You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2012/02/18 04:14:28 UTC

DO NOT REPLY [Bug 52703] New: SSL+SNI+client-auth fakeBasicAuth "lost" after some time

https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

             Bug #: 52703
           Summary: SSL+SNI+client-auth fakeBasicAuth "lost" after some
                    time
           Product: Apache httpd-2
           Version: 2.2.16
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: mod_ssl
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: calestyo@scientia.net
    Classification: Unclassified


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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

Eric Covener <co...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #8 from Eric Covener <co...@gmail.com> 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

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

Eric Covener <co...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEEDINFO

--- Comment #4 from Eric Covener <co...@gmail.com> 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?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

--- Comment #15 from Christoph Anton Mitterer <ca...@scientia.net> 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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

--- Comment #11 from Eric Covener <co...@gmail.com> 2012-03-04 16:20:01 UTC ---
*** Bug 52631 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

--- Comment #13 from Christoph Anton Mitterer <ca...@scientia.net> 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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

Christoph Anton Mitterer <ca...@scientia.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|SSL+SNI+client-auth         |SSL+SNI+client-auth "lost"
                   |fakeBasicAuth "lost" after  |after some time
                   |some time                   |

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

Christoph Anton Mitterer <ca...@scientia.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #3 from Christoph Anton Mitterer <ca...@scientia.net> 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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

--- Comment #9 from Christoph Anton Mitterer <ca...@scientia.net> 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? :)

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

--- Comment #2 from Christoph Anton Mitterer <ca...@scientia.net> 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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

Eric Covener <co...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #14 from Eric Covener <co...@gmail.com> 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).

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

--- Comment #5 from Christoph Anton Mitterer <ca...@scientia.net> 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?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

--- Comment #10 from Eric Covener <co...@gmail.com> 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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth fakeBasicAuth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

Eric Covener <co...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Eric Covener <co...@gmail.com> 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

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


[Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

nada <ap...@valgronda.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |apache_bugzilla@valgronda.c
                   |                            |om

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

--- Comment #6 from Eric Covener <co...@gmail.com> 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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

--- Comment #12 from Eric Covener <co...@gmail.com> 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?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 52703] SSL+SNI+client-auth "lost" after some time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52703

--- Comment #7 from Christoph Anton Mitterer <ca...@scientia.net> 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?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org