1511989 - consider enabling TLS 1.3 post-handshake authentication if/when NSS implements it

Status: RESOLVED FIXED

(Core :: Security: PSM, defect, P5)

Description

[Craig]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

Go to a URL that requires TLS 1.3 post-handshake authentication.

This can be tested by using Apache 2.4.37 (or later) ensuring that TLS 1.3 is enabled (which it is by default if OpenSSL 1.1 is used to build Apache), and using "SSLVerifyClient require" inside of a Location or Directory section. For example:
---
SSLCACertificateFile /etc/ssl/DoD_CAs.pem
SSLOCSPEnable on
<Directory /var/www/localhost/htdocs/cac>
        SSLOptions +StrictRequire
        SSLRequireSSL
        SSLVerifyClient require
        SSLVerifyDepth  10
        SSLOptions +FakeBasicAuth
</Directory>
---
See https://bz.apache.org/bugzilla/show_bug.cgi?id=62975 for this issue being reported in Apache (which is invalid; the problem is in Firefox).

Please feel free to test this behavior at https://www.integralblue.com/testhandshake/


Actual results:

An Apache error page is generated with this text:
---
You don't have permission to access /testhandshake/ on this server.
Reason: Cannot perform Post-Handshake Authentication.
---


Expected results:

Firefox should have performed client certificate authentication (such as asking for the PIN for my smartcard).

Comment 1

[Craig]

The same issue occurs in Chrome; this issue has been reported to Chromium at https://bugs.chromium.org/p/chromium/issues/detail?id=911653

Comment 2

[Daiki Ueno [:ueno]]

Attachment: Bug 1511989, enable TLS 1.3 post-handshake authentication

This adds a config option to enable client authentication through the TLS 1.3 post-handshake auth mechanism.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1bb8ad865648
enable TLS 1.3 post-handshake authentication r=keeler

Comment 4

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/1bb8ad865648

Comment 5

[Graham Leggett]

This bug is closed and marked fixed, but still occurs on Firefox 78.4.0esr (64-bit).

Did this regress?

Comment 6

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

This bug only added the ability to turn it on, given that there are some pending issues. If you want it, set security.tls.enable_post_handshake_auth to true in about:config.

Comment 7

[najqvashyxvzeszhib]

I think there are now larger problems, at least in Firefox for Android. In recent versions of Firefox for Android (version 80 or higher, at least), setting security.tls.enable_post_handshake_auth to true in about:config doesn't work. First, you have to use the Firefox nightly to even get the option to set the value, because in the regular Firefox Daylight, about:config doesn't work. But in the nightly, if you set security.tls.enable_post_handshake_auth to true, you no longer get the post-handshake error, but instead you get a Firefox error when going to a site that needs it. The new error says: "Secure Connection Failed. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of the problem." You then have the option of clicking on "Advanced", and then you get "Someone could be trying to impersonate the site and you should not continue. Websites prove their identity via certificates. Firefox Nightly does not trust <website url> because its certificate issuer is unknown, the certificate is self-signed, or the server is not sending the correct intermediate certificates." (This is all bogus, as the same site currently works in Firefox for Android 68, after setting the option in about:config. Furthermore the client cert is self-signed of course, but not the main SSL cert on the server.) Finally, I am shown an option to "Accept the Risk and Continue". If I click that, I get returned to the original "Secure Connection Failed" error. The error is simply looping.

It should be noted that this still happens, after following the instructions, found at https://fingers.today/tech/import-p12-client-cert-firefox-android for importing the client cert into Firefox.

It seems that in recent versions of Firefox for Android, at least, this problem is actually worse than in version 68.

Comment 8

[Hubert Kario]

@najqvashyxvzeszhib

that sounds like a regression, please file a new bug

Comment 9

[Halton Huo]

(In reply to najqvashyxvzeszhib from comment #7)

Firefox Nightly does not trust <website url> because its certificate issuer is unknown, the certificate is self-signed, or the server is not sending the correct intermediate certificates." (This is all bogus, as the same site currently works in Firefox for Android 68, after setting the option in about:config. Furthermore the client cert is self-signed of course, but not the main SSL cert on the server.) Finally, I am shown an option to "Accept the Risk and Continue". If I click that, I get returned to the original "Secure Connection Failed" error. The error is simply looping.

The test web site (https://www.integralblue.com/testhandshake/) is now updated with let's encrypt cert, should be resolved.

Comment 10

[Philip Prindeville]

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #6)

This bug only added the ability to turn it on, given that there are some pending issues. If you want it, set security.tls.enable_post_handshake_auth to true in about:config.

What's the reason to not have this be the default?

Comment 11

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

Bug 1637754. See also the discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=911653#c7