If a web server fails to complete TLS handshake and returns error to TLS client (i.e. browser), does a typical TLS client such as chrome browser retry the handshake a few times before giving up? And if it does retry how many retries? Also is there a TLS handshake timeout in chrome, past that would it retry or just give up ?
In the past browsers tried the TLS handshake itself with an older TLS version in the hope that it will succeed then. Today browsers usually don't do this anymore, i.e. if the initial connection fails they don't retry.
Also is there a TLS handshake timeout in chrome
There is one, i.e. the browser will not wait forever for the server to reply but give up after a while.
Related
I have TLS program and I did some experiments on it.
I start confidential TLS server session and try to connect to it with pure Telnet client.
As expected, the handshake failed and the server is available to the next client but on the Telnet client side I didn't receive any indication that the handshake failed and that the server is accepting other clients.
I can see in Wireshark that even after the handshake failed the Telnet client can send strings; I see [PSH, ACK] from the client answered by [ACK] from the server.
Adding Wireshark snapshot, Telnet failed the handshake, Telnet keep sending messages, followed by success in the TLS handshake and more Telnet messages:
Why is the server ACKing the Telnet client if the handshake failed and he is accepting other clients?
As expected, the handshake failed ...
I cannot see a failed TLS handshake in the packet capture and I'm not sure how you come to this conclusion.
All I can see that the client on source port 60198 (presumable your telnet) is sending 3 bytes several times and the server just ACK'ing these without sending anything back and without closing the connection. Likely the server is still expecting data in the hope that at some time it will be a complete TLS record. Only then it will be processed by the TLS stack and then it might realize that something is wrong with the client.
... the server is available to the next client
It is pretty normal for a server to handle multiple clients in parallel. In contrary, it would be unusual if the server could not do this.
I'm working on an academic project about TLS handshakes and i have captured some TLS traffic generated by multiple clients (google chrome, firefox...) and I want to see if for a given browser the client hello message will always be the same or no (I have removed the GREASE extensions because they are added in a random way to the client hello message and I omitted the SNI). I found that the same browser generate multiple client hello messages.
Is it normal to see such behavior or I'm doing something wrong?
A TLS handshake is done for each TCP connection involved in HTTPS and it is common that the browser uses multiple TCP connections in parallel. This is probably what you see. Multiple TLS handshakes within the same TCP connection are uncommon but might happen if a server requires a client certificate only for a specific path and thus triggers a renegotiation.
I've set out to handle tls operations manually on a websockets server, due to the cockeyed way php supports listening on secured transports.From RFC6455:
If /secure/ is true, the client MUST perform a TLS handshake over the
connection after opening the connection and before sending the
handshake data [RFC2818]. If this fails (e.g., the server's
certificate could not be verified), then the client MUST Fail the
WebSocket Connection and abort the connection. Otherwise, all
further communication on this channel MUST run through the encrypted
tunnel [RFC5246].
According to this, the first thing I should receive is the clientHello message which signifies the beginning of a TLS handshake.But all I receive on the server is the websocket handshake request, encrypted.
I am baffled by this.Is there no TLS handshake at all?
I have recently switched over to HAProxy from AWS ELB. I am terminating SSL at the load balancer (HAProxy 1.5dev19).
Since switching, I keep getting some SSL connection errors in the HAProxy log (5-10% of the total number of requests). There's three types of errors repeating:
Connection closed during SSL handshake
Timeout during SSL handshake
SSL handshake failure (this one happens rarely)
I'm using a free StartSSL certificate, so my first thought was that some hosts are having trouble accepting this certificate, and I didn't see these errors in the past because ELB offers no logging. The only issue is that some hosts have do have successful connections eventually.
I can connect to the servers without any errors, so I'm not sure how to replicate these errors on my end.
This sounds like clients who are going away mid-handshake (TCP RST or timeout). This would be normal at some rate, but 5-10% sounds too high. It's possible it's a certificate issue; I'm not certain exactly how that presents to
Things that occur to me:
If negotiation is very slow, you'll have more clients drop off.
You may have underlying TCP problems which you weren't aware of until your new SSL endpoint proxy started reporting them.
Do you see individual hosts that sometimes succeed and sometimes fail? If so, this is unlikely to be a certificate issue. I'm not sure how connections get torn down when a user rejects an untrusted certificate.
You can use Wireshark on the HAProxy machine to capture SSL handshakes and parse them (you won't need to decrypt the sessions for handshake analysis, although you could since you have the server private key).
I had this happen as well. The following appeared first SSL handshake failure then after switching off option dontlognull we also got Timeout during SSL handshake in the haproxy logs.
At first, I made sure all the defaults timeouts were correct.
timeout connect 30s
timeout client 30s
timeout server 60s
Unfortunately, the issue was in the frontend section
There was a line with timeout client 60 which I only assume means 60ms instead of 60s.
It seems certain clients were slow to connect and were getting kicked out during the SSL handshake. Check your frontend for client timeouts.
How is your haproxy ssl frontend configured ?
For example I use the following to mitigate BEAST attacks :
bind X.X.X.X:443 ssl crt /etc/haproxy/ssl/XXXX.pem no-sslv3 ciphers RC4-SHA:AES128-SHA:AES256-SHA
But some clients seem to generate the same "SSL handshake failure" errors. I think it's because the configuration is too restrictive.
The https-version of my website suddenly is not reachable any more from Firefox or Chrome (chrome shows ERR_TIMED_OUT). Both browsers behave as if the site was down. With Internet Explorer is working all right.
This happens on multiple computers since yesterday. I use a startcom.org signed certificate.
Wireshark shows:
TLSV1 Client Hello
TLSV1 Server Hello
Certificate
Server Key Exchange, Server Hello Done
Client Key Exchange, Change cipher spec, Encrypted Handshake Message
Encrypted Handshake Message, Change cipher spec, Encrypted Handshake Message
Encrypted Alert
TCP RST, ACK
A bit later there is a request from User-Agent: Microsoft-CryptoAPI/6.1 to crl.startssl.com/crt1-crl.crl
Any help appreciated.
This may be caused by different behaviour when checking for certificate revocation (via CRLs) doesn't work. It seems that StartSSL has had some problems recently, and http://crl.startssl.com/crt1-crl.crl is quite slow to respond.
You can check whether it's enabled in your browser.
In IE: Internet Options -> Advanced -> Security -> Check for server certificate revocation
In Firefox, in about:config -> see the options that contain the text crl (and ocsp).