What it means to see a 'bad' certificate in TLS Certificate Transparency logs

https://utcc.utoronto.ca/~cks/space/blog/tech/TLSCertTransBadCertMeanings

by todsacerdoti • 4 years ago

48 23 4 years ago

utcc.utoronto.ca

bracewel• 4 years ago

There is a fifth, incredibly common, (arguably) non-malicious possibility.

You don't control the entirety of your web stack, and your hosting provider, or DNS provider, or someone else, has decided to be 'helpful' (either blindly, or due to some misconfiguration somewhere along the line) and issue a certificate on your behalf, as they are able to intercept CA validation traffic at the DNS, TLS, or HTTP layer.

tinus_hn2• 4 years ago

This is also arguably malicious, it is not for them to get certificates for your domain and snoop your traffic. I’d hope this is not ‘incredibly common’, in my opinion it is completely unacceptable.

The certificate certifies the holder is the owner of the domain, if some third party gets a certificate that’s fraudulent. In at least some jurisdictions making a fraudulent claim like that is illegal.

michaelt• 4 years ago

Or indeed you're in a position of overlapping authority.

Universities will often have a cash-strapped organisation-wide IT Department (e-mail for english majors) and another layer of IT in certain academic departments (computer labs for CS students) and another layer of IT after that (the centre for machine learning paid for that cluster, of course they have full authority over it) - and often it's that third-level body that's getting all the grant funding and publishing all the papers.

The people who control www.example.edu might basically be the marketing department for their glossy student recruitment brochure. Who's to say they have authority over certificate issuance for datasets.ml.cs.example.edu ?

cryptonector2• 4 years ago

There is a better way than CT: DANE, with query name minimization to prevent MITMing of some domains (as opposed to none or all) by a malicious or compromised . or TLD.

DANE means you get a real PKI with real name constraints, unlike WebPKI.

DANE stapling can reduce latency, but doing DANE w/ qname minimization for most of the domainname being resolved has the property that you get to make life really hard for a malicious or compromised . or TLD. You get to cache a lot of results, so using DANE stapling for the stem of the domainname should still reduce latency a fair bit.

With DNS over TLS or HTTPS we're seeing that resolvers are willing to use TCP, which is one answer to the DNS amplification attack concern.

josephg• 4 years ago

What’s the status on DANE? Is it supported in any modern web browsers? Is it gaining any traction?

Koenvh• 4 years ago

DANE is gaining adoption primarily when it comes to email - browsers are still hesitant.

Avamander2• 4 years ago

You're just trading one PKI for an another with DANE. One that has way less transparency.

cryptonector2• 4 years ago

First of all, this is not worse than WebPKI. CT or no CT, you won't catch CAs MITMing you until it's too late, and even with CT you depend utterly on the sites you visit actually auditing CT.

Second of all, with DANE with QName minimization the parent CAs (zones) don't know what you'll be asking of the ones below, so either they MITM you for all your requests or none of them or they have to have other context to decide when to MITM you. The one bit of context they really want but don't get to have -if you minimize queries- is the full domainname you're trying to resolve, so it's hard for them to decide whether to MITM you. And you can catch DNS zones lying because you can a) perform the same lookups in different networks, b) you can download, cache, and check . and TLDs so you can catch those lying (which is 99% of the battle).

But most importantly, you get real, strong name constraints.

garaetjjte• 4 years ago

DANE (and generally anything that depends on DNSSEC) is dead technology at this point, with zero adoption in browsers. Arguably it offers less protection against malicious TLD or root because you don't get any logs. (well, you could require both with PKIX-EE mode, but that's getting really complicated to configure)

tptacek2• 4 years ago

DANE stapling died in committee at the IETF; there's no solid answer for how to implement it in a way where an attacker with control of a root certificate can't strip it off a TLS session, and if you assume an attacker can't control a WebPKI root certificate, DANE isn't serving any purpose either.

Meanwhile: DANE and CT don't have the same functionality at all. DANE defines away the need for transparency by saying that the PKI will be operated by entities we all intrinsically and completely trust (world governments). CT says "we don't trust the PKI at all, so let's log it". A lack of any kind of DANE transparency log is one small reason among many that DANE isn't taken seriously.

AndyMcConachie• 4 years ago

If a CA is behaving in a bad way why would they include a bad cert they issued in certificate transparency logs?

I don't understand what CT accomplishes since it places the onus of reporting on the party that CT is supposed to monitor.

ivanr• 4 years ago

CAs don't have to report their certificates to CT logs, and actually there is no reporting in a variety of use cases. However, modern browsers no longer trust certificates for which there is no (cryptographic) evidence of logging to CT.

The net result is that CT gives us visibility into all web certificates (and more).

witrak• 4 years ago

"The net result is that CT gives us visibility into all web certificates [...]" including not always the desirable effect of publishing information on hosts in the non-public part of the institution network...

tinus_hn2• 4 years ago

Anyone who gets presented the certificate can check if it is in the log, and if it is not the authority is exposed and can be held accountable by the parties that manage the root certificate stores (browser and OS vendors).

charcircuit• 4 years ago

why would they include a bad cert they issued in certificate transparency logs?

Because secure browsers like Chrome require certificate transparency for it to trust the cert.

Unfortunately there still exist insecure browsers like Firefox which leaves a percentage of the population vulnerable to bad certs that aren't logged.

zinekeller• 4 years ago

Because secure browsers like Chrome require certificate transparency for it to trust the cert.

And if it was found out to be fraudulent? "Secure" Chrome would do f***all unless you're PayPal while "insecure" Firefox always checks if the certificate is still valid.

sweetbitter• 4 years ago

How can Chrome be considered secure if its "security" entails the equivalent of giving a shell on the PC of all users to a shady corporation like Google?

tialaramex2• 4 years ago

Others have responded at a high level, but I'll describe both a very low level and even higher level answer.

Low level first. CT logs produce a cryptographic "receipt" for the logged item. This receipt is a promise to report the item to anybody who asks within 24 hours. Web browsers, including Chrome, Edge and Safari, want to see the receipt. They may collect some receipts and check the logs did indeed publish these items. So, technically to make your certificate work in those browsers you need to log the certificate and the log you use needs to publish it.

Very high level. Logging and obtaining receipts, then providing the receipt to a browser is extra work. So, if you sell certificates it makes sense to do this work for all your customers by default and just bake the receipts into the data they have. It's extra trouble to build a mechanism to sidestep this, and so there's often no reason to do so.

What it means to see a 'bad' certificate in TLS Certificate Transparency logs

Related Stories