Live data from Hacker News

Certificate Transparency in Firefox

blog.transparency.dev

101–110 of 116 posts

Re: Certificate Transparency in Firefox

#102
post #73

Earlier 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.

Nothing saying you can't, just when people talk about DANE that is usually not what they are proposing.

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

#103
post #12

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! :)

Why not use something like crt.sh?

Why not use something like Merklemap?

Re: Certificate Transparency in Firefox

#104

I 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.

> 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.

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

#105
post #85
post #59

Earlier 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).

For anybody wondering: The weird amount of time is because with a commercial CA it needs to be possible to "carry" some validity during renewal. If I need a $10 Doodad and they're valid for exactly one calendar year, if I renew the Doodad on Monday instead of the following Sunday because I know I'll forget at the weekend, I am losing almost 20¢ of value. People get disproportionately passionate about stuff like this. So, the CAs credited your remaining time on the previous certificate - if you renewed with them, if you had six weeks to go but renewed a 3 year cert early you'd get issued a 3 years + 6 weeks cert.

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

#106
post #64

Earlier 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.

I assume Firefox doesn't implement this but one idea at the core of a full CT system is "gossip". Suppose your browser visits a site which has Dodgy Cert which has a bogus SCT, there should be some chance that the browser tells other people who care, maybe it anonymously sends some info to a gossip integrator. Browsers don't check that every SCT they see makes consistent sense, if your browser is shown two SCTs which could not exist in the same universe it won't realise - but the hypothetical gossip integrator can see if any browsers sampled any SCTs which are not mutually coherent and raise alarms.

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

#107
post #72

In 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.

technically incorrect which is presumably the best kind of incorrect?

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

#108
post #73

Earlier 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.

What benefit would that provide? It's just one more thing that has to be constantly maintained and could break while providing very little additional security.

Re: Certificate Transparency in Firefox

#109
post #33

I 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.

Thanks for the correct link! It doesn't trigger the warning on the latest Firefox android though :(
Post reply on HN