Certificate Transparency is now enforced in Firefox on desktop platforms starting with version 135

[Dana Keeler]

Hi folks,

Certificate Transparency is an important part of the web PKI that enables the detection of misissued certificates. Starting in Firefox 135, Certificate Transparency is now enforced on all desktop platforms. This means that Firefox now requires that TLS web server certificates issued from roots in Mozilla's Root CA program be accompanied by sufficient Certificate Transparency information (essentially, 2 SCTs) in order for TLS connections to succeed. Otherwise, Firefox will show the error "MOZILLA_PKIX_ERROR_INSUFFICIENT_CERTIFICATE_TRANSPARENCY".

In practice, this should require no particular changes on the part of website operators. If your site works in Chrome and Safari, it should work in Firefox as well. However, if you were making use of policies to exempt certain internal certificates or domains from CT, you will need to apply those policies to Firefox as well. See https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency#Enterprise_Policies

If you encounter any issues, please let us know or file a bug directly: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security%3A%20PSM

Thank you,

Dana

[Bas Westerbaan]

Congratulations! This is an important achievement. Thank you for the hard work.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAHP1u2ibhTB4r5YMZ6GNGo4Cr%2B5HQN3w-ULip6_ayX1aAzsH7A%40mail.gmail.com.

[Matthew McPherrin]

Congratulations!

As a CT log operator, do I need to begin submitting my new logs to Firefox, or will you take logs from the other programs?
As a CA, do you have a list of supported logs that we can validate against?

Thanks,

Matthew McPherrin
Let's Encrypt SRE

[Jan Schaumann]

"'Dana Keeler' via dev-secur...@mozilla.org" <dev-secur...@mozilla.org> wrote:

> Certificate Transparency is now enforced on all desktop platforms.

This is great news!

Could you clarify how this applies to custom CAs? The
language in your email could, I believe, be
interpreted in different ways:

> This means that Firefox now requires that TLS web
> server certificates issued from roots in Mozilla's
> Root CA program

This part suggests to me that this _only_ applies to
the CAs in the root program as shipped by Mozilla.
I.e., if I add my custom CA, certs issued by that will
_not_ be subject to this requirement.

> However, if you were making use of policies to
> exempt certain internal certificates or domains from
> CT, you will need to apply those policies to Firefox
> as well.

But this statement suggests that for my custom CA I
_do_ need to take action.

Sorry if this is obvious to everybody else, but if you
could clarify, that'd be much appreciated.

Thanks!
-Jan

[Dana Keeler]

> As a CT log operator, do I need to begin submitting my new logs to Firefox, or will you take logs from the other programs?

> As a CA, do you have a list of supported logs that we can validate against?

Currently Firefox derives the list of trusted logs from Google's list: https://www.gstatic.com/ct/log_list/v3/log_list.json

Should this ever change, we'll give plenty of notice.

To see what logs are in a particular version of Firefox, you can examine the history of https://searchfox.org/mozilla-central/source/security/ct/CTKnownLogs.h

[Dana Keeler]

> Could you clarify how this applies to custom CAs?

For CAs that are not part of Mozilla's Root CA program (in other words, CAs that are not built-ins shipped with Firefox), no certificate transparency information is required (in other words, for your custom CA, no action should be needed).

The use of policies to exempt internal certificates or domains applies to situations where a publicly-trusted CA was used to issue certificates for domains that are intended to be internal to an organization.

[Jan Schaumann]

Dana Keeler <dke...@mozilla.com> wrote:
> > Could you clarify how this applies to custom CAs?
>
> For CAs that are not part of Mozilla's Root CA program (in other words, CAs
> that are not built-ins shipped with Firefox), no certificate transparency
> information is required (in other words, for your custom CA, no action
> should be needed).
> The use of policies to exempt internal certificates or domains applies to
> situations where a publicly-trusted CA was used to issue certificates for
> domains that are intended to be internal to an organization.

Thanks, that makes it clear.

-Jan

[Jeremy Rowley]

I realize ekr is no longer part of Mozilla, but I am wondering on your thoughts on his previous dislike for CT? 

https://educatedguesswork.org/posts/transparency-part-2/

How did you overcome his criticisms? Did Mozilla just accept the CT shortcomings? I like CT personally, but I found his criticisms interesting and wanted to hear more about any discussion/decisions related to them. 

Congrats as well!

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/Z6KL1PP89G61L92e%40netmeister.org.

[Dana Keeler]

Personally, I don't think I fundamentally disagree with anything in that blog post. Much of the criticism seems to involve how complicated the design is in contrast to the relatively weak security properties we actually get out of the system as deployed. It helps that as a browser, we don't have to do the complicated Merkle tree stuff - we can just verify the SCTs as counter-signatures. That said, in the future we may want to run our own log, but that's a discussion for another time. Also, we should probably investigate some sort of privacy-preserving auditing mechanism, but again that's future work. I think our position can be summed up as "CT: Still Useful", as ekr says.