Bug 52703 - SSL+SNI+client-auth "lost" after some time
Summary: SSL+SNI+client-auth "lost" after some time
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.2.16
Hardware: All All
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
: 52631 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-02-18 03:14 UTC by Christoph Anton Mitterer
Modified: 2018-11-07 21:09 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2012-02-18 03:14:28 UTC
Hi.

This is a really weird problem. I'm actually not sure whether it's a bug in Apache (or the browsers) but, having absolutely no idea, I need some point to start (sorry).

It is similar (and may be related to #52631). It happens with Firefox and Chromium.


Setup is the following:
I'm using SSL with SNI and SSL client authentication required.
I have fakeBasicAuth enabled.

I go to the site, I'm asked for my certificate, I'm granted access,.. so far everything fine.

But after some time (haven't measured it, about in the range of 10 minutes), when I click reload, or any link within the same site, the access is forbidden and I get HTTP 403.
It seems as if the SSL session would still be open (the browsers show their coloured address and there is no client cert or other SSL error).

Looking in the vhost's log I see:
[Sat Feb 18 04:08:23 2012] [error] No hostname was provided via SNI for a name based virtual host
[Sat Feb 18 04:08:23 2012] [error] No hostname was provided via SNI for a name based virtual host

and in the server wide error log:
at Feb 18 04:08:22 2012] [info] [client 91.8.39.109] Connection to child 84 established (server localhost:443)
[Sat Feb 18 04:08:22 2012] [info] Seeding PRNG with 1312 bytes of entropy
[Sat Feb 18 04:08:23 2012] [info] [client 91.8.39.109] Connection to child 17 established (server localhost:443)
[Sat Feb 18 04:08:23 2012] [info] Seeding PRNG with 1312 bytes of entropy
[Sat Feb 18 04:08:23 2012] [info] [client 91.8.39.109] Connection to child 213 established (server localhost:443)
[Sat Feb 18 04:08:23 2012] [info] Seeding PRNG with 1312 bytes of entropy
[Sat Feb 18 04:08:23 2012] [info] [client 91.8.39.109] Connection to child 148 established (server localhost:443)
[Sat Feb 18 04:08:23 2012] [info] Seeding PRNG with 1312 bytes of entropy
[Sat Feb 18 04:08:23 2012] [info] [client 91.8.39.109] Connection to child 83 established (server localhost:443)
[Sat Feb 18 04:08:23 2012] [info] Seeding PRNG with 1312 bytes of entropy
[Sat Feb 18 04:08:23 2012] [info] [client 91.8.39.109] Connection to child 11 established (server localhost:443)
[Sat Feb 18 04:08:23 2012] [info] Seeding PRNG with 1312 bytes of entropy
[Sat Feb 18 04:08:23 2012] [info] [client 91.8.39.109] Connection closed to child 84 with standard shutdown (server localhost:443)
[Sat Feb 18 04:08:23 2012] [info] [client 91.8.39.109] Connection closed to child 11 with standard shutdown (server localhost:443)
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] Request header read timeout
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] (70007)The timeout specified has expired: SSL input filter read failed.
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] Connection closed to child 17 with standard shutdown (server localhost:443)
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] Request header read timeout
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] (70007)The timeout specified has expired: SSL input filter read failed.
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] Connection closed to child 213 with standard shutdown (server localhost:443)
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] Request header read timeout
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] (70007)The timeout specified has expired: SSL input filter read failed.
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] Connection closed to child 148 with standard shutdown (server localhost:443)
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] Request header read timeout
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] (70007)The timeout specified has expired: SSL input filter read failed.
[Sat Feb 18 04:08:33 2012] [info] [client 91.8.39.109] Connection closed to child 83 with standard shutdown (server localhost:443)


...for every tried access.
The times of both log output correspond (both from the same access).
Not sure what this timeout from the server log is,.. but I guess it's due to my use of RequestReadTimeout, could that be?!


When I restart Apache and try it again with both browsers it still doesn't work again (still get 403, but still the SSL session seems to be successfully created).


The only way to get it working again, is to close the browsers and start again, or with firefox, to clear all "Active Logons".


Now I have absolutely no idea where to start tracing,... not even whether this seems to be more a browser issue or a server issue.
Just some indication that some timeout or cache that runs out could be the reason.


Any ideas?


Cheers,
Chris.
Comment 1 Eric Covener 2012-02-18 12:07:32 UTC
You're using bugzilla for support and discussion, but it is to be used strictly for reporting bugs.  Discuss your issue on a mailing list until it can be distilled to an actual bug with supporting doc.

http://httpd.apache.org/lists.html#http-users
Comment 2 Christoph Anton Mitterer 2012-02-19 19:02:32 UTC
For the records:

I've opened tickets at...


Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=728715

and

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

about this issue.
Comment 3 Christoph Anton Mitterer 2012-03-03 00:44:00 UTC
I just found out that this issue, as well as #52631, is seemingly solved by setting
SSLSessionCache (https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslsessioncache) to it's default:
none
from my own setting (Debian's default):
SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)


I came to this idea via http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html ...

So SSLSessionCache is responsible for SSL Session resumption, right?!

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.


Eric et al, I guess this is enough proof that this is a bug as one could imagine from the beginning, right?! So reopening it.
Comment 4 Eric Covener 2012-03-03 01:12:08 UTC
So the "after some time" is the first time the session is attempted to be  resumed, or the first time it's attempted and fails or what?  What does a packet capture say?
Comment 5 Christoph Anton Mitterer 2012-03-03 01:25:31 UTC
>So the "after some time" is the first time the session is attempted
>to be resumed, or the first time it's attempted and fails or what?

As far as I can tell from my debugging: yes


>What does a packet capture say?

I've done already one in the past, which can be found in the attachments of:
https://bugzilla.mozilla.org/show_bug.cgi?id=728715

Is this useful (is it the same you want for https://issues.apache.org/bugzilla/show_bug.cgi?id=52631#c11)? If not what shall I do?
Comment 6 Eric Covener 2012-03-03 01:46:26 UTC
I clicked through.  In the failing case the client tries to resume the session and does not set a server_name extension in the handshake.  The resume seems to succeed (the session ID itself is not in the parsed trace, but the exchange is clearly very short).

Presumably openssl doesn't save/restore this info in the session, because it comes in on a part of the handshake that isn't abbreviated (initial client hello).

When the same client isn't trying to resume a session, it sends the server_name extension.

It does not seem to directly explain why the clients do the right thing with SSL session caching disabled, since all things being equal they should just continue down the "fail" case but with a new session created.

So in short, Apache uses the extension when it's present in the handshake.
Comment 7 Christoph Anton Mitterer 2012-03-03 02:02:11 UTC
So you mean basically, that this has to be a bug in the clients (that is NSS), right?

I thought session resumption would mean that the client doesn't have to send all information (including server_name) again?
Comment 8 Eric Covener 2012-03-03 02:46:45 UTC
The TLS extensions RFC (rfc6066?) says that when the session is resumed, the original extensions should be used.

Some related discussion here:
  http://rt.openssl.org/Ticket/Display.html?id=2019&user=guest&pass=guest
Comment 9 Christoph Anton Mitterer 2012-03-04 16:04:04 UTC
Hey Eric,

We've found out new hints, see https://bugzilla.mozilla.org/show_bug.cgi?id=728715 especially starting with comment 12.


There seem to be still some bugs hidden somewhere..

a) It does not work with SSL 3.0 and session resumption (SSLSessionCache) enabled.

b) It works however with TLS 1.0 AND session resumption (SSLSessionCache) enabled.
BUT:
There seem to be either a bug or documentation ambiguity in https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslprotocol :

"TLSv1 SSLv3"
seems to be different from
"+TLSv1 +SSLv3"

Could you possibly have a look? :)
Comment 10 Eric Covener 2012-03-04 16:18:16 UTC
> BUT:
> There seem to be either a bug or documentation ambiguity in
> https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslprotocol :
> 
> "TLSv1 SSLv3"
> seems to be different from
> "+TLSv1 +SSLv3"
> 

SSLProtocol doesn't treat two non-+/- options as being both enabled -- the last one wins as if they were on separate lines.
Comment 11 Eric Covener 2012-03-04 16:20:01 UTC
*** Bug 52631 has been marked as a duplicate of this bug. ***
Comment 12 Eric Covener 2012-03-04 16:27:16 UTC
Kaspar / drh -- does this split between sslv3 and tlsv1.0 in openssl make sense wrt the extended client hello extensions coming from the abbreviated handshake or the original handshake? 

Is it at odds with interpretation by NSS?
Comment 13 Christoph Anton Mitterer 2012-03-04 16:35:56 UTC
Hi Eric.

With respect to comment #10, I've submitted bug #52821.

This explains why it didn't work for me with TLS 1.0 (as TLS 1.0 was simply not
used)


Nevertheless, it's still open why it doesn't work with SSL 3.0, so until that
is found out, please keep the bug open.
If it's a problem in NSS, I'll take care to close the Apache bug here, once
everything is solved.

Thanks.
Comment 14 Eric Covener 2012-03-04 19:06:03 UTC
Include an update her summarizing the SSLv3 problem, specifically whether it is an issue in full handshakes, abbreviated/resumed handshakes, and where your client sets the server_name extension (initial handshake, resumed handshake).
Comment 15 Christoph Anton Mitterer 2012-03-16 00:06:06 UTC
Hi Eric.

Is there still something required from your side?

At least the corresponding NSS bug (https://bugzilla.mozilla.org/show_bug.cgi?id=728715) was closed today.


Chris.
Comment 16 William A. Rowe Jr. 2018-11-07 21:09:54 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.