507351 - Rapid(?) connections to an SNI-enabled server returns content from the wrong vhost

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[Ben Roberts]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1) Gecko/20090718 Sabayon Firefox/3.5.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1) Gecko/20090718 Sabayon Firefox/3.5.1

I frequently have problems connecting to an apache2 server running SNI (with a backported OpenSSL library) which only manifests in Firefox (Windows/Linux) and not any other browser I've tried (IE7/8, Opera running on both Windows and Linux).

Occasionally when connecting to an SNI enabled server, Firefox will not correctly negotiate the TLS connection, and will be served content from the default vhost on the server. This presents an SSL-certificate warning which persists until the browser is completely restarted (Firefox processes terminated, and the browser reopened).

The problem appears to occur more frequently if the browser is making several concurrent connections to the SNI-enabled server. But I admit I haven't empirically tested this. It is particularly noticeable when opening a saved session with one or more tabs open to the SNI-enabled server.

Reproducible: Sometimes

Steps to Reproduce:
1. Open several tabs to an SNI-enabled webserver, such as https://dev.sihnon.net/
2. Save the session, and exit the browser completely
3. Reopen the browser with the saved session reloaded
Actual Results:  
More often than not, at least one tab will be showing an SSL certificate error, having been served content from the "localhost" vhost with an invalid SSL certificate.

Expected Results:  
Every tab to be displaying content from the dev.sihnon.net vhost, with no SSL errors.

This bug is present in the current 3.5.1 release, and was also present in the 3.0.x releases.

Comment 1

[Kaspar]

Chances are good that this is an issue with PSM's code for dealing with TLS intolerant servers - see bug 239381, which tracks some of these bugs.

Do you already log the SSL/TLS version in your Apache logs? (If not, add  %{SSL_PROTOCOL}x to the respective LogFormat directive.) If all "failed" requests show "SSLv3" (and not "TLSv1"), this would further confirm my hypothesis - Firefox erroneously falls back to SSL 3.0 even though the server speaks TLS 1.0.

Also, note that bug 412833 was recently resolved, so you could give one of the latest nightly builds a try and see if it solves your problem: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ (note that this particular fix is not in any of the 3.5.x versions).

Comment 2

[Ben Roberts]

I can your SSLv3 theory:

// Resumed session with two directory listings, and one websvn tab open
2a01:348:1b6:0:21b:21ff:fe04:b6ac - - [06/Aug/2009:18:01:27 +0100] "GET /websvn/index.php HTTP/1.1" 200 4349 TLSv1
2a01:348:1b6:0:21b:21ff:fe04:b6ac - - [06/Aug/2009:18:01:29 +0100] "GET /websvn/templates/calm/images/favicon.ico HTTP/1.1" 200 15086 TLSv1
2a01:348:1b6:0:21b:21ff:fe04:b6ac - - [06/Aug/2009:18:01:29 +0100] "GET /websvn/templates/calm/collapse.js HTTP/1.1" 200 4984 TLSv1
// The websvn tab is showing partial content, the directory listing tabs are both showing certificate errors. Refreshing any of the three tabs makes no new requests to the server.
// At this point I added an exception for the mismatched certificate, and pages are now viewable, with the following server log entry:
2a01:348:1b6:0:21b:21ff:fe04:b6ac - - [06/Aug/2009:18:01:58 +0100] "GET /websvn/index.php HTTP/1.1" 200 4349 SSLv3

It looks like this might be a duplicate of bug 412833. I'll see how difficult it will be to build a nightly on this machine and test with that.

Comment 3

[Kai Engert [:KaiE:]]

Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody

Comment 4

[David Caldwell]

This bug is happening to me with my server (Apache 2.2.16) and Firefox 4.0b9 (and it happened with FF 4.0b8 too). It is intermittent--sometimes when it launches everything works great, most times it gets stuck talking to my server in SSLv3 mode instead of TLSv1 (verified with %{SSL_PROTOCOL}x in the Apache log format directive).

Comment 5

[Kai Engert [:KaiE:]]

Maybe we still have a race related to TLS-intolerance fallbacks.

Comment 6

[Dana Keeler (she/her) [:keeler]]

Firefox doesn't support SSL 3 anymore.