My Server is configured to accept both SSLv3 and TLS1.0 protocols. But a few clients are sending below handshake parameters and after the server hello, the client drops the connection and sends 'handshare failure(40) alert, not sure if it's the client fault or server.
Here's the initial client hello packet:
Secure Socket Layer
SSLv3 Record Layer: Client Hello
Content Type: Handshake (22)
Version: SSL 3.0 (0x0300) <-----------------
Length: 103
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 78
Version: TLS 1.0 (0x0301) <-------------
Random
Session ID Length: 0
Cipher Suites Length: 18
Cipher Suites (9 suites)
The Record layer is SSL 3.0 but the inside handshake protocol is TLS 1.0. My question is, is this the right way of doing it i.e. using different versions for each layer? if it is what method is it? I can't find it anywhere, I looked through the RFC but can't find any reference. Also, how can I produce such requests?
EDIT: I'm not interested in troubleshooting and fixing the issue, I just want to know how can I send such packets? Any command? And what should I name this method?
i.e. I can use curl or openssl to either use ssl3 or tls1 but that would send same version in both record layer and handshake layer:
curl -v -ssl3 https://www.mywebserver.com
Above curl command would look on wireshark:
EDIT2: Is this even legal? I have been googling around and can't find any example. Is it violating any rfc standards?
Thanks
Yes, this is legal (at least it was clarified in recent TLS specifications).
You can look this up in rfc5246 (TLS 1.2) or in rfc6101 (SSL 3.0) or other rfc's concerning the SSL/TLS. The problem is with the initial version of the record protocol and with the handshake protocol:
rfc5246:
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version.
Regarding the handshake protocol, the client will negotiate the highest version that it has implemented:
client_version: The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client
I just want to know how can I send such packets? Any command?
openssl s_client -connect www.myserver.com:443 -no_ssl2
should produce something similar to the trace you provided.
Related
When using ssl_version of TLSv1_2 and the receiver is using tls version 1.0, will it honor both tls version 1 and 1.2?
conn.use_ssl = useSSL
conn.ssl_version="TLSv1_2"
conn.verify_mode = OpenSSL::SSL::VERIFY_NONE
By setting conn.ssl_version="TLSv1_2", you are forcing the TLS version to exactly TLS 1.2. thus, the connection will be negotiated either with this exact version, or not at all. If the server only offers TLS 1.0, TLS 1.1 or even (exclusively) TLS 1.3, then the connection will not be established.
Note that this is unrelated to the verify_mode which only affects how the certificates presented by the server are validated. With OpenSSL::SSL::VERIFY_NONE, you are telling the client that it should not check whether the certificates can be validated against any trusted root certificates. The server must still provide a syntactically valid certificate and "correct" encryption.
I am using Spring Rest template for making GET requests calls to an external API. This API does not support TLS 1.3 yet. The connection to the service works fine during normal work load.
During load testing, I observed that some of the calls were failing with the below exception:
Remote host terminated the handshake; nested exception is javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:748)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:674)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:583)
On enabling javax.debug level logs, found that for the calls that failed, TLS1.3 protocol was used for handshake.
javax.net.ssl|DEBUG|9D|http-nio-8080-exec-28|2021-02-09 16:34:59.588 UTC|SSLSocketOutputRecord.java:71|WRITE: **TLS12** alert(close_notify), length = 10
javax.net.ssl|DEBUG|06 87|http-nio-8080-exec-176|2021-02-09 16:34:08.621 UTC|SSLSocketOutputRecord.java:71|WRITE: **TLS13** alert(handshake_failure), length = 2
My application is implemented in Java 11 [openjdk 11.0.3]. Java 11 also supports TLS 1.3. In order to resolve the issue, I will have to enforce it to use TLS1.2.
I want to understand, how is the TLS protocol version to be used determined by Java? In this case, both TLS1.2 and TLS1.3 were used alternatively.
We are currently using java 7 and have trouble connecting to the geocode API from HERE.
When testing in our application we receive an error as follows:
Received fatal alert: handshake_failure
The url we request:
https://geocoder.ls.hereapi.com/6.2/geocode.json?apiKey={API-KEY}&searchtext=NYC,+USA
Running the same request in Postman works seamlessly.
Likewise running the code for the request in an alternative java 8 workspace. The request returns the expected response.
We assume the reason is that no matching ciphers exist between client and server when using java 7.
Does the HERE support team know of problems similar to this?
Is there a good workaround without having to upgrade to jdk1.8?
The HTTP connection to HERE APIs utilizes via TLSv1.2 cryptographic protocol because TLSv1.0 and TLSv1.1 have known security vulnerabilities.
In the jdk1.8 the SSLContext has been already set to TLSv1.2 by default therefore it works (unlike jdk1.7, you can see a handshake info if pass the -Djavax.net.debug=all parameter).
For java 7 you need to set SSLContext to TLSv1.2 before a https connection to init in your java code:
SSLContext sslCtx = SSLContext.getInstance("TLSv1.2");
sslCtx.init(null,null,null);
SSLContext.setDefault(sslCtx);
Additionally you can update the Unlimited Strength Java(TM) Cryptography
Extension (JCE) Policy Files for the Java(TM) Platform, Standard
Edition (Java SE) Runtime Environment 7 - This bundle provides "unlimited strength" policy files which contain no
restrictions on cryptographic strengths.
Trying connect to https server (https://3dsecure.kkb.kz) using TLS 1.2.
(defn- http-request-clojure [xml req-type]
(let [url-info (url-map req-type)
(prepare-response (.toString (:body (client/get
(str (:url url-info) "?"
(and (:name url-info)
(str (:name url-info) "="))
(URLEncoder/encode xml))
{:insecure? true
:socket-timeout 10000
:conn-timeout 10000}))))))
Got error "javax.net.ssl.SSLException: Received fatal alert: protocol_version"
openssl 1.0.1g , java 7.
Any ideas what goes wrong?
It's not you, it's them: from their Qualys SSL Labs report:
Java 6u45 No SNI 2 Protocol or cipher suite mismatch Fail3
Java 7u25 Protocol or cipher suite mismatch Fail3
Java 8u31 TLS 1.2 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) No FS 112
at least from today. They could fix this at any time, so hopefully you have a close enough relationship to politely encourage them to folow that link, and perhaps update openssl to they aren't vulnerable to this protocol downgrade attack.
This is almost always a simple matter of changing the nginx or apache config, though it can take a little fiddling to ensure all devices can still connect. SSL labs is an amazing resource for figuting this out.
From your perspective, is using Java 8 an option? It will be the easiest way past this.
I wrote a websocket server in c++ that works fine with websocket protocol 00 (the one with key1, key2 in handshake header).
Now with the new update I am trying to do the same for the new way handshaking work. Here is my server response to the handshake request:
"HTTP/1.1 101 Switching Protocols\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nSec-WebSocket-Accept: " + serverKey + "\r\n\r\n";
in which serverkey is computed correctly. As an example:
handshake request:
GET /test HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 192.168.123.102:8585
Sec-WebSocket-Origin: http://192.168.123.5
Sec-WebSocket-Key: YB0mPvJ5t8ggCeGUWY39uQ==
Sec-WebSocket-Version: 8
handshake response header :
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: xt9iyCNryQTseELUkHPWjzxA2ts=
I also check my algo with the example here https://datatracker.ietf.org/doc/html/draft-ietf-hybi-thewebsocketprotocol-08 and it produced the exact same response.
However I still get the following error:
"Error during WebSocket handshake: Sec-WebSocket-Accept mismatch"
I am using chrome 15 as my browser.
Do you have any Idea what goes wrong?
(also in chrome inspector Network, it does not show the response which is the case when it does not accept the handshake (even with older versions))
I actually found out what was the primary problem.
the key that I used for base64 encoding was
YB0mPvJ5t8ggCeGUWY39uQ==
258EAFA5-E914-47DA-95CA-C5AB0DC85B11
instead of
YB0mPvJ5t8ggCeGUWY39uQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11
an extra \n was the whole problem.
HOWEVER, Now that I receive the Connected message (ws client is successfully connected to ws sever) I cannot send or receive anything. The problem is server side.
DO you know what are the server side changes since older websocket protocol? I only change my handshake respond and it doesnt seem enough.
There is a different framing protocol for when the client sends data. Previously it was quite simple. Now it is much more complicated. Please refer to the websockets rfc6455 spec.
https://www.rfc-editor.org/rfc/rfc6455#section-5.2