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

31–40 of 116 posts

Re: Certificate Transparency in Firefox

#31

Post by perching_aix »

Eikon wrote: post #29
perching_aix wrote: post #23

Earlier quoted context omitted.

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.

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

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.

Re: Certificate Transparency in Firefox

#34

Post by greatgib »

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!

Re: Certificate Transparency in Firefox

#35

Post by Eikon »

greatgib wrote: post #34

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!

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.

Re: Certificate Transparency in Firefox

#36

Post by Eikon »

perching_aix wrote: post #31
Eikon wrote: post #29

Earlier quoted context omitted.

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

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.

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

Re: Certificate Transparency in Firefox

#37

Post by tialaramex »

greatgib wrote: post #34

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!

"Passive DNS" is a thing people sell. If people connect to your systems and use public DNS servers, chances are I can "map the complete endpoints of your infrastructure" without touching that infrastructure for a small cost.

If client X doesn't want client-x.your-firm.example to show up by all means obtain a *.your-firm.example wildcard and let them use any codename they like - but know that they're going to name their site client-x.your-firm.example, because in fact they don't properly protect such "secrets".

"Blue Harvest" is what secrets look like. Or "Argo" (the actual event not the movie, although real life is much less dramatic, they didn't get chased by people with guns, they got waved through by sleepy airport guards, it's scary anyway but an audience can't tell that).

What you're talking about is like my employer's data centre being "unlisted" and having no logo on the signs. Google finds it with an obvious search, it's not actually secret.

Re: Certificate Transparency in Firefox

#38

Post by perching_aix »

Eikon wrote: post #36
perching_aix wrote: post #31

Earlier quoted context omitted.

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.

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

I don't necessarily see the complication. The benefit would be that I, the domain owner, would be able to communicate to clients what certificate they should be expecting, and in turn, clients would be able to tell if there's a mismatch. Sounds like a simple win to me.

According to my understanding, multiple CAs can issue a certificate covering the same domain just fine, so that on its own showing up on the CT logs is not a sign of CA compromise, just a clue. Could then check CAA, but that is optional and clients are never supposed to check that according to the standard, only the CAs (which again the idea is that one or more are compromised in this scenario). So there's a gap there. This gap to my knowledge is currently bridged by people auditing CT manually, and is the gap that would be filled with DANE in this setup in my thinking, automating it away (or just straight up providing it, because I can imagine that a lot of domain owners do not monitor CT for their domains whatsoever).

Re: Certificate Transparency in Firefox

#39

Post by AznHisoka »

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

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

Is my query wrong or are you just showing less results intentionally if you’re not paying?

Re: Certificate Transparency in Firefox

#40

Post by tialaramex »

perching_aix wrote: post #19

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

The reason browsers didn't implement DANE is because most people's DNS servers are garbage, so if you do this the browser doesn't work and "if you changed last you own the problem".

At the time if you asked a typical DNS server e.g. at an ISP or built into a cheap home router - any type of question except "A? some.web.site.example" you get either no answer or a confused error. What do you mean records other than A exist? RFC what? These days most of them can also answer AAAA? but good luck for the records needed by DNSSEC.

Today we could do better where people have any sort of DNS privacy, whether that's over HTTPS or TLS or QUIC so long as it's encrypted it's probably not garbage and it isn't being intercepted by garbage at your ISP.

Once the non-adoption due to rusted-in-place infrastructure happened, you get (as you will probably see here on HN) people who have some imagined principle reasons not to do DNSSEC, remember always to ask them how their solution fixed the problem that they say DNSSEC hasn't fixed. The fact the problem still isn't fixed tells you everything you need to know.

Post reply on HN