My server running on PC uses LibreSSL
My client running on board uses wolfSSL
Will handshake be success?
Different TLS implementations can work together because they all implement a standardized protocol. This does not mean that it will work in all cases, i.e. common problems like no shared ciphers, invalid certificates etc can happen both when connecting with different TLS stacks but also when connecting with same TLS stacks.
In other words, there are no inherent handshake problems caused by using different TLS stacks. But other problems might make the handshake fail.
Related
I have a couple questions.
If I were to use TLS1.0->1.3 Client-Side and never use SSLv2 or v3, would there be any impacts on TCP Client Handshake Compatibility?
As in, would there ever be a server that wouldn't support this change that would require me to use SSLv2/v3?
I guess what i'm asking is if TLS is backwards compatible which servers that use SSLv2/v3 or do I not understand SSL/TLS properly?
Also other way around, if I was running an OS that had no support for TLS, would I at some point end up with Protocol Issues when Handshaking an SSL Stream?
I used Wireshark to monitor packages of some websites, but found that there are such many communicating patterns of TLS 1.2.
The first one is a generic one:
Client: Client Hello
Server: Server Hello, Certificate, Server Hello Done
Client: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
Server: Change Cipher Spec, Encrypted Handshake Message
Second one is as followed:
Wireshark1
I'm just confused with why Certificate and Server Hello Done was in another package. Who demand server to do that? For what reasons?
After multiply refreshing page, I got the third one:
Wireshark2
Only 3 packages in handshake? A lot of processes were missed, was it because the information was cached? And how about the pre-master key?
Thanks for the answering!
TLS is a protocol over TCP, i.e. over a streaming transport protocol. For transport the data stream gets split into packets and thus it can happen that the ServerHelloDone is contained in one packet or in another or even split over two packets. Since the sizes are visible in your second example but not in the first it is unknown why the difference is exactly but it might be caused by the size of the certificate(s) contained in the handshake.
As for the third example: this is simple a TLS session reuse, i.e. it continues an older session and thus no sending of server certificate or similar is needed.
I'm testing SSL/TLS stream proxying within NGINX that will connect to a web server using gnutls as the underlying TLS API. Using the command line test tool in gnutls (gnutls-serv) the entire process works, but I can't understand the logic:
the NGINX client (proxying HTTP requests from an actual client to the gnutls server) seems to want to handshake the connection multiple times. In fact in most tests it seems to handshake 3 times without error before the server will respond with a test webpage. Using wireshark, or just debugging messages, it looks like the socket on the client side (in the perspective of the gnutls server) is being closed and reopened on different ports. Finally on the successful connection, gnutls uses a resumed sessions, which I imagine is one of the previously mentioned successful handshakes.
I am failing to find any documentation about this sort of behaviour, and am wondering if this is just an 'NGINX thing.'
Though the handshake eventually works with the test programs, it seems kind of wasteful (to have multiple expensive handshakes) and implementing handshake logic in a non-test environment will be tricky without actually understanding what the client is trying to do.
I don't think there are any timeouts or problems happening on the transport, the test environment is a few different VMs on the same subnet connected between 1 switch.
NGINX version is the latest mainline: 1.11.7. I was originally using 1.10.something, and the behaviour was similar though there were more transport errors. Those errors seemed to get cleaned up nicely with upgrading.
Any info or experience from other people is greatly appreciated!
Use either RSA key exchange between NGINX and the backend server or use SSLKEYLOGFILE LD_PRELOAD for NGINX to have the necessary data for Wireshark to decrypt the data.
While a single incoming connection should generate just one outgoing connection, there may be some optimisations in NGINX to fetch common files (favicon.ico, robots.txt).
I would like to display a message to customers who's browser's highest level of encryption is SSLv3. Is it possible for me to target browser settings of SSLv3 and lower? Client or Server code? We will be allowing lower versions of SSL to use our site during a certain grace period. During this grace period, we would like to display a message only to those users that have browser settings of SSL3 or lower.
Not easily. The browser's supported SSL versions are not detectable until the SSL handshake is in progress, and even then only if the browser uses an SSLv2 handshake to allow dynamic version negotiation. If an unsupported version were detected, you would not be able to send a message back since the handshake failed and the connection would be closed before you could send any message. However, SSL itself has an error packet that gets sent during handshaking, and it can specify a version mismatch error.
The best you can do in your own code is support all SSL versions on the server side, let the client complete a handshake normally, and then detect which version was actually used and send back a message if the SSL version is too low.
Or, you could simply enable TLSv1 or higher only, and simply refuse to let older clients connect at all. They just would not get a nice error message unless the browser decided to detect the SSL version mismatch error and display its own pretty message about it.
Firstly, nowadays, you can generally forget about clients that don't support at least SSLv3. SSLv3 has been widely available for many years.
The TLS Client Hello message, sent when the connection is initiated by the browser, should contain the highest TLS version it supports:
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. For this
version of the specification, the version will be 3.3 (see
Appendix E for details about backward compatibility).
Appendix E is of course worth looking at.
(The Client Hello message will also contain the list of cipher suites the client supports, which is possibly relevant for the general idea of your question.)
Of course, this specification is just a "SHOULD", so a client supporting TLS 1.2 could still send a Client Hello for TLS 1.1, but what would be the point? By doing so it would have no chance ever to use TLS 1.2 anyway. It could be a preference box that is turned off, but that would effectively make it a client that doesn't support the highest version anyway. (If you want anything more subtle, you'd need to build a database of known user agents, which will be partly unreliable, and for which you'd need to analyse the full user agent string to know everything possible about the platform.)
Now, how to convey the content of the Client Hello message to your application is another matter, and depends very much on which SSL/TLS stack you use. It might not even be directly possible without modifying that SSL/TLS library or the server you're using.
This being said, you can generally get the negotiated TLS version during the current session quite easily. Since that version is the "lower of that suggested by the client in the client hello and the highest supported by the server" (i.e. "min(max(client), max(server))"). If your server supports SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2, and since the latest version is TLS 1.2 anyway, what you'll get during your current connection will also be the max currently supported by the client. As long as your server supports the latest version, you should be able to know what the client supports at best from any live connection.
If you're behind Apache HTTP server's mod_ssl, you should be able to get that from the SSL_PROTOCOL environment variable. You should also be able to get the protocol from the SSLSession in Java.
(If you are willing to write a more bespoke service, you could pass further details like the cipher suites more directly to your application, like this service from Qualys SSL Labs does, although I'm not sure if it's meant to be widely available or just a test service.)
I'd have to agree with Remy about it being a bit challenging.
However, a good starting point may be to retrieve some SSL (certificate) information.
Something similar to this:
X509Certificate certChain[] =
(X509Certificate[]) req.getAttribute("javax.net.ssl.peer_certificates");
Another way of getting more information is to retrieve the cipher_suite attribute (similar to the code snippet above).
javax.net.ssl.cipher_suite
I hope this (at least) gets you closer.
Good luck.
1 question about Stunnel. I would like to use Stunnel as a FIX (Financial Information eXchange) gateway for internet, to support both SSL and non-SSL connection. Is Stunnel able to do without any encryption? I just had a try with plain socket but it looked Stunnel rejected the connection saying 'invalid protocol' or something.
It's possible to use SSL/TLS without encryption using cipher suites with null encryption (e.g. TLS_RSA_WITH_NULL_SHA), which are normally disabled by default, but could be set via the ciphers option of Stunnel. However, you would still be using SSL/TLS, which isn't what you seem to be looking for.
It looks like you're more generally looking for what's usually called a TCP bouncer. You should be able to find a number of implementations around.