9 ms·

Certificate Transparency in Firefox

184 points by tracymiranda 2y ago

schoen 2y ago
Congratulations! That's terrific news.
joelthelion 2y ago
Can someone explain in a nutshell what CT is, and how does it help security for the average user?
- djaychela 2y ago
  There's a site for it here (linked 2 levels deep from the original article): https://certificate.transparency.dev/ https://certificate.transparency.dev/
- perching_aix 2y ago
  CT is an append-only distributed log for certificate issuances. People and client software can use it to check if a certificate is being provided by a trusted CA, if it has been revoked, or is being provided by multiple CAs (the latter possibly indicating CA compromise). CA meaning Certificate Authority, the organizations that issue certificates. This provides a further layer of technological defense to attempting the mitigation of your web browser traffic being intercepted and potentially tampered with. In practice a regular person is unlikely to run into this, because web PKI is mostly working as expected, so there's no reason for the edge cases to happen en masse. This change is covering one such edge case. No idea how the typical corporate interception solutions (e.g. Zscaler) circumvent it in other browsers where this check has long been implemented.
  - q2dg 2y ago
    Will Mitmproxy stop working?
    - notpushkin 2y ago
      Chrome treats certificates added by user as not requiring CT: https://github.com/mitmproxy/mitmproxy/discussions/5720 https://github.com/mitmproxy/mitmproxy/discussions/5720
      - zinekeller 2y ago
        And to wit, Firefox too: > Setting this preference to 2 causes Firefox to enforce CT for certificates issued by roots in Mozilla's Root CA Program.
    - perching_aix 2y ago
      I believe so. You'll need to disable CT enforcement / or add your SPKI hash to the ignore list in the browser settings temporarily to get it working. [0] I guess this is also how corporations get around this issue? Still unsure. [0] https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency https://wiki.mozilla.org/SecurityEngineering/Certificate_Tra...
      - mcpherrinm 2y ago
        No. CT is only required for public CAs. You only need those browser policy settings if you’re using a public CA without CT.
        perching_aix 2y ago
        I'd imagine this is why certs that terminate in root certificates manually added to the trust store will work fine then [as stated by other comments]?
        mcpherrinm 2y ago
        Right, any CA you add yourself that isn’t part of what Mozilla ships isn’t considered a publicly trusted CA.
- tgsovlerkhgsel 2y ago
  It's a public, tamper-proof log of all certificates issued. When a CA issues a certificate, it sends a copy to at least two different logs, gets a signed "receipt", and the receipt needs to be included in the certificate or browsers won't accept it. The log then publishes the certificate. This means that a CA cannot issue a certificate (that browsers would accept) without including it in the log. Even if a government compels a CA, someone compromises it, or even steals the CAs key, they'd have to either also do the same to two CT logs, or publish the misissued certificate. Operators of large web sites then can and should monitor the CT logs to make sure that nobody issued a certificate for their domains, and they can and will raise hell if they see that happen. If e.g. a government compels a CA to issue a MitM certificate, or a CA screws up and issues a fake cert, and this cert is only used to attack a single user, it would have been unlikely to be detected in the past (unless that user catches it, nobody else would know about the bad certificate). Now, this is no longer possible without letting the world know about the existence of the bad cert. There are also some interesting properties of the logs that make it harder for a government to compel the log to hide a certificate or to modify the log later. Essentially, you can store a hash representing the content of the log at any time, and then for any future state, the log can prove that the new state contains all the old contents. The "receipts" mentioned above (SCTs) are also a promise to include a certificate by a certain time, so if a log issues an SCT then publishes a new state more than a day later that doesn't include the certificate, that state + the SCT are proof that the log is bad.
  - brookst 2y ago
    Thanks for the great explanation of both tech design and real world benefits!
  - xg15 2y ago
    > Operators of large web sites then can and should monitor the CT logs to make sure that nobody issued a certificate for their domains, and they can and will raise hell if they see that happen. The tech is definitely an improvement from the previous situation, but I've always wondered about this step: Suppose you've found an unauthorized certificate for your site in the log (and you're not Google, Apple or Microsoft). Then what? What can you actually do about it?
- cyberax 2y ago
  Basically, a git repository for all the issues certificates.
MidnightRider39 2y ago
[flagged]
linwangg 2y ago
Great move! Curious to see how this will impact lesser-known CAs. Will this make it easier to detect misissued certs, or will enforcement still depend on browser policies?
- arccy 2y ago
  firefox is just catching up with what chrome implemented years ago. unless you have a site visited only by firefox users, ecosystem effect is likely to be minimal... though it does protect firefox users in the time between detection and remediation.
ozim 2y ago
Wonder why they say you should monitor transparency logs instead of setting up CAA records - malicious actors will most likely disregard CAA anyway.
- lambdaone 2y ago
  Let's not let the best be the enemy of the good. Malicious actors who disregard CAA would first have to have gone through the process of accreditation to be added to public trust stores, and then would quickly get removed from those trust stores as soon as the imposture was detected. So while creating a malicious CA and then ignoring CAA records is entirely possible for few-shot high-value attacks, it's not a scalable approach, and it means CAA offers at least partial protection against malicious actors forging certificates as a day-to-day activity. Transparency logs are of course better because they make it much easier for rogue CAs to be caught rapidly, but it's not a reason to abandon CAA until transparency log checking is universal, not just in browsers, but across the whole PKI ecosystem.
- mcpherrinm 2y ago
  In any security setting, it’s usually good to have both controls and detection. CAA records help prevent unexpected issuance, but what if your DNS server is compromised? DNSSEC might help. Certificate Transparency provides a detection mechanism. Also, unlike CAA records which are enforced only by policy that CAs must respect them, CT is technically enforced by browsers. So they are complimentary. A security-sensitive organization should have both.
- tgsovlerkhgsel 2y ago
  They're doing different things, and you should do both. Setting CAA records primarily serves to reduce your attack surface against vulnerable domain validation processes. If an attacker wants to specifically attack your domain, and you use CAA, the attacker now needs to find a vulnerability in your CA's domain validation process instead of any CAs validation process. If it works, it prevents an attacker from getting a valid cert. Monitoring CT logs only detects attacks after the fact, but will catch cases where CAs wrongly issued certificates despite CAA records, and if you monitor against a whitelist of your own known certificates, it will catch cases where someone got your CA to issue them a certificate, either by tricking the CA or compromising your infrastructure (most alerts you will actually see will be someone at your company just trying to get their job done without going through what you consider the proper channels, although I think you can now restrict CAA to a specific account for LetsEncrypt). Since CT is required now by browsers, an attacker that compromises (or compels!) a CA in any way would still have to log the cert or also compromise or compel at least two logs to issue SCTs (signed promises to include the cert in the log) without actually publishing the cert (this is unlikely to get caught but if it was, there would be signed proof that the log did wrong).
deleted 2y ago
[deleted]
Eikon 2y ago
Shameless plug: Check out my Certificate Transparency monitor at https://www.merklemap.com https://www.merklemap.com The scale is massive, I just crossed 100B rows in the main database! :)
- AznHisoka 2y ago
  Why do it only show a few subdomains for .statuspage.io? I would have expected at least 10K or so. https://www.merklemap.com/search?query=*.statuspage.io&page=0 https://www.merklemap.com/search?query=*.statuspage.io&page=... Is my query wrong or are you just showing less results intentionally if you’re not paying?
  - Eikon 2y ago
    > Why do it only show a few subdomains for .statuspage.io? I would have expected at least 10K or so. https://www.merklemap.com/search?query=*.statuspage.io&page= https://www.merklemap.com/search?query=*.statuspage.io&page=... Because they have a wildcard for *.statuspage.io, which they are probably hosting their pages on. > Is my query wrong or are you just showing less results intentionally if you’re not paying? No, results are the same but not sorted.
- gessha 2y ago
  This is really cool! It discovered even subdomains that lived for a few days on my site. If it’s not a secret, how do you discover those? Is it by listening to DNS record changes?
  - Eikon 2y ago
    By using... certificate transparency logs. https://www.merklemap.com/documentation/how-it-works https://www.merklemap.com/documentation/how-it-works
- tgsovlerkhgsel 2y ago
  Are you continuously monitoring consistency proofs? Or in other words, would someone (you or someone else) actually notice if a log changed its contents retroactively?
megamorf 2y ago
Doesn't this effectively render corporate CAs useless?
- Eikon 2y ago
  No, it just makes any CA accountable for all the certs they issue.
- zinekeller 2y ago
  > Doesn't this effectively render corporate CAs useless? All of the browsers ignore transparency for enterprise roots. To determine which is which, the list of actual public roots is stored separately in the CA database, listed in chrome://certificate-manager/crscerts for Chrome and listed as a "Builtin Object Token" in Firefox's Certificate Manager.
- archi42 2y ago
  Another comment mentioned [0]. Enterprise and people running a private CA can set "security.pki.certificate_transparency.disable_for_hosts" to disable CT for certain domains (plus all their subdomains). I just hope they automatically disable it for non-public tlds, both from IANA and RFC 6762. [0] https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency https://wiki.mozilla.org/SecurityEngineering/Certificate_Tra...
perching_aix 2y ago
Would be cool if DANE/TLSA record checks were also implemented. Not sure why browsers are not adopting it.
- zinekeller 2y ago
  Impractical in the sense that there are still TLDs (ccTLDs mind you, ICANN can't force anything for those countries) which do not have any form of DNSSEC, which makes DANE and TLSA useless for those TLDs.
  - perching_aix 2y ago
    Kind of disappointing if that is the actual stated reason by the various browser vendors, all or nothing doesn't sound like a good policy for this. Surely there is a middle ground possible.
    - Eikon 2y ago
      Supporting DANE means you need to maintain both traditional CA validation and DANE simultaneously. This may be controversial, but I believe that with CT logs already in place, DANE could potentially reduce security by leaving you without an audit trail of certificates issued to your hosts. If you actively monitor certificate issuance to your hosts using CT, you are in a much better security posture than what DANE would provide you with. People praising DANE seem to be doing so as a political statement ("I don't want a 3rd party") rather than making a technical point.
      - perching_aix 2y ago
        Why not do both at the same time? I understand that a TLSA record in and of its own would suffice technically, but combined with the regular CA-based PKI, I figured the robustness would increase.
        Eikon 2y ago
        > Why not do both at the same time? I understand that a TLSA record in and of its own would suffice technically, but combined with the regular CA-based PKI, I figured the robustness would increase. That seems quite complicated while not increasing security by much, or at all?
sciens3 2y ago
[flagged]
deleted 2y ago
[deleted]
braiamp 2y ago
I am on Debian Firefox 135.0.1 and https://no-sct.badssl.com/ https://no-sct.badssl.com/ doesn't error out as expected. Is Debian doing something different?
- masfuerte 2y ago
  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/ https://no-sct.badssl.com/>, but the actual href points to <https://certificate.transparency.dev/useragents/ https://certificate.transparency.dev/useragents/>. Your comment has the correct link which gives the warning.
  - wkat4242 2y ago
    Thanks for the correct link! It doesn't trigger the warning on the latest Firefox android though :(
  - tracymiranda 2y ago
    Thanks for flagging this - I've updated the post to fix the link
- jeroenhd 2y ago
  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_Transparency 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 sites you visit) and Debian overridding it for privacy purposes.
  - lxgr 2y ago
    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.
greatgib 2y ago
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!
- Eikon 2y ago
  You're essentially advocating for security through obscurity. The fact that public infrastructure is mappable is actually beneficial. It helps enforce best practices rather than relying on the flawed 'no one will discover this endpoint' approach. > And it's a new single point of control and failure! This reasoning is flawed. X.509 certificates themselves embed SCTs. While log unavailability may temporarily affect new certificate issuance, there are numerous logs operated by diverse organizations precisely to prevent single points of failure. Certificate validation doesn't require active log servers once SCTs are embedded.
  - cle 2y ago
    They are tradeoffs and it’s not all-or-nothing. There’s a reason security clearances exist, and that’s basically “security through obscurity”. The argument here is that the loss of privacy and the incentives that will increase centralization might not be worth the gain in security for some folks, but good luck opting out. It basically requires telling bigco about your domains. How convenient for crawlers…
  - tzs 2y ago
    > You're essentially advocating for security through obscurity So? The problem with security through obscurity is when it is the only security you are using. I didn't see anything in his comment that implied his only protection was the secrecy of his endpoints. Security through obscurity can be fine when used in addition to other security measures, and has tangible benefits in a significant fraction of real world situations.
    - grayhatter 2y ago
      > So? The problem with security through obscurity is when it is the only security you are using. I didn't see anything in his comment that implied his only protection was the secrecy of his endpoints. Directly, or unintentionally implied or not. That's an implication you're allowed to infer when obscurity is the only thing listed, because it's *very* common that is the only defense mechanism. Also, when given the choice between mentioning something that works (literally any other security measure), or mentioning something well known to fail more often than work (obscurity). You're supposed to mention the functioning one, and omit the non-functioning one. https://xkcd.com/463/ https://xkcd.com/463/ > Security through obscurity can be fine when used in addition to other security measures, No, it also has subtle downsides as well. It changes the behavior of everything that interacts with the system. Humans constantly over value the actual value of security though obscurity. And will make decisions based on that misconceived notion. I once heard an engineer tell me. "I didn't know you could hit this endpoint with curl". The mental model for permitting secrets to be used as part of security is actively harmful to security. Much more than it has ever shown to benefit it. Thus, the cure here is to affirmatively reject security though obscurity. We should treat it the same way we treat goto. Is goto useful, absolutely. Are there places where it improves code? Another absolutely. Did code quality as a whole improve once SWE collectively shunned goto? Yes! Security though obscurity is causing the exact same class of issues. And until the whole industry adapts to the understanding that it's actually more harmful than useful, we still let subtle bugs like "I thought no one knew about this" sneak in. We're not going to escape this valley while people are still advocating for security theatre. We all collectively need to enforce the idea that secrets are dangerous to software security. > and has tangible benefits in a significant fraction of real world situations. So does racial profiling, but humans have proven over and over and over again, that we're incapable of not misusing in a way that's also actively harmful. And again, when there are options that are better in every way, it's malpractice to use the error prone methods.
elmo2you 2y ago
I may be (legitimately) flagged for asking a question that may sound antagonizing ... but asked with sincerity: is at all smart to mention Firefox and transparency in the same sentence, at least at this particular moment in time? While this no doubt is an overall win, at least for most and in most cases, afaik this isn't completely without problems of its own. I just hope it won't lead to a systemd-like situation, where a cadre of (opinionated) people with power get to decide what's right from wrong, based on their beliefs about what might only be a subset of reality (albeit their only/full one at that). Not trying to be dismissive here. Just have genuine concerns and reservations. Even if mostly intuitively for now; no concrete ones yet. Maybe it's just a Pavlov-reaction, after reading the name Firefox. Honestly can't tell.
- lxgr 2y ago
  You’re spot on: You are reacting seemingly without understanding the fundamentals of what you are reacting to. Certificate Transparency [1] is an important technology that improves TLS/HTTPS security, and the name was not invented by Mozilla to my knowledge. If Firefox were to implement a hypothetical IETF standard called “private caching”, would you also be cynical about Firefox “doing something private at this point in time” without even reading up what the technology in question does? [1] https://en.wikipedia.org/wiki/Certificate_Transparency https://en.wikipedia.org/wiki/Certificate_Transparency
  - elmo2you 2y ago
    > You’re spot on: You are reacting seemingly without understanding the fundamentals of what you are reacting to. What if I did (understand)? What if I knew a thing or two about it, even some lesser known details and side-effects? Maybe including a controversy or two, or at least an odd limitation and potential hazard at that. But, you correctly do point out that Firefox isn't to blame for implementing somebody else's "standard". Responsible for any and all consequences? Nonetheless, certainly yes. Aside from now probably not being the best of times for Firefox, my main (potential) concern still stands. However, it is hardly a Firefox-only one, I'll give it that.
    - 2y ago
samgranieri 2y ago
Hmm. I wonder how this will work with certificates generated by enterprise or private certificate authorities. Specifically, I use caddy for local web development and it generates a snake oil ca for anything on *.localhost using code from step-ca. I also use step-ca and bind to run a homelab top level domain and generate certs using rfc2136. I have to install that root ca cert everywhere, but it’s worth it
- Habgdnv 2y ago
  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 CAs are limited to 1 year I think, or 2? I think it was 1.. * Can use weaker algorithms or older standards if they want. * Not subject to browser revocation policies - no need for OCSP/CRL etc. * More things that I do not know?
  - Uvix 2y ago
    Public CAs are currently limited to 398 days (effectively 13 months).
    - tialaramex 2y ago
      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.
snailmailman 2y ago
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.
- tialaramex 2y ago
  > 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.
  - cmeacham98 2y ago
    More likely guess, given a refresh fixed it: there was a slight delay with the CT log and it hadn't started returning the precertificate yet.
    - tialaramex 2y ago
      The browser isn't talking to the CT log, nor to the CA. It's just looking at the documents it was given, typically the certificate for a single intermediate and then the certificate for server itself which has the SCTs baked inside it. Suppose that you get a cert minted for your new server on 1st March at 14:56:09 UTC, the CA does a few checks, concludes this is OK and writes a to-be-signed certificate dated 1st March 13:56:11 UTC, then it mutates this tbsCert by adding poison (per the CT design) signs that and sends it to two CT logs shortly after, each CT log accepts this poisoned pre-cert and provides an SCT dated 1st March 14:56:15. The CA fastens these SCTs to the tbsCert it made before and signs all of that, which it provides back as a new certificate, this delivery completes at 14:56:21 only 12 seconds after you started and your server can use it immediately. Unfortunately your PC's clock is 15 seconds slow, it still believes it is 14:56:06 and so when it tries to visit the web site and sees the SCTs with 14:56:15 on them those are from the future and not yet valid. A message is shown explaining that this isn't valid, you take a moment to read it and then try refreshing at what you believe (based on your PC clock) is 14:56:15. This time though it all works because now the documents are valid.
ocdtrekkie 2y ago
Highlight point: They are just using Chrome's transparency logs. Yet again, Firefox chooses to be subservient to Google's view of the world.
- lima 2y ago
  Chrome's list of transparency logs. The actual CT logs are operated by multiple parties, including Google.
ruuda 2y ago
Through this article, a few links away, I learnt about tiling logs, explained in https://research.swtch.com/tlog https://research.swtch.com/tlog.
- tracymiranda 2y ago
  Tiled logs are cool & Chrome are starting to forge a path towards adoption: https://groups.google.com/a/chromium.org/g/ct-policy/c/HBFZHG0TCsY/m/HAaVRK6MAAAJ https://groups.google.com/a/chromium.org/g/ct-policy/c/HBFZH...
einpoklum 2y ago
It seems Mozilla is making Firefox irrelevant through collection of data on users and its plan to have users consent to that data collected and passed on to third parties. So what it does with certificates may not be very important, very soon.
- user3939382 2y ago
  Yeah in light of their license change, my reaction to this is “who cares”.

184 points by tracymiranda 2y ago

schoen 2y ago

Congratulations! That's terrific news.

joelthelion 2y ago

Can someone explain in a nutshell what CT is, and how does it help security for the average user?

djaychela 2y ago
There's a site for it here (linked 2 levels deep from the original article): https://certificate.transparency.dev/ https://certificate.transparency.dev/
perching_aix 2y ago
CT is an append-only distributed log for certificate issuances. People and client software can use it to check if a certificate is being provided by a trusted CA, if it has been revoked, or is being provided by multiple CAs (the latter possibly indicating CA compromise). CA meaning Certificate Authority, the organizations that issue certificates. This provides a further layer of technological defense to attempting the mitigation of your web browser traffic being intercepted and potentially tampered with. In practice a regular person is unlikely to run into this, because web PKI is mostly working as expected, so there's no reason for the edge cases to happen en masse. This change is covering one such edge case. No idea how the typical corporate interception solutions (e.g. Zscaler) circumvent it in other browsers where this check has long been implemented.
- q2dg 2y ago
  Will Mitmproxy stop working?
  - notpushkin 2y ago
    Chrome treats certificates added by user as not requiring CT: https://github.com/mitmproxy/mitmproxy/discussions/5720 https://github.com/mitmproxy/mitmproxy/discussions/5720
    - zinekeller 2y ago
      And to wit, Firefox too: > Setting this preference to 2 causes Firefox to enforce CT for certificates issued by roots in Mozilla's Root CA Program.
  - perching_aix 2y ago
    I believe so. You'll need to disable CT enforcement / or add your SPKI hash to the ignore list in the browser settings temporarily to get it working. [0] I guess this is also how corporations get around this issue? Still unsure. [0] https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency https://wiki.mozilla.org/SecurityEngineering/Certificate_Tra...
    - mcpherrinm 2y ago
      No. CT is only required for public CAs. You only need those browser policy settings if you’re using a public CA without CT.
      - perching_aix 2y ago
        I'd imagine this is why certs that terminate in root certificates manually added to the trust store will work fine then [as stated by other comments]?
        mcpherrinm 2y ago
        Right, any CA you add yourself that isn’t part of what Mozilla ships isn’t considered a publicly trusted CA.
tgsovlerkhgsel 2y ago
It's a public, tamper-proof log of all certificates issued. When a CA issues a certificate, it sends a copy to at least two different logs, gets a signed "receipt", and the receipt needs to be included in the certificate or browsers won't accept it. The log then publishes the certificate. This means that a CA cannot issue a certificate (that browsers would accept) without including it in the log. Even if a government compels a CA, someone compromises it, or even steals the CAs key, they'd have to either also do the same to two CT logs, or publish the misissued certificate. Operators of large web sites then can and should monitor the CT logs to make sure that nobody issued a certificate for their domains, and they can and will raise hell if they see that happen. If e.g. a government compels a CA to issue a MitM certificate, or a CA screws up and issues a fake cert, and this cert is only used to attack a single user, it would have been unlikely to be detected in the past (unless that user catches it, nobody else would know about the bad certificate). Now, this is no longer possible without letting the world know about the existence of the bad cert. There are also some interesting properties of the logs that make it harder for a government to compel the log to hide a certificate or to modify the log later. Essentially, you can store a hash representing the content of the log at any time, and then for any future state, the log can prove that the new state contains all the old contents. The "receipts" mentioned above (SCTs) are also a promise to include a certificate by a certain time, so if a log issues an SCT then publishes a new state more than a day later that doesn't include the certificate, that state + the SCT are proof that the log is bad.
- brookst 2y ago
  Thanks for the great explanation of both tech design and real world benefits!
- xg15 2y ago
  > Operators of large web sites then can and should monitor the CT logs to make sure that nobody issued a certificate for their domains, and they can and will raise hell if they see that happen. The tech is definitely an improvement from the previous situation, but I've always wondered about this step: Suppose you've found an unauthorized certificate for your site in the log (and you're not Google, Apple or Microsoft). Then what? What can you actually do about it?
cyberax 2y ago
Basically, a git repository for all the issues certificates.

MidnightRider39 2y ago

[flagged]

linwangg 2y ago

Great move! Curious to see how this will impact lesser-known CAs. Will this make it easier to detect misissued certs, or will enforcement still depend on browser policies?

arccy 2y ago
firefox is just catching up with what chrome implemented years ago. unless you have a site visited only by firefox users, ecosystem effect is likely to be minimal... though it does protect firefox users in the time between detection and remediation.

ozim 2y ago

Wonder why they say you should monitor transparency logs instead of setting up CAA records - malicious actors will most likely disregard CAA anyway.

lambdaone 2y ago
Let's not let the best be the enemy of the good. Malicious actors who disregard CAA would first have to have gone through the process of accreditation to be added to public trust stores, and then would quickly get removed from those trust stores as soon as the imposture was detected. So while creating a malicious CA and then ignoring CAA records is entirely possible for few-shot high-value attacks, it's not a scalable approach, and it means CAA offers at least partial protection against malicious actors forging certificates as a day-to-day activity. Transparency logs are of course better because they make it much easier for rogue CAs to be caught rapidly, but it's not a reason to abandon CAA until transparency log checking is universal, not just in browsers, but across the whole PKI ecosystem.
mcpherrinm 2y ago
In any security setting, it’s usually good to have both controls and detection. CAA records help prevent unexpected issuance, but what if your DNS server is compromised? DNSSEC might help. Certificate Transparency provides a detection mechanism. Also, unlike CAA records which are enforced only by policy that CAs must respect them, CT is technically enforced by browsers. So they are complimentary. A security-sensitive organization should have both.
tgsovlerkhgsel 2y ago
They're doing different things, and you should do both. Setting CAA records primarily serves to reduce your attack surface against vulnerable domain validation processes. If an attacker wants to specifically attack your domain, and you use CAA, the attacker now needs to find a vulnerability in your CA's domain validation process instead of any CAs validation process. If it works, it prevents an attacker from getting a valid cert. Monitoring CT logs only detects attacks after the fact, but will catch cases where CAs wrongly issued certificates despite CAA records, and if you monitor against a whitelist of your own known certificates, it will catch cases where someone got your CA to issue them a certificate, either by tricking the CA or compromising your infrastructure (most alerts you will actually see will be someone at your company just trying to get their job done without going through what you consider the proper channels, although I think you can now restrict CAA to a specific account for LetsEncrypt). Since CT is required now by browsers, an attacker that compromises (or compels!) a CA in any way would still have to log the cert or also compromise or compel at least two logs to issue SCTs (signed promises to include the cert in the log) without actually publishing the cert (this is unlikely to get caught but if it was, there would be signed proof that the log did wrong).

deleted 2y ago

[deleted]

Eikon 2y ago

Shameless plug: Check out my Certificate Transparency monitor at https://www.merklemap.com https://www.merklemap.com The scale is massive, I just crossed 100B rows in the main database! :)

AznHisoka 2y ago
Why do it only show a few subdomains for .statuspage.io? I would have expected at least 10K or so. https://www.merklemap.com/search?query=*.statuspage.io&page=0 https://www.merklemap.com/search?query=*.statuspage.io&page=... Is my query wrong or are you just showing less results intentionally if you’re not paying?
- Eikon 2y ago
  > Why do it only show a few subdomains for .statuspage.io? I would have expected at least 10K or so. https://www.merklemap.com/search?query=*.statuspage.io&page= https://www.merklemap.com/search?query=*.statuspage.io&page=... Because they have a wildcard for *.statuspage.io, which they are probably hosting their pages on. > Is my query wrong or are you just showing less results intentionally if you’re not paying? No, results are the same but not sorted.
gessha 2y ago
This is really cool! It discovered even subdomains that lived for a few days on my site. If it’s not a secret, how do you discover those? Is it by listening to DNS record changes?
- Eikon 2y ago
  By using... certificate transparency logs. https://www.merklemap.com/documentation/how-it-works https://www.merklemap.com/documentation/how-it-works
tgsovlerkhgsel 2y ago
Are you continuously monitoring consistency proofs? Or in other words, would someone (you or someone else) actually notice if a log changed its contents retroactively?

megamorf 2y ago

Doesn't this effectively render corporate CAs useless?

Eikon 2y ago
No, it just makes any CA accountable for all the certs they issue.
zinekeller 2y ago
> Doesn't this effectively render corporate CAs useless? All of the browsers ignore transparency for enterprise roots. To determine which is which, the list of actual public roots is stored separately in the CA database, listed in chrome://certificate-manager/crscerts for Chrome and listed as a "Builtin Object Token" in Firefox's Certificate Manager.
archi42 2y ago
Another comment mentioned [0]. Enterprise and people running a private CA can set "security.pki.certificate_transparency.disable_for_hosts" to disable CT for certain domains (plus all their subdomains). I just hope they automatically disable it for non-public tlds, both from IANA and RFC 6762. [0] https://wiki.mozilla.org/SecurityEngineering/Certificate_Transparency https://wiki.mozilla.org/SecurityEngineering/Certificate_Tra...

perching_aix 2y ago

Would be cool if DANE/TLSA record checks were also implemented. Not sure why browsers are not adopting it.

zinekeller 2y ago
Impractical in the sense that there are still TLDs (ccTLDs mind you, ICANN can't force anything for those countries) which do not have any form of DNSSEC, which makes DANE and TLSA useless for those TLDs.
- perching_aix 2y ago
  Kind of disappointing if that is the actual stated reason by the various browser vendors, all or nothing doesn't sound like a good policy for this. Surely there is a middle ground possible.
  - Eikon 2y ago
    Supporting DANE means you need to maintain both traditional CA validation and DANE simultaneously. This may be controversial, but I believe that with CT logs already in place, DANE could potentially reduce security by leaving you without an audit trail of certificates issued to your hosts. If you actively monitor certificate issuance to your hosts using CT, you are in a much better security posture than what DANE would provide you with. People praising DANE seem to be doing so as a political statement ("I don't want a 3rd party") rather than making a technical point.
    - perching_aix 2y ago
      Why not do both at the same time? I understand that a TLSA record in and of its own would suffice technically, but combined with the regular CA-based PKI, I figured the robustness would increase.
      - Eikon 2y ago
        > Why not do both at the same time? I understand that a TLSA record in and of its own would suffice technically, but combined with the regular CA-based PKI, I figured the robustness would increase. That seems quite complicated while not increasing security by much, or at all?

sciens3 2y ago

[flagged]

deleted 2y ago

[deleted]

braiamp 2y ago

I am on Debian Firefox 135.0.1 and https://no-sct.badssl.com/ https://no-sct.badssl.com/ doesn't error out as expected. Is Debian doing something different?

masfuerte 2y ago
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/ https://no-sct.badssl.com/>, but the actual href points to <https://certificate.transparency.dev/useragents/ https://certificate.transparency.dev/useragents/>. Your comment has the correct link which gives the warning.
- wkat4242 2y ago
  Thanks for the correct link! It doesn't trigger the warning on the latest Firefox android though :(
- tracymiranda 2y ago
  Thanks for flagging this - I've updated the post to fix the link
jeroenhd 2y ago
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_Transparency 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 sites you visit) and Debian overridding it for privacy purposes.
- lxgr 2y ago
  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.

greatgib 2y ago

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!

Eikon 2y ago
You're essentially advocating for security through obscurity. The fact that public infrastructure is mappable is actually beneficial. It helps enforce best practices rather than relying on the flawed 'no one will discover this endpoint' approach. > And it's a new single point of control and failure! This reasoning is flawed. X.509 certificates themselves embed SCTs. While log unavailability may temporarily affect new certificate issuance, there are numerous logs operated by diverse organizations precisely to prevent single points of failure. Certificate validation doesn't require active log servers once SCTs are embedded.
- cle 2y ago
  They are tradeoffs and it’s not all-or-nothing. There’s a reason security clearances exist, and that’s basically “security through obscurity”. The argument here is that the loss of privacy and the incentives that will increase centralization might not be worth the gain in security for some folks, but good luck opting out. It basically requires telling bigco about your domains. How convenient for crawlers…
- tzs 2y ago
  > You're essentially advocating for security through obscurity So? The problem with security through obscurity is when it is the only security you are using. I didn't see anything in his comment that implied his only protection was the secrecy of his endpoints. Security through obscurity can be fine when used in addition to other security measures, and has tangible benefits in a significant fraction of real world situations.
  - grayhatter 2y ago
    > So? The problem with security through obscurity is when it is the only security you are using. I didn't see anything in his comment that implied his only protection was the secrecy of his endpoints. Directly, or unintentionally implied or not. That's an implication you're allowed to infer when obscurity is the only thing listed, because it's *very* common that is the only defense mechanism. Also, when given the choice between mentioning something that works (literally any other security measure), or mentioning something well known to fail more often than work (obscurity). You're supposed to mention the functioning one, and omit the non-functioning one. https://xkcd.com/463/ https://xkcd.com/463/ > Security through obscurity can be fine when used in addition to other security measures, No, it also has subtle downsides as well. It changes the behavior of everything that interacts with the system. Humans constantly over value the actual value of security though obscurity. And will make decisions based on that misconceived notion. I once heard an engineer tell me. "I didn't know you could hit this endpoint with curl". The mental model for permitting secrets to be used as part of security is actively harmful to security. Much more than it has ever shown to benefit it. Thus, the cure here is to affirmatively reject security though obscurity. We should treat it the same way we treat goto. Is goto useful, absolutely. Are there places where it improves code? Another absolutely. Did code quality as a whole improve once SWE collectively shunned goto? Yes! Security though obscurity is causing the exact same class of issues. And until the whole industry adapts to the understanding that it's actually more harmful than useful, we still let subtle bugs like "I thought no one knew about this" sneak in. We're not going to escape this valley while people are still advocating for security theatre. We all collectively need to enforce the idea that secrets are dangerous to software security. > and has tangible benefits in a significant fraction of real world situations. So does racial profiling, but humans have proven over and over and over again, that we're incapable of not misusing in a way that's also actively harmful. And again, when there are options that are better in every way, it's malpractice to use the error prone methods.

elmo2you 2y ago

I may be (legitimately) flagged for asking a question that may sound antagonizing ... but asked with sincerity: is at all smart to mention Firefox and transparency in the same sentence, at least at this particular moment in time? While this no doubt is an overall win, at least for most and in most cases, afaik this isn't completely without problems of its own. I just hope it won't lead to a systemd-like situation, where a cadre of (opinionated) people with power get to decide what's right from wrong, based on their beliefs about what might only be a subset of reality (albeit their only/full one at that). Not trying to be dismissive here. Just have genuine concerns and reservations. Even if mostly intuitively for now; no concrete ones yet. Maybe it's just a Pavlov-reaction, after reading the name Firefox. Honestly can't tell.

lxgr 2y ago
You’re spot on: You are reacting seemingly without understanding the fundamentals of what you are reacting to. Certificate Transparency [1] is an important technology that improves TLS/HTTPS security, and the name was not invented by Mozilla to my knowledge. If Firefox were to implement a hypothetical IETF standard called “private caching”, would you also be cynical about Firefox “doing something private at this point in time” without even reading up what the technology in question does? [1] https://en.wikipedia.org/wiki/Certificate_Transparency https://en.wikipedia.org/wiki/Certificate_Transparency
- elmo2you 2y ago
  > You’re spot on: You are reacting seemingly without understanding the fundamentals of what you are reacting to. What if I did (understand)? What if I knew a thing or two about it, even some lesser known details and side-effects? Maybe including a controversy or two, or at least an odd limitation and potential hazard at that. But, you correctly do point out that Firefox isn't to blame for implementing somebody else's "standard". Responsible for any and all consequences? Nonetheless, certainly yes. Aside from now probably not being the best of times for Firefox, my main (potential) concern still stands. However, it is hardly a Firefox-only one, I'll give it that.
  - 2y ago

samgranieri 2y ago

Hmm. I wonder how this will work with certificates generated by enterprise or private certificate authorities. Specifically, I use caddy for local web development and it generates a snake oil ca for anything on *.localhost using code from step-ca. I also use step-ca and bind to run a homelab top level domain and generate certs using rfc2136. I have to install that root ca cert everywhere, but it’s worth it

Habgdnv 2y ago
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 CAs are limited to 1 year I think, or 2? I think it was 1.. * Can use weaker algorithms or older standards if they want. * Not subject to browser revocation policies - no need for OCSP/CRL etc. * More things that I do not know?
- Uvix 2y ago
  Public CAs are currently limited to 398 days (effectively 13 months).
  - tialaramex 2y ago
    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.

snailmailman 2y ago

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.

tialaramex 2y ago
> 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.
- cmeacham98 2y ago
  More likely guess, given a refresh fixed it: there was a slight delay with the CT log and it hadn't started returning the precertificate yet.
  - tialaramex 2y ago
    The browser isn't talking to the CT log, nor to the CA. It's just looking at the documents it was given, typically the certificate for a single intermediate and then the certificate for server itself which has the SCTs baked inside it. Suppose that you get a cert minted for your new server on 1st March at 14:56:09 UTC, the CA does a few checks, concludes this is OK and writes a to-be-signed certificate dated 1st March 13:56:11 UTC, then it mutates this tbsCert by adding poison (per the CT design) signs that and sends it to two CT logs shortly after, each CT log accepts this poisoned pre-cert and provides an SCT dated 1st March 14:56:15. The CA fastens these SCTs to the tbsCert it made before and signs all of that, which it provides back as a new certificate, this delivery completes at 14:56:21 only 12 seconds after you started and your server can use it immediately. Unfortunately your PC's clock is 15 seconds slow, it still believes it is 14:56:06 and so when it tries to visit the web site and sees the SCTs with 14:56:15 on them those are from the future and not yet valid. A message is shown explaining that this isn't valid, you take a moment to read it and then try refreshing at what you believe (based on your PC clock) is 14:56:15. This time though it all works because now the documents are valid.

ocdtrekkie 2y ago

Highlight point: They are just using Chrome's transparency logs. Yet again, Firefox chooses to be subservient to Google's view of the world.

lima 2y ago
Chrome's list of transparency logs. The actual CT logs are operated by multiple parties, including Google.

ruuda 2y ago

Through this article, a few links away, I learnt about tiling logs, explained in https://research.swtch.com/tlog https://research.swtch.com/tlog.

tracymiranda 2y ago
Tiled logs are cool & Chrome are starting to forge a path towards adoption: https://groups.google.com/a/chromium.org/g/ct-policy/c/HBFZHG0TCsY/m/HAaVRK6MAAAJ https://groups.google.com/a/chromium.org/g/ct-policy/c/HBFZH...

einpoklum 2y ago

It seems Mozilla is making Firefox irrelevant through collection of data on users and its plan to have users consent to that data collected and passed on to third parties. So what it does with certificates may not be very important, very soon.

user3939382 2y ago
Yeah in light of their license change, my reaction to this is “who cares”.