593066 - firefox should potentially clear remembered client authentication decisions upon (some) handshake failures

Status: NEW

(Core :: Security: PSM, enhancement, P3)

Description

[Henry Story]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

If the server rejects a client side certificate (past due date) Firefox reconnects with exactly the same certificate. This means that the server cannot get the user to change certificate if the user mistakenly chooses the wrong one.

Reproducible: Always

Steps to Reproduce:
1. download the mini test server that is open source at http://github.com/bblfish/TLS_test
 $  git clone http://github.com/bblfish/TLS_test.git

2. run it as explained in the README - it downloads apache jetty from maven central

3. Connect to http://localhost:8443/ 

4. You can select some of the exceptions made available by the Java VM, such as certificate being out of date, etc... And don't forget to reset the session by clicking the "reset ssl session" button.

5. click the "Set" button (could put a better name)

6. you will arrive on a page that shows that the session has been cleared, and that the exception will be thrown on the next connection.

7. click the next page button

5. When that is done
Actual Results:  
A1. The web browser shows a "Secure Connection Failed" page with a button "Try Again"
A2. If you click the Try Again button, the exact same certificate used previously is sent again.

Expected Results:  
Instead of A1. Firefox should immediately ask the user for a certificate selection box where he should be able to choose which certificate to use (he should be able to select the same one of course - so that we can do testing like this, though perhaps it should be moved to the back of the selection list)


The exceptions thrown by the JVM should produce error messages specified by the TLS rfc

http://tools.ietf.org/html/rfc4346#section-7.2

The codes are described in a little more detail here

http://tools.ietf.org/html/rfc4346#section-7.2.2

  bad_certificate
     A certificate was corrupt, contained signatures that did not
     verify correctly, etc.

  unsupported_certificate
     A certificate was of an unsupported type.

  certificate_revoked
     A certificate was revoked by its signer.

 certificate_expired
     A certificate has expired or is not currently valid.

  certificate_unknown
     Some other (unspecified) issue arose in processing the
     certificate, rendering it unacceptable.

Comment 1

[Henry Story]

of course that should be https://localhost:8443/ above, and jetty is not an apache project. Sorry for the typos.

Comment 2

[David Chadwick]

This is a serious error in my opinion, since it seriously inhibits the use of mutual authentication using client side certificates

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Changing severity to S4 because of it was never set according to the new system in the first place.