651897 - Firefox 4.0 regression: conditional URL-based client certificate requirement

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[Marti Raudsepp]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20110321 Firefox/4.0
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20110321 Firefox/4.0

This was also reported on the Firefox support site: https://support.mozilla.com/en-US/questions/811718

When a web server is configured to require client certificates conditionally -- e.g. only for certain URLs, then it breaks the next un-authenticated request *after* the authenticated request. When it was a page request, Firefox refuses the renegotiation and displays the usual SSL error screen with error code "ssl_error_handshake_unexpected_alert". However, if the authenticated page doesn't redirect, it can also manifest in failing to load some media file (CSS or JS). After a refresh everything will work again, because it creates a new non-client-authenticated SSL session.

Apache logs the following error every time:
[Thu Apr 21 19:48:04 2011] [error] [client X.Y.Z.W] Re-negotiation handshake failed: Not accepted by client!?, referer: https://example.org/

An example Apache configuration to reproduce this error looks like this:
<VirtualHost MY-IP-ADDRESS:443>
  SSLEngine on
  SSLCertificateFile ...
  SSLCertificateKeyFile ...
  <Location ~ "^/cert-login/">
    SSLCACertificatePath /path/to/ca
    SSLVerifyClient require
    SSLVerifyDepth  2
  </Location>
</VirtualHost>


Reproducible: Always

Actual Results:  
SSL error page with ssl_error_handshake_unexpected_alert

Expected Results:  
Loading the un-authenticated page

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Does your server support secure renegotiation?

To check, go to https://www.ssllabs.com/, put your server's domain name into the "Test Your SSL Server Now!" input box, and click Submit. SSLLabs will do a bunch of tests which take a while. Afterwards, in the report you will see a line in the "Miscellaneous" section called "Renegotiation", with the value "Secure Renegotiation Supported." If you see something else, then your server doesn't support secure renegotiation; enabling it to resolve this issue. How you enable it depends on the server and/or SSL accelerator (load balancer) you are using. 

If your server already supports secure renegotiation or enabling secure renegotiation doesn't help, then it might be a bug in Firefox.

Either way, please post a reply in this bug with the results of your testing.

Comment 2

[Marti Raudsepp]

Thanks. Yes, the SSL Labs test says "This server supports secure renegotiation" and scores 85%.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

What was the latest version of Firefox that worked? 3.6? Do you know if any of the 4.0 betas worked?

Comment 4

[Marti Raudsepp]

Yeah, Firefox 3.6.8 - 3.6.10 don't have this problem.

The earliest 4.0 version where I tried smartcard authentication was IIRC around RC 10 or 11 and that was already broken.

Comment 5

[Marti Raudsepp]

I'm not at all familiar with the Firefox codebase, but is there anything I can do to help solve this problem?

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to comment #5)
> I'm not at all familiar with the Firefox codebase, but is there anything I can
> do to help solve this problem?

We need a test case that we can use, and the certificates to test it. I don't want to build the test case on your production system. If somebody could post a set of Apache(?) configuration files and instructions for generating the necessary certs and keys--without any sensitive info that would compromise their production systems' security--that would give us a great head-start in figuring out what is wrong.

Comment 7

[Marti Raudsepp]

Attachment: Configuration package to reproduce the bug

This tarball contains files necessary to reproduce said bug.

1. Copy all files from the archive to /tmp/certtest/
2. Drop certtest.conf to your Apache vhosts directory -- on Ubuntu/Debian that's /etc/apache2/sites-enabled
3. Enable Apache 'ssl' and 'alias' modules if necessary, restart Apache
4. Install /tmp/some_user_cert.pfx as a Firefox client certificate
5. Navigate to https://127.0.0.1:8443/ and accept the self-signed server certificate
6. The page should open -- if it's a 404 page then everything went OK, doesn't matter for our test
7. Enter the URL https://127.0.0.1:8443/cert
8. Observe that the request to /cert went fine, but when the server redirects you back to /, Firefox refuses re-negotiation and displays the "ssl_error_handshake_unexpected_alert" page
9. A simple refresh fixes the error.
10. Observe message in Apache logs: [error] [client 127.0.0.1] Re-negotiation handshake failed: Not accepted by client!?

Comment 8

[u279076]

Marti, can you try using the following tool to identify a regression range for this bug?

http://harthur.github.com/mozregression/

Thanks

Comment 9

[Thomas Ahlblom]

The problem has now disappeared in Nightly:

Last bad nightly: 2011-05-05 First good nightly: 2011-05-06
Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=31879b88cc82&tochange=88fdbd974f82

Further track down with Tinderbox
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2f2d4de42515&tochange=92d5e760e0c0

Comment 10

[Thomas Ahlblom]

Reproduced:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17
Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Mozilla/5.0 (X11; Linux x86_64; rv:5.0a2) Gecko/20110524 Firefox/5.0a2
Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101 Firefox/5.0

WFM:
Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110527 Firefox/7.0a1

Comment 11

[Thomas Ahlblom]

(In reply to comment #4)
> Yeah, Firefox 3.6.8 - 3.6.10 don't have this problem.

I've used the testcase in comment 7, but even 3.6.8 - 3.6.10 seem broken to me and so far I've not found an old version that works for me.

Thus, reproduced:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
h

Comment 12

[Thomas Ahlblom]

Local track down with GNU/Linux shows when Nightly went good.

The first good revision is:
changeset:   68988:29f3dc7ad5db
user:        Kai Engert <[e-mail]>
date:        Thu May 05 16:35:11 2011 +0200
summary:     Bug 642148 - Upgrade Mozilla to NSPR 4.8.8 beta 3 and NSS 3.12.10 beta 1, r=wtc, r=kaie

Comment 13

[Thomas Ahlblom]

Marti, can you please confirm that this bug isn't an issue any more using recent versions of Firefox?

Comment 14

[Marti Raudsepp]

Yes, this problem has been fixed for a while now. Sorry that I forgot to update this bug.