> I suspect that some clients fail to use SNI. I've already seen > this from time to time. It looks like after some errors, they > refrain from using SNI or even TLS at all and fall back to SSLv3.
This scared my a bit, so I've done some digging. I've found 2 related bug reports with a lot of details: NSS: SSL+SNI+client-auth "lost" after some time https://bugzilla.mozilla.org/show_bug.cgi?id=728715 Apache: SSL+SNI+client-auth "lost" after some time https://issues.apache.org/bugzilla/show_bug.cgi?id=52703 This behavior seem to arise from a very specific and strange configuration: The server supports TLSv1.0 and SNI, but TLSv1.0 is disabled. Here is what happens: When the browser starts a fresh ssl session to the server, the client_hello usually announces TLSv1.0 or TLSv1.1 and the request contains the server_name (SNI) header. Since the server on the other side: - does support SNI, server_name is parsed and used (so this request is ok) - since TLS is disabled on the server, the server_hello contains only a SSLv3 announcment - the session id is exchanged and keepalive and multiple sessions keep the service working for a few seconds - the browser caches the session id and also the fact the the server doesn't support TLS - on subsequent requests, the browser remembers the server is SSLv3-only and connects - as per RFC2246 - directly in SSLv3. - since SSLv3 doesn't support TLS Extenions like SNI, the server_name attribute is omitted from the client_hello, and the server has to hand out the default certificate. One can see this behavior very well in the attachment from the NSS bug report: session 1: https://bug728715.bugzilla.mozilla.org/attachment.cgi?id=598729 session 2: https://bug728715.bugzilla.mozilla.org/attachment.cgi?id=598730 In this case, only one of the following 2 RFC "SHOULD"'s can be implemented, because a SSLv3 message cannot contain a TLSv1 extension: RFC2246 (TLSv1.0): > Whenever a client already knows the highest protocol known to a > server (for example, when resuming a session), it should initiate the > connection in that native protocol. RFC6066 (Transport Layer Security (TLS) Extensions; like SNI): > The client SHOULD include the same server_name extension in the session > resumption request as it did in the full handshake that established the > session. So in this case, we should verify whether the server allows a TLSv1.0 handshake or if a fallback to SSLv3 is happening. > bind :443 ssl crt [...] no-tlsv10 ciphers ECDHE-RSA-AES256-SHA:[...] Kenneth, can you please remove the "no-tlsv10" keyword from the bind line in your configuration. This will enable TLSv1.0 which I believe will fix the issue you are seeing. Lukas
