Closed Bug 1590888 Opened 5 years ago Closed 5 years ago

reinstate client certificate filtering (essentially revert bug 1267643)

Categories

(Core :: Security: PSM, task, P1)

Product:
Core
Component:
Security: PSM
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla72
Tracking Flags:
Tracking Status
firefox70 --- wontfix
firefox71 --- fixed
firefox72 --- fixed

People

(Reporter: keeler, Assigned: keeler)

References

Details

(Whiteboard: [psm-assigned])

Attachments

(1 file)

bug 1590888 - reinstate filtering of client certificate selection during the TLS handshake r?kjacobs
47 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta+
Details | Review

It turns out that not doing client certificate filtering (heeding the certificate_authorities list in the client certificate request from the server) is causing some usability issues. We'll have to reinstate that functionality for now (it was originally removed in bug 1267643).

Bug 1267643 removed filtering of client certificates based on the
"certificate_authorities" list sent in the client certificate request from the
server in TLS handshakes because it is impossible to implement as specified
without false negatives (i.e. excluding certificates that could be usable but
don't seem to be according to the certificates the client is aware of). In
practice, however, it seems enough users rely on this behavior that we should
add it back until the platform can save client certificate selections across
restarts and the "select one automatically" option is removed (see also bug
634697).

Then make the behavior configurable at least (using about:config for example), so that each user can chose for himself which behavior he prefers...

Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/be1569bfb0e5
reinstate filtering of client certificate selection during the TLS handshake r=kjacobs

https://hg.mozilla.org/mozilla-central/rev/be1569bfb0e5

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox72: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla72

Will a fix be released soon?

(In reply to Bozhan Bozhkov from comment #11)

Will a fix be released soon?

You can track the progress of this bug using the tracking flags in the Tracking section of this bug, near the top of the page.

Comment on attachment 9103738 [details]
bug 1590888 - reinstate filtering of client certificate selection during the TLS handshake r?kjacobs

Beta/Release Uplift Approval Request

  • User impact if declined: Automatic client certificate selection may not work correctly. Also, users visiting servers that request client certificates when the user doesn't actually have one that the server is interested in may get spammed by client certificate selection dialogs.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This patch reinstates previous behavior. While this isn't a direct backout (i.e. the implementation is new), the new code uses more modern, safer types, so this should actually be safer than what we had before. Plus, now it actually has meaningful test coverage.
  • String changes made/needed:
Attachment #9103738 - Flags: approval-mozilla-beta?

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

(In reply to Bozhan Bozhkov from comment #11)

Will a fix be released soon?

You can track the progress of this bug using the tracking flags in the Tracking section of this bug, near the top of the page.

Does that means, there will be no fix for the current version?

Comment on attachment 9103738 [details]
bug 1590888 - reinstate filtering of client certificate selection during the TLS handshake r?kjacobs

P1 regression in 70 with multiple duplicates, patch has tests and baked a few days in nightly, uplift approved for 71 beta 6, thanks.

Attachment #9103738 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

(In reply to Bozhan Bozhkov from comment #16)

Does that means, there will be no fix for the current version?

Probably not. You can use ESR 68 or beta in the meantime: https://www.mozilla.org/en-US/firefox/all/

The problem reported in bug 1592532 (marked as a duplicate of this one) still exists in Firefox 71 Beta 7.

When negotiating a TLS session with a smartcard that contains 2 certificates (one with Key Usage = Non-Reputiation and the other with Key Usage = Signing), it is the 'Non-Repudiation' certificate that is presented first in the drop-down list and therefore the certificate that is used 'by default' if the average user simply hits 'OK' because they know nothing about certificates. The session connection then fails with SSL_ERROR_UNSUPPORTED_CERT_ALERT.

To make matters worse, the 'Remember this decision' checkbox is selected by default so when the user attempts to reconnect to the site (which they would certainly do), it fails immediately without presenting the certificate selection dialog. Only when the user closes and restarts Firefox are they able to select a different certificate (if it occurs to them to do so). Remember that most users don't have knowledge of certificates/PKI principles.

This comment describes the regression very accurately: 'https://bugzilla.mozilla.org/show_bug.cgi?id=1592532#c11'. It makes much more sense to filter by 'Certificate Usage' in order to present certificates appropriate for the operation being attempted.

We provide the unique smartcard middleware to a french government agency in charge of the management of information systems for health care professionals and the agency provides several Web Portals for their users.

These portals require a client/server mutual authentication through the use of a smart card on the client side. A very significant number of these users are not enterprise users (doctors, nurses, dentists and all other healthcare professionals for example) and this will cause them serious problems due to this regression if the fix is not applied to the release version.

Flags: needinfo?(dkeeler)

Hi,

We have a governmental health smartcard used by more than 1.000.000 professionals. A great part of them will be impacted by Firefox 71 : our smartcard contains 2 certificates (1 for SSL authentication, 1 for signature) and our user profils aren't aware about certificate differences.

We are really concerned about this important issue of use cases and we have no workaround: all our users validate the default suggestion of certificate choice by Firefox as usual.

Could you prioritize a correction to avoid that all users are just wrong from December 3?

Thanks in advance,

Regards,

Thanks for the additional information. I've reopened that bug.
Incidentally, I recommend you have your users use the ESR branch of Firefox to help avoid these kinds of issues in the future: https://www.mozilla.org/en-US/firefox/enterprise/

Flags: needinfo?(dkeeler)

Thank you Dana.

Just an observation: bug 1592532 (ie., our original bug report that is a duplicate of this one) is still marked as resolving this issue in version 72 of Firefox and that Firefox 71 is 'affected'.

Thanks again for your responsiveness.
Paul.

Flags: needinfo?(dkeeler)

Hi Dana,

You right that Firefox ESR is a possible workaround but:

  • we have to contact all end user of Firefox 70 before december 3 to pass to Firefox ESR,
  • and we have to recontact them to pass to Firefox 72 later.

Our user are Healthcare people et aren't very aware about technology. We have to assist them at each step of installation process. We think that we have at least 60.000 daily users. That's why impact is really important for us.

Thank you for your involvement.

Regards,

Hi,
In our side we are in the same position. We are concerned by the same problem.
Because we work with Healthcare people too, Firefox ESR does not appear to be an easy solution to implement.

Thank you.

Regards.

Paul - before we uplift bug 1592532 to 71, it would be best to confirm it now works as expected. Can you download the latest version of Nightly and comment in that bug if it works? (https://www.mozilla.org/en-US/firefox/channel/desktop/) (same question to anyone following this bug, really)

Flags: needinfo?(dkeeler)

Hi Dana,

For us nightly [72.0a1 (2019-11-07) (64-bit)] works as expected, tested both of the site we use personal certificates to authenticate to offers the correct certificate in the selection box in the nightly and FF also chooses the correct one when on "Select one automatically". So i would say it works like it was before 70. (that is its not confusing healthcare/government workers)

Regard.

Dana.

As my colleage BPER said in bug 1592532, this is resolved in the latest nightly. I have tested the 64 bit version (on Win 10) as well.

Thank you.

Paul

Hi again.

I have also just tested the latest Nightly on macOS 10.14.6 (Mojave) and it is also functions as expected.

Paul.

Dana,

That's ok for us too: FF72 nightly.

Thank you.

Regards

Thanks for the confirmation!

FF72 nightly works for me with MacOS Catalina (10.15.1). Thank you for fixing it!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: