Lukas, Excellent analysis there! As of this morning, I have removed the no-tlsv10 option from the bind and asked folks to report back if they are still seeing the default certificate when they are not supposed to.
The extended logging is also enabled. If I do get these errors again, I will collect some relevant data from those and see if I can spot this behaviour. Many thanks, Kenneth On Fri, Mar 15, 2013 at 11:35 PM, Lukas Tribus <[email protected]> wrote: > > > 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 > >
