Firefox 4.0 regression: conditional URL-based client certificate requirement

RESOLVED WORKSFORME

Status

()

Core
Security: PSM
RESOLVED WORKSFORME
7 years ago
2 years ago

People

(Reporter: Marti Raudsepp, Unassigned)

Tracking

({qawanted, regression})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bugday-2011-05-27])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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

Updated

7 years ago
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
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.
(Reporter)

Comment 2

7 years ago
Thanks. Yes, the SSL Labs test says "This server supports secure renegotiation" and scores 85%.
What was the latest version of Firefox that worked? 3.6? Do you know if any of the 4.0 betas worked?
Keywords: regression
(Reporter)

Comment 4

7 years ago
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.
Keywords: qawanted, regressionwindow-wanted
(Reporter)

Comment 5

7 years ago
I'm not at all familiar with the Firefox codebase, but is there anything I can do to help solve this problem?
(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.
(Reporter)

Comment 7

7 years ago
Created attachment 528818 [details]
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!?
Marti, can you try using the following tool to identify a regression range for this bug?

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

Thanks

Comment 9

7 years ago
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
Whiteboard: [bugday-2011-05-27]

Comment 10

7 years ago
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

7 years ago
(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

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

The first good revision is:
changeset:   68988:29f3dc7ad5db
user:        Kai Engert <kaie@kuix.de>
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

6 years ago
Marti, can you please confirm that this bug isn't an issue any more using recent versions of Firefox?
(Reporter)

Comment 14

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

Updated

6 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Depends on: 642148
Resolution: --- → WORKSFORME
Keywords: regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.