Closed Bug 728713 Opened 13 years ago Closed 13 years ago

SSL / SNI accesses don't work the first time the vhost is accessed

Categories

(Firefox :: Untriaged, defect)

Product:
Firefox
Component:
Untriaged
Version:
10 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 728715

People

(Reporter: calestyo, Unassigned)

References

(
URL
)

Details

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). When I have the website in Firefox and/or Chromium opened (correctly) and I restart Apache, then the next reload of _both_ (!!!) browsers won't work but will lead me to the default name based vhost (which has then a different certificate, which of course doesn't verify). Subsequent reloads work again and bring me to the non-default name based vhost. BUT.... when I have the browsers closed and do the restart,... and then open the browsers (either of them or both) it works for them. So it seems as if this wouldn't be just some internal Apache issue, but really how the Apache+Browser plays with each other. I've already opened a ticket at Apache's bugzilla about that issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=52631#add_comment 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.
I've reported the same issue now at Chromium: https://code.google.com/p/chromium/issues/detail?id=114943
When you are doing the reload, are you doing just a reload, or a force clear the browser cache reload (like shift+click on the reload icon or CRTL+F5)?
Please set the environment variable "NSS_SSL_CBC_RANDOM_IV=0" and test again.
Now that I think about it, that will most likely make no difference. This is either just an unfortunate side-effect of the way SSL is defined to work or a server-side issue. I fail to understand how a re-configuration on the server side that is not picked up could possibly be a browser side issue.
Oh given what I just said, I bet the issue is that if the same relative URL exists with both virtual host names, you should be issuing a touch on the files in the new VM you just created to ensure that a modified since query will return the updated content, otherwise the browser will access what is in the cache.
I've just reported a similar (but not sure whether they have really anything in common) issue: https://bugzilla.mozilla.org/show_bug.cgi?id=728715
I've just tried the force reload by Ctrl-F5 and by clicking on the icon (each time I first loaded the page (successfully) then restarted the webserver, then reloaded (failed)). This made no difference. I still got the certificate error, as the wrong vhost was chosen. I do not get any "no SNI host name sent" errors... rather the following... In the Apache error log of the default name based vhost: --- first successful load ---------------------------- [Sun Feb 19 20:14:02 2012] [info] [client 188.174.212.187] Connection to child 64 established (server b.http.srv.scientia.net:443) [Sun Feb 19 20:14:02 2012] [info] Seeding PRNG with 1312 bytes of entropy [Sun Feb 19 20:14:02 2012] [info] [client 188.174.212.187] Connection to child 1 established (server b.http.srv.scientia.net:443) [Sun Feb 19 20:14:02 2012] [info] Seeding PRNG with 1312 bytes of entropy [Sun Feb 19 20:14:02 2012] [info] [client 188.174.212.187] Connection to child 133 established (server b.http.srv.scientia.net:443) [Sun Feb 19 20:14:02 2012] [info] Seeding PRNG with 1312 bytes of entropy [Sun Feb 19 20:14:02 2012] [info] [client 188.174.212.187] Connection to child 65 established (server b.http.srv.scientia.net:443) [Sun Feb 19 20:14:02 2012] [info] Seeding PRNG with 1312 bytes of entropy [Sun Feb 19 20:14:02 2012] [info] [client 188.174.212.187] Connection to child 16 established (server b.http.srv.scientia.net:443) [Sun Feb 19 20:14:02 2012] [info] Seeding PRNG with 1312 bytes of entropy --- apache restart ---------------------------- [Sun Feb 19 20:14:07 2012] [info] [client 188.174.212.187] Connection closed to child 16 with standard shutdown (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:07 2012] [info] [client 188.174.212.187] Connection closed to child 1 with standard shutdown (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:07 2012] [info] [client 188.174.212.187] Connection closed to child 65 with standard shutdown (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:07 2012] [info] [client 188.174.212.187] Connection closed to child 133 with standard shutdown (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:08 2012] [info] [client 188.174.212.187] (70007)The timeout specified has expired: SSL input filter read failed. [Sun Feb 19 20:14:08 2012] [info] [client 188.174.212.187] Connection closed to child 64 with standard shutdown (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:12 2012] [info] removed PID file /var/run/apache2.pid (pid=30512) [Sun Feb 19 20:14:12 2012] [notice] caught SIGTERM, shutting down [Sun Feb 19 20:14:13 2012] [info] Init: Seeding PRNG with 1312 bytes of entropy [Sun Feb 19 20:14:13 2012] [info] Loading certificate & private key of SSL-aware server [Sun Feb 19 20:14:13 2012] [info] Loading certificate & private key of SSL-aware server [Sun Feb 19 20:14:13 2012] [info] Init: Generating temporary RSA private keys (512/1024 bits) [Sun Feb 19 20:14:13 2012] [info] Init: Generating temporary DH parameters (512/1024 bits) [Sun Feb 19 20:14:13 2012] [info] Init: Initializing (virtual) servers for SSL [Sun Feb 19 20:14:13 2012] [info] Configuring server for SSL protocol [Sun Feb 19 20:14:13 2012] [info] Configuring server for SSL protocol [Sun Feb 19 20:14:13 2012] [info] mod_ssl/2.2.22 compiled against Server: Apache/2.2.22, Library: OpenSSL/1.0.0g [Sun Feb 19 20:14:13 2012] [info] Init: Seeding PRNG with 1312 bytes of entropy [Sun Feb 19 20:14:13 2012] [info] Loading certificate & private key of SSL-aware server [Sun Feb 19 20:14:13 2012] [info] Loading certificate & private key of SSL-aware server [Sun Feb 19 20:14:13 2012] [info] Init: Generating temporary RSA private keys (512/1024 bits) [Sun Feb 19 20:14:14 2012] [info] Init: Generating temporary DH parameters (512/1024 bits) [Sun Feb 19 20:14:14 2012] [info] Shared memory session cache initialised [Sun Feb 19 20:14:14 2012] [info] Init: Initializing (virtual) servers for SSL [Sun Feb 19 20:14:14 2012] [info] Configuring server for SSL protocol [Sun Feb 19 20:14:14 2012] [info] Configuring server for SSL protocol [Sun Feb 19 20:14:14 2012] [info] mod_ssl/2.2.22 compiled against Server: Apache/2.2.22, Library: OpenSSL/1.0.0g [Sun Feb 19 20:14:14 2012] [notice] Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.0g configured -- resuming normal operations [Sun Feb 19 20:14:14 2012] [info] Server built: Feb 1 2012 21:36:49 --- 2nd but failed load ---------------------------- [Sun Feb 19 20:14:20 2012] [info] [client 188.174.212.187] Connection to child 132 established (server b.http.srv.scientia.net:443) [Sun Feb 19 20:14:20 2012] [info] Seeding PRNG with 1312 bytes of entropy [Sun Feb 19 20:14:20 2012] [info] [client 188.174.212.187] SSL library error 1 in handshake (server b.http.srv.scientia.net:443) [Sun Feb 19 20:14:20 2012] [info] SSL Library Error: 336151570 error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate Subject CN in certificate not server name or identical to CA!? [Sun Feb 19 20:14:20 2012] [info] [client 188.174.212.187] Connection closed to child 132 with abortive shutdown (server b.http.srv.scientia.net:443) The log of the non-default name based vhost (the one where the website really is): --- first successful load ---------------------------- [Sun Feb 19 20:14:02 2012] [info] Initial (No.1) HTTPS request received for child 64 (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:02 2012] [info] Subsequent (No.2) HTTPS request received for child 64 (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:02 2012] [info] Initial (No.1) HTTPS request received for child 1 (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:02 2012] [info] Initial (No.1) HTTPS request received for child 133 (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:02 2012] [info] Initial (No.1) HTTPS request received for child 65 (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:02 2012] [info] Initial (No.1) HTTPS request received for child 16 (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:03 2012] [info] Subsequent (No.2) HTTPS request received for child 16 (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:03 2012] [info] Subsequent (No.3) HTTPS request received for child 64 (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:03 2012] [info] Subsequent (No.2) HTTPS request received for child 65 (server alpa-hydraulik-verladetechnik.de:443) [Sun Feb 19 20:14:03 2012] [info] Subsequent (No.3) HTTPS request received for child 16 (server alpa-hydraulik-verladetechnik.de:443) --- apache restart ---------------------------- --- 2nd but failed load ---------------------------- [Sun Feb 19 20:14:13 2012] [info] Loading certificate & private key of SSL-aware server [Sun Feb 19 20:14:13 2012] [info] Configuring server for SSL protocol [Sun Feb 19 20:14:13 2012] [info] RSA server certificate enables Server Gated Cryptography (SGC) [Sun Feb 19 20:14:13 2012] [info] Loading certificate & private key of SSL-aware server [Sun Feb 19 20:14:14 2012] [info] Configuring server for SSL protocol [Sun Feb 19 20:14:14 2012] [info] RSA server certificate enables Server Gated Cryptography (SGC)
btw: That website is publicly available. If you wanna try this out your self, we can meet in some instant messaging and correctly time the restart/reloading.
Next: 1) killall firefox-bin 2) export NSS_SSL_CBC_RANDOM_IV=0 3) firefox 4) went to the website (loaded correctly) 5) apache restarted 6) reload (Ctrl+R) 7) website loading failed (I got the default name based vhost, with the wrong cert) 8) next reload was successful again So settings that NSS variable didn't change things.
Bill, I'm not sure what you mean in comment 5. I have two port 443 vhosts... default name based vhost (b.http.srv.scientia.net: The DocumentRoot points just to an empty directory /var/www/empty non-default name based vhost (alpa-hydraulik-verladetechnik.de): The DocumentRoot points just to some /srv/www/foobar. There is effectively only a standard robots.txt in it. The actual content is served by plone, which is accessed via a ReverseProxy configuration in Apache. So there aren't the same relative URIs, are they? What do you mean should I touch?
I meant you should make sure that if the browser does a modified since date query (which is what it will do if you loaded the page previously before you changed the server configuration) the server will actually return new content because it has been modified since the last time it was loaded rather than deciding this content has not been changed since that date and will tell the browser to just use what is in the cache. Remember even though browsers normally do not cache data to disk for SSL requests, they DO still cache data to memory.
The data served by the vhost is not there in form of real files, but a reverse proxy setup, to a Zope/Plone server. How can I change the last modification date there?
I've just reported this https://issues.apache.org/bugzilla/show_bug.cgi?id=52631#c9 ... which seems to imply that SSL session resumption is responsible for this issue, as well as for #728715. 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.
This bug seems to have the same reasons as bug #728715 ... so I suggest to discuss anything further there (when it is NSS related) or at: https://issues.apache.org/bugzilla/show_bug.cgi?id=52703 (when it is Apache related).
marking as dupe of bug 728715. You have the same session resumption if you restart the server
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.