Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Certificate Transparency in Firefox

blog.transparency.dev

Post reply on HN
Print view View original

91–100 of 116 posts

Re: Certificate Transparency in Firefox

#91

Post by Eikon »

antonios wrote: post #89
Eikon wrote: 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! :)

That's interesting, can you share more information about your tech stack?

Merklemap is running PostgreSQL as the primary database, currently scaling at ~18TB on NVMe storage, and around 30TB of actual certificates that are stored on s3.

The backend is implemented in Rust (handling web services, search functionality, and data ingestion pipelines).

The frontend is built with Next.js.

Re: Certificate Transparency in Firefox

#92

Post by tptacek »

perching_aix wrote: post #78
cpach wrote: post #69

Earlier quoted context omitted.

DNSSEC has aged very poorly. I also believe it operates at the wrong layer. When you surf to chase.com you want to make be sure that the website you see is actually JPMorganChase and not Mallory’s fake bank site. That’s why we have HTTPS and the WebPKI. If your local DNS server is poisoned somehow that’s obviosly not good, but it cannot easily send you to a fake version of chase.com. Part of why it’s so hard for Mall…

There are a lot of things that are different for sure since that article's release, for example the crypto, but also the existence of DoH/DoT and that it is leaps and bounds more deployed. They also talk about key pinning, but key pinning has been dead for a while and replaced by exactly CT. I'm also not sure how much to trust the author. The writing is very odd language wise and they seem to have quite the axe to gr…

The existence of DoH hurts DNSSEC, it doesn't help it. While privacy is the motivating use case for DoH, it's also the case that on-path attackers can't corrupt the results of a DoH query; they have to move upstream of it.

The dream of TLSA as a bulwark against suborned CAs has always been problematic, because the security of TLSA records collapses down to that of the TLD operators, the most popular of which are state actors or proxies for them, and most of the remainder are essentially e-commerce firms, not trust anchors.

But that doesn't matter, because TLSA as an alternative to the WebPKI is already dead on arrival. So many people have problematic access to DNS that no browser can ship hard-fail DANE; in the (extraordinarily unlikely) future world where mainstream browsers do DANE, everybody will have soft-fail DANE falling back to the WebPKI. So, instead of a small number of (state-run!) PKI roots, you'll have the thousands of legacy operators plus the state-run PKI roots.

This problem motivated the design of "stapling" protocols, where we'd basically throw away the DNS part of the protocol, and just keep the TLSA records, and attach them to the TLS handshake. For several years, this was the last best hope for DANE adoption (read Geoff Huston on this, he's a DANE supporter and he's great), and it all fell apart because nobody could get the security model right.

It's at this point I like to remind people that the browsers basically had to shake down the CAs to get Certificate Transparency to happen. They held almost all the cards (except for antitrust claims, which were wielded against them) --- "comply with CT, or we'll remove you from our root program". But browsers can't do that with DNS TLD operators; they hold none of the cards. So, in addition to the fact that there's no "DNS Transparency" on the horizon, there's also none of the leverage required to actually get it deployed.

DANE does not work. DNSSEC is a dead letter. It's long past time for people to move on. I have a lot of hope for what we can accomplish with ubiquitous DoH-like lookups.

Re: Certificate Transparency in Firefox

#94

Post by einpoklum »

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.

Re: Certificate Transparency in Firefox

#95

Post by mcpherrinm »

perching_aix wrote: post #54
mcpherrinm wrote: post #27

Earlier quoted context omitted.

No. CT is only required for public CAs. You only need those browser policy settings if you’re using a public CA without CT.

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]?

Right, any CA you add yourself that isn’t part of what Mozilla ships isn’t considered a publicly trusted CA.

Re: Certificate Transparency in Firefox

#96

Post by tgsovlerkhgsel »

lxgr wrote: post #68
tgsovlerkhgsel wrote: post #66

Earlier quoted context omitted.

No, I assume but Mozilla was first collecting telemetry to see if enabling CT would cause user-visible errors or not.

Ah, good point – presumably 2 also sends telemetry to Mozilla?

I would expect (without having checked) that both 1 and 2 send telemetry to Mozilla if and only if the global telemetry switch is on (which I think it is by default).

Re: Certificate Transparency in Firefox

#97

Post by user3939382 »

einpoklum wrote: post #94

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.

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

Re: Certificate Transparency in Firefox

#98

Post by xg15 »

tgsovlerkhgsel wrote: post #28
joelthelion wrote: post #3

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

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…

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

Re: Certificate Transparency in Firefox

#99

Post by cpach »

xg15 wrote: post #98
tgsovlerkhgsel wrote: post #28

Earlier quoted context omitted.

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…

> 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)…

Good question!

When you inform the CA about the incident they are required to revoke the certificate. AFAICT they are also expected to file an incident report to Mozilla’s Bugzilla bug tracker (they have a section just for stuff like this).

The operations of Certificate Authorities are strictly regulated by policies such as the “Baseline Requirements” (Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates), Mozilla’s Root Store Policy and the policies of the Common CA Database. If a CA fails to live up to these requirements, the major browsers will kick their root cert of their root stores. (This is not an empty threat.)

You can find some more info here:

https://wiki.mozilla.org/CA/Responding_To_An_Incident

https://cabforum.org/working-groups/server/baseline-requirem... (section 4.9)

The bugzilla I mentioned is here: https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Progra... – AFAICT, a lot of the deviations are reported by CA staff themselves. So the whole system is actually quite open and self-regulating, not as corrupt and scammy as many seem to believe.

Re: Certificate Transparency in Firefox

#100

Post by tialaramex »

immibis wrote: post #87
Eikon wrote: 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! :)

I tried to do something like this one time and had a problem just finding the logs . All information on the internet points to the fact that certain logs exist, but not how to access them. Are they not public access? Do you have a B2B relationship with the companies like Cloudflare that run logs?

They're required to be public services. https://crt.sh/monitored-logs is the list of logs monitored by crt.sh (a public log monitor operated by Sectigo, a commercial CA) if that helps. Each of the major browsers also publishes which logs they trust and provides information about e.g. distrust of logs. Is the problem that you couldn't figure out how to use a log? It doesn't just have a web site where you can type in searches you need to be able to use their web API as defined in the protocol documentation.
Post reply on HN