Shameless plug: Check out my Certificate Transparency monitor at https://www.merklemap.com The scale is massive, I just crossed 100B rows in the main database! :)
Certificate Transparency in Firefox
101–110 of 116 posts
Re: Certificate Transparency in Firefox
#102Earlier quoted context omitted.
That is kind of the value proposition for DANE though.
What prevents me from putting the hash of the public key of my public CA certificate into the TLSA record? Nothing. What prevents clients from checking both that the public CA based certificate I'm showing is valid and is present on CT, as well as that it's hashes to the same value I have placed into the TLSA record? Also nothing. Am I grossly misunderstanding something here? Feels like I missed a meta.
In terms of what you are saying, i think the main objection would be that HPKP feels a lot easier then putting it in DNS and we couldnt even get that to work. Otoh maybe dns could do a lot lower ttl which would counter some of the risks.
Re: Certificate Transparency in Firefox
#103Re: Certificate Transparency in Firefox
#104I have had the flag to enable this setting enabled for quite some time. It’s never caused any issues. I have only seen it pop-up once- for a cert that I had just issued a second prior. The cert was logged properly and the page loaded another second later. Very quick.
Hmm. Possibly a timing issue? It is conventional to slightly "back date" certificates so that they claim to have been issued an hour ago, as obviously if users forgot to adjust a PC for the clocks changing your site should still work & it was seen as easier to just back date the certificates. However for SCTs because the log has a Maximum Merge Delay conventionally set to 24 hours - so such back dating gives you 1 hour less to fix any technical problems - if you miss that 24 hour deadline you're out and must start over. So we do not back date SCTs.
Thus if your system had the time slightly wrong (say, off by 10 seconds) but had Transparency checks enabled I can imagine it would reject a freshly issued cert because the certificate says it was issued almost an hour ago but the SCTs are in the near future.
Re: Certificate Transparency in Firefox
#105Earlier quoted context omitted.
As of now, such stricter certificate requirements only apply to publicly trusted CAs that ship with the browser. Custom-added CAs are not subject to these requirements—this applies to all major browsers. I haven't tested Firefox's implementation yet, but I expect your private CA to continue working as expected since it is manually added. Private CAs can: * Issue longer certificates, even 500 years if you want. Public…
Public CAs are currently limited to 398 days (effectively 13 months).
As the maximum expiry shrank (to improve agility and encourage automation) the slack for granting such extra periods shrank too, withh "3 years" it was actually 39 months, maybe a bit more depending on how you squint, now it's exactly 398 days because Apple said so.
Re: Certificate Transparency in Firefox
#106Earlier quoted context omitted.
135.0.1 on Ubuntu is warning me. Maybe Mozilla is doing a delayed rollout? For context, in about:config my security.pki.certificate_transparency.mode is set to 2. According to https://wiki.mozilla.org/SecurityEngineering/Certificate_Tra... if it's on 0 (disabled) or 1 (not enforcing, collecting telemetry only), you can enable it. I can imagine Mozilla setting that setting to 1 by default (collecting telemetry on site…
Does the browser actually communicate with any external service for enforcing CT? I was under the impression it just checked the certificate for an inclusion proof, and actual monitoring of consistency between these proofs and logs is done by non-browser entities.
This would detect e.g. US government forces Google's log to cover up a CIA-obtained certificate for north-korean-military.example so it works fine for visitors, but the Korean's can't see it in the public logs. There's no sign that anything like this has ever happened, but in theory it would be easier to pull off since gossip is not implemented.
Re: Certificate Transparency in Firefox
#107In theory it is good, but somehow it is also a big threat to privacy and security of your infrastructure. No need anymore to scan your network to map the complete endpoints of your infrastructure! And it's a new single point of control and failure!
> In theory it is good, but somehow it is also a big threat to privacy and security of your infrastructure. This is silly. Certificates have to be in CT logs regardless of if firefox valudates or not. Additionally this doesnt apply to private CAs, so internal infrastructure is probably not affected unless you are using public web pki on them.
Certificate logging is not mandatory, none of the Root Programmes (agreements with typically browser vendors to recognise your CA roots) require logging. Now, in practice the browsers may reject certificates if they aren't presented a logging proof (in the certificate or stapled to it by the protocol, or some other means) but that's not a violation of your agreement with the vendor.
Most CAs (obviously including ISRG / Let's Encrypt) always log every certificate, but some either have programmes where you can pick or legacy systems which just don't do this. You can log such a certificate yourself, if you want, and then staple the receipts to your connection setup - but most people don't know how and don't want to learn.
Re: Certificate Transparency in Firefox
#108Earlier quoted context omitted.
That is kind of the value proposition for DANE though.
What prevents me from putting the hash of the public key of my public CA certificate into the TLSA record? Nothing. What prevents clients from checking both that the public CA based certificate I'm showing is valid and is present on CT, as well as that it's hashes to the same value I have placed into the TLSA record? Also nothing. Am I grossly misunderstanding something here? Feels like I missed a meta.
Re: Certificate Transparency in Firefox
#109I am on Debian Firefox 135.0.1 and https://no-sct.badssl.com/ doesn't error out as expected. Is Debian doing something different?
I do get the warning using the same Firefox version on Windows. Note that the link in the article is mangled. The link text is https://no-sct.badssl.com/ >, but the actual href points to https://certificate.transparency.dev/useragents/ >. Your comment has the correct link which gives the warning.
Re: Certificate Transparency in Firefox
#110Highlight point: They are just using Chrome's transparency logs. Yet again, Firefox chooses to be subservient to Google's view of the world.