728715 - SSL+SNI+client-auth "lost" after some time

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[Christoph Anton Mitterer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Iceweasel/10.0.2
Build ID: 20120217174734

Steps to reproduce:

Hi.

I've originally reported this problem against the Apache HTTPD Server, but there is some indication that this is not a problem of the server, but of the browsers.

The basic story is, that I have an Apache HTTPD server, that runs SSL vhosts with SNI (Server Name Indication).
The vhost uses SSL client authentication (required) and fakeBasicAuth (but the later is likely completely unrelated).


When I access the website in Firefox and/or Chromium authenticate myself by choosing one of my certificates, the access works and I see the website.

But after some time (between 2-10 minutes usually) when I reload the page or it automatically reloads, the access fails.

So far the reasons seems that the browser doesn't send the SNI host name again.
The only solution is to either restart the browser or in Firefox, clear the "Active Logins".
Then I can reload, reauthenticate and it works for another while.

As you can imagine this is extremely annoying ;-) .

I've put extensive information in the bug report:
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

and a thread on Apache's user mailing list:
https://mail-archives.apache.org/mod_mbox/httpd-users/201202.mbox/%3C9242b47ae7f6c0e17980992824c639c2%40scientia.net%3E
(click the thread link on the right top)

Maybe (but this is just pure speculation) bug #728713 (https://bugzilla.mozilla.org/show_bug.cgi?id=728713) is somehow related to this one.

Any help or information how to further trace this down would be great.
(I'm however on holidays till 1st of March, so expect a delay in further answers)


Cheers,
Chris.

Comment 1

[Matthias Versen [:Matti]]

Please try bug 728713#c3

Comment 2

[Christoph Anton Mitterer]

https://code.google.com/p/chromium/issues/detail?id=114944

Comment 3

[Christoph Anton Mitterer]

Sorry, the URL in comment 2 meant to be described as:

I've just reported the same issue in Chromium.

Comment 4

[Christoph Anton Mitterer]

Matthias, I've just tried "NSS_SSL_CBC_RANDOM_IV=0" with this issue.
It doesn't change anything.

Comment 5

[Christoph Anton Mitterer]

Attachment: ssltap log - connection #1 (success)

Comment 6

[Christoph Anton Mitterer]

Attachment: ssltap log - connection #2 (failed)

Comment 7

[Christoph Anton Mitterer]

I've added two logs made with ssltap.
Again, a 1st connection where it worked and a 2nd where it then failed.

I'm not an SSL expert, but it seems that on the 1st access it correctly sends the server_name.
But on the later access nothing at all.

Comment 8

[Matthias Versen [:Matti]]

In the second connection log you can see that the client is using a session_id and that looks like a connection resumption.

From rfc6066:
>Note also that all the extensions defined in this document are
>relevant only when a session is initiated.  A client that requests
>session resumption does not in general know whether the server will
>accept this request, and therefore it SHOULD send the same extensions
>as it would send if it were not attempting resumption.

Comment 9

[Christoph Anton Mitterer]

What does this mean now?
Is there anything I can do to help (I'm on vacation starting with today, till 29th... not sure whether I can go online till then.)?

If this was a bug in NSS, it would also explain why Chromium is affected, right?
It uses NSS, too, AFAIR?

Comment 10

[Christoph Anton Mitterer]

Is there anything left I can do to help tracking this down?

Comment 11

[Christoph Anton Mitterer]

I've just reported this https://issues.apache.org/bugzilla/show_bug.cgi?id=52703#c3 ... which seems to imply that SSL session resumption is responsible for this issue, as well as for #728713.

Again, it happens with Firefox/Chromium (both using NSS) so this might be
either a NSS bug or an Apache bug or some bad playing between both.

Comment 12

[Wan-Teh Chang]

Christoph: thank you for the bug report.  The ssltap logs
are helpful.

The ssltap log for the full handshake shows the ClientHello
advertised SSL version 3.1 (TLS 1.0) but the ServerHello
chose SSL version 3.0.

The ssltap log for the session resumption handshake shows the
ClientHello advertised SSL version 3.0, which is why it had
no TLS extensions.

Here is how NSS determines the SSL version to advertise in
ClientHello:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.165&mark=3891,3899,3907,3910,3918#3891

'sid' points to a sslSessionID structure.  Note the second
argument passed to ssl3_NegotiateVersion().  It caps the
version advertised in ClientHello.  So, if sid exists and
sid->version is SSL 3.0, ClientHello will advertise SSL 3.0.

So, you can solve the problem by turning on TLS 1.0 in your
Apache HTTPD server.

I have two questions for the people cc'ed in this bug.

1. If a server chooses SSL version 3.0, should it process
the TLS extensions in the ClientHello?

Since SSL 3.0 does not define any extensions (except the
renegotiation_info extension that was added in RFC 5746),
it seems that a server that chooses SSL 3.0 should ignore
all extensions in the ClientHello except the
renegotiation_info extension.

An NSS server seems to process extensions when it uses
SSL 3.0:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.165&mark=6145-6150#6145

2. When a client tries to resume an SSL 3.0 session,
should it cap the version advertised in ClientHello to
SSL 3.0, or more generally the version of the previous
session?

Comment 13

[Christoph Anton Mitterer]

Uhm... SSLProtocol is set to "TLSv1 SSLv3", so TLS is on... do you mean _only_ TLS?

Anything else I can do?

Comment 14

[Wan-Teh Chang]

Christoph:

In "ssltap log - connection #1 (success)" (attachment 598729 [details]),
search for "client_version" and "server_version".  You will
see that the browser advertised version 3.1 (TLS 1.0) in
ClientHello, but the server chose version 3.0 (SSL 3.0) in
ServerHello.

So you need to figure out why your server chose SSL 3.0 under
that condition.  I thought it was because TLS 1.0 was disabled.
But the SSLProtocol setting you showed seems to mean both
TLS 1.0 and SSL 3.0 are enabled.  So I don't know why your
server didn't choose TLS 1.0.

The Apache mod_ssl doc at
http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslprotocol
seems to suggest that you need to use the plus sign '+'.  So
you can give "+TLSv1 +SSLv3" a try.

Comment 15

[Christoph Anton Mitterer]

Ok I just changed the setting to "+TLSv1 +SSLv3" and indeed it seems to change the behaviour of Apache, at least it seems to work now WITH SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000).

This is a bit strange, as normally the +/- is only used to merge options from different and not the same directive.


So:
a) With TLS 1.0, evertyhing seems to work

b) This seems to be a bug (or documentation unclarity) with respect to which protocols get enabled.

c) It does no work with SSL 3.0... is this expected? Or a bug somewhere (NSS or Apache?)?

Comment 16

[Christoph Anton Mitterer]

Eric from the Apache folks made some interesting comments at
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703#c6
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703#c8

If you haven't read this, it might be worth to do so.
I don't fully understand their implications...

Comment 18

[Matthias Versen [:Matti]]

comment #15
>c) It does no work with SSL 3.0... is this expected?

from comment #12
>Since SSL 3.0 does not define any extensions
There is no SNI in SSL3.0 since SNI appeared only in TLSv1 (=SSL3.1).

The NSS developer don't need additional information at the moment since the technical issue seems to be clear (comment #12)

Comment 19

[Christoph Anton Mitterer]

So what does this mean now? Is everything "clear" and the bugs can all be closed?

Comment 20

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Wan-Teh Chang from comment #12)
> 1. If a server chooses SSL version 3.0, should it process
> the TLS extensions in the ClientHello?

 "A server that receives a client hello containing the "server_name"
  extension MAY use the information contained in the extension to guide
  selection of an appropriate certificate to return to the client,
  and/or other aspects of security policy.  In this event, the server
  SHALL include an extension of type "server_name" in the (extended)
  server hello."

 "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."

My recommendation is that if the server includes the server name indication extension in the server hello, regardless of whether the server selects SSL 3.0 or TLS 1.0, then we must include the server name indication extension in any resumption handshakes for that server.

More generally, I suggest that if the server includes ANY server hello extensions, then we should assume that the server can tolerate extensions, regardless of whether the negotiated protocol version is SSL 3.0 or TLS 1.0+; in the case of SSL 3.0 with at least one server extension, we should then send the same extensions we would send for a TLS 1.0 session resumption.

> Since SSL 3.0 does not define any extensions (except the
> renegotiation_info extension that was added in RFC 5746),
> it seems that a server that chooses SSL 3.0 should ignore
> all extensions in the ClientHello except the
> renegotiation_info extension.

AFAICT, nothing prohibits SSL 3.0 servers from implementing extensions.

> 2. When a client tries to resume an SSL 3.0 session,
> should it cap the version advertised in ClientHello to
> SSL 3.0, or more generally the version of the previous
> session?

This has been discussed repeatedly on the TLS WG mailing list. But, IIRC, there are bugs with IIS (or generically with SChannel?) that sort of forces this issue, one way or another. I cannot remember the details though.

Comment 21

[Wan-Teh Chang]

Christoph:

From your point of view, everything is clear and the bugs can all be closed.

Both the NSS and Apache/mod_ssl teams can look into how their respective code
works under certain conditions.  But it's possible that neither team will spend
much time on them because SSL 3.0 is becoming less and less important.

NSS side:
1. Consider sending extensions in a SSL 3.0 ClientHello when trying to resume a
   session if the server previously included an extension other than renegotiation_info
   in ServerHello.
2. Consider not capping the protocol version in ClientHello to the version of the
   previous session when trying to resume a session.

(I think only #2 is worth doing because it is independent of SSL 3.0.)

Apache/mod_ssl side:
- Find out why Apache/mod_ssl cannot resume an SSL 3.0 session if the server name
  indicator is not provided in the ClientHello that tries to resume the session.
  See "ssltap log - connection #2 (failed)"
  (https://bugzilla.mozilla.org/attachment.cgi?id=598730) for the SSL packet
  trace that shows the session resumption failed and a full handshake was
  performed.

Comment 22

[Wan-Teh Chang]

Attachment: ssltap log showing Internet Explorer's ClientHello versions in session resumption

My experiments showed that IE also caps the protocol version advertised
in a ClientHello that tries to resume a session to the version of the
session.

I don't know of an SSL 3.0 website, so I enabled TLS 1.1 in IE and
tested against a TLS 1.0 website (https://www.verisign.com/).  IE
advertised version 3.2 (TLS 1.1) in ClientHellos that didn't have a
session ID, but advertised version 3.1 (TLS 1.0) in ClientHellos
that had a session ID.

So it may not be a good idea to change the behavior of NSS but I
still don't know why we should cap the protocol version like this :-)

Comment 23

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Wan-Teh, there are implementations that are buggy with respect to RSA key exchange. Remember that the negotiated version number is included as part of the encrypted data in RSA key exchange, to avoid version rollbacks. IIRC, some implementations expect that the version offered in the client hello will appear there; other implementations expect that the version negotiated will appear there. IIRC, such problems may occur only with renegotiations and/or only with resumptions. I think that such capping has a positive effect when dealing with such things.

Comment 24

[Wan-Teh Chang]

Attachment: Add a comment about the advertised version in ClientHello when trying to resume a session

I found that capping the version advertised in ClientHello by the
version in the SSL session ID is recommended by the TLS RFCs.  So
I added a comment about that.

Comment 25

[Christoph Anton Mitterer]

Wasn't 2246 obsoleted by 4346? Is it still recommended there?

Comment 26

[Wan-Teh Chang]

This recommendation is still in TLS 1.2 (RFC 5246).  The only change
is that "should" is capitalized "SHOULD".

Since that piece of code was written before year 2000, I thought I
should cite the current TLS specification at that time.