115368 - Mozilla chokes on site using client+server SSL (particularly sending data)

Status: VERIFIED DUPLICATE of bug 139802

(Core Graveyard :: Security: UI, defect, P3)

Description

[Brice Ruth]

I recently set up 'Sqwebmail', a UNIX based web email retrieval & sending
system. To harden the system, I set it up so that the site was secured via SSL
and required the client to provide a valid certificate (signed by the server's
CA). As far as I can tell, all the security certificates are properly set up, as
they work fine in IE6. Here's basically what I did (details omitted)

1) created self-signed CA
2) created server cert signed by my CA
3) created client cert signed by my CA (.p12)
4) installed CA, server cert, server key in Apache
5) prepped CA for clients (pem -> der)
6) installed CA on Mozilla, successful
5) installed client cert in Mozilla via 'Restore' - certificate is accepted,
verified, and trusted
6) accessed site

Althought the client/server negotiation is INCREDIBLY slow via Mozilla (compared
with IE6 running on a slower computer 450MHz P3 vs. 400MHz PPC/G3, with far less
memory (256M vs. 768M on the G3), in VMware, while 'user-mode-linux' is running
a full debian installation ...) it does actually manage to bring up the page and
display the login. Initial login just puts me back at the login page, subsequent
login works fine (something is going on here where the login CGI isn't getting
the information properly from Mozilla, I only have to enter the login info once
via IE6). I can view mail, but composing and sending mail does not work.  The
CGI shunts me back to the login and I haven't been able to track down WHY.

This bug will take some analysis of both what's going on in Mozilla as well as
what's going on with the server. I'm more than happy to provide logs from the
server as well as access to the server via a temporary mail account that can be
accessed via this interface.  To properly test this, whoever will be debugging
this will need a client certificate signed by my CA. Generate the certificate
request like so:

$ openssl genrsa -out client.key 1024
$ openssl req -new -key client.key -out client.csr

OpenSSL on MacOS X or any other UNIX works fine, as should OpenSSL on Win32.

Not being able to use client+server SSL for webmail isn't necessarily a 'major'
problem, but I can see some valid uses for this and I imagine that it is
affected as well.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

->PSM

Comment 2

[Stephane Saux]

I use client auth everyday.
What build are you using.

Comment 3

[Brice Ruth]

Here's from about:mozilla

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.6+) Gecko/20011210

as you can see, a relatively recent build.  I don't think client auth in and of
itself is entirely broken, it just doesn't appear to be working correctly. Would
you like me to try on other platforms? I have Mandrake 8.1, Win95, Win98, Win2K,
MacOS 9.1, MacOS 9.2.1, and of course MacOS X at my disposal.

Comment 4

[Greg K.]

Brice, can you still reproduce this using RC1?

Comment 5

[Brice Ruth]

The short answer: yes, it still occurs with RC1 (build: 2002041805 on OS X,
v.10.1.4).

The long answer - here's some timing:

time to security device authentication prompt: 40s
time to page finished loading (via status bar timing): 176.22s

I've determined that one option in the Apache server's SSL configuration appears
to be key here: OptRenegotiate, which is short for optimize the SSL
renegotiation scheme. Here's the full description:

+++
* OptRenegotiate

This enables optimized SSL connection renegotiation handling when SSL directives
are used in per-directory context. By default a strict scheme is enabled where
every per-directory reconfiguration of SSL parameters causes a full SSL
renegotiation handshake. When this option is used mod_ssl tries to avoid
unnecessary handshakes by doing more granular (but still safe) parameter checks.
Nevertheless these granular checks sometimes maybe not what the user expects, so
enable this on a per-directory basis only, please.
+++

If I turn this on (via SSLOption +OptRenegotiate), I observe the following timings:

time to security device authentication prompt: 40s
time to page finished loading (via status bar timing): 46.22s

Yet, as far as my testing goes, IE6 is unaffected by this option. (?!?) It also
seems to me that 40s is an awfully long time to wait for Moz to prompt me to
authenticate my software security device ... what's causing that delay?

Comment 6

[Stephane Saux]

cc nelsonb.
javi

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

I can think of several possibilities here, including
a) something really wierd about the certs involved.  
b) the server in question is doing something that causes many many SSL
connections to be made beween client and server before a pager is evidently 
served,  e.g. redirecting many times, or closing the connection without
writing back any bytes to the client, which will typically cause the 
client to retry potentially many times.  

SSLtap output would reveal b.  Submittor, please attach copies of the 
relevant certs (either as DER or as base64 encoded DER) to this bug.
Without ssltap output and the certs, I doubt we'll ever know what's 
happening for this user.

Comment 8

[Brice Ruth]

OK, I think I'm going to need some help in providing you with the info you need.
One the server, I have three files, SSLCertificateFile, SSLCertificateKeyFile,
and SSLCACertificateFile. Which of these do you need? I *believe* they are all
in PEM format, also - so how do I get them to the DER format you need? I'm only
vaguely familiar with OpenSSL (basically enough to generate these files whilst
following directions) - do I need to use OpenSSL's pkcs7 tool to generate the
DER files?

On the client, I assume I only need to export my client cert from Moz, right?!?

Comment 9

[Brice Ruth]

Attachment: Brice Ruth's client-side certificate (PKCS12)

Here's the "backup" of my client-cert from Moz (no password)

Comment 10

[Brice Ruth]

FYI - someone should be able to import the client-side cert I posted and connect
to the following URL to experience the slowness I'm talking about:

http://webmail.webprojkt.com/

You don't need to login - the length of time it takes just for this first page
to appear should speak volumes! I have the "OptRenegotiate" option turned OFF
right now. I think, to fully test this bug, I may setup another virtual host so
that I can have one URL that has OptRenegotiate turned on and one that has it
turned off, running simultaneously (otherwise its kinda time-consuming to switch
the configuration around all the time :)).

Comment 11

[John Unruh]

Confirming on Mac OSX

Comment 12

[John G. Myers]

I think this and bug 139802 are duplicates.  I would think the OptRenegotiate
option is simply affecting the number of (overly expensive) full handshakes.

Comment 13

[Brice Ruth]

I think John's correct. Should someone with "the power(tm)" mark bug 139802 as a
dup of this one?

Comment 14

[John Unruh]

*** Bug 139802 has been marked as a duplicate of this bug. ***

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

While it may indeed be likely that these two bugs have the same cause,
I don't think there's proof of that yet.  Bug 139802 describes a problem
that can be measured, addressed, and fixed; namely the time required to 
do a single client authentication handshake.  So, I'd suggest that bug 
139802 be kept open, and this bug be marked to depend on that one.  Then
when that bug is fixed, someone can see if this bug is also fixed, and if
so, resolve this bug at that time. 

I will add some more comments to that bug suggesting some ways to approach it.

Comment 16

[Brice Ruth]

That sounds reasonable :)

Comment 17

[John Unruh]

*** This bug has been marked as a duplicate of 139802 ***

Comment 18

[Matt Perry]

Verified dupe