Comment by judge2020 | Hacker News Reader

Comment by judge2020 | Hacker News Reader

Parent Full thread

Certificate transparency effectively solves this because certain browsers (currently only Safari and Chrome) require all new certificates be submitted to multiple certificate transparency lists - if it encounters a certificate that isnt, it’ll show a warning page before establishing the TLS session. More info[0].

This doesn’t stop interception, but the first time it happens that some huge company notices a certificate issuance they didn’t authorize and/or should be blocked by their CAA records, it’ll be a large event with disastrous consequences for the CA, likely triggering immediate (<48 hours) removal from publicly trusted CA lists.

Of course, if a country wants to intercept, they still can by intercepting all traffic with their own (new) CA - Kazakhstan tried this and asked all their citizens to install it if they wanted internet[1], but it shows that these efforts won’t go unnoticed and browser developers might fight back against government surveillance.

0: https://chromium.googlesource.com/chromium/src/+/refs/heads/...

1: https://news.ycombinator.com/item?id=25324951

There are some nuances to Certificate Transparency (CT) that are worth highlighting:

- Technically, certificates are not required to be recorded in CT logs. If not submitted, they're still perfectly valid, but they won't be accepted by clients who insist on CT (e.g., most browsers). They will work perfectly well in all other situations.

- At the point of use, certificates must be accompanied by proofs of submission to several CT logs. These proofs are better known as Signed Certificate Timestamps, or SCTs. SCTs are _promises_ by CT logs to publish, but there is no way to know if the certificates actually had been published. You have to trust the CT logs. This is largely where we're currently with CT.

The main improvement is that a certificate must now be endorsed by min. 3 parties for it to work in a browser (CA + 2 CT log operators at present; 2 parties if a CA also operates one of the logs). At this time, Google must operate one of the CT logs [for the certificate to work in Chrome].

The missing piece (currently in progress) is SCT auditing, where a portion of observed SCTs are continuously checked for presence in CT logs. I wrote a little about it here: https://www.hardenize.com/blog/certificate-transparency-sct-...

Does this actually work and in use?

I worked on a transparent MITM proxy, a proxy that is configured in the firewall not at the application; IE applications were unaware they were using a proxy.

Simply adding the proxies CA key to the system trust store was all that was needed to make all applications, including browsers, to trust the certificates we were manufacturing.

There was no indication besides inspecting the certificate that the certificate was ours. Definitely no calls go check certificate transparency that we could see.

If the MITM CA is installed (maybe only via Group Policy) then browsers relax their requirements for CA's. But some domains (like google) are strictly locked down to a specific set of CA's in Chrome.

Since TLS Interception is critical for some places to achieve their duties (either auditing in banking, or content filtering in schools) we will always have some kind of legit use for MITM CA boxes.

It gets slightly worse if you look at how AntiVirus generally installs CA's to do malware content filtering. Cloudflare publishes stats on what % of traffic they think has been MITM'd: https://malcolm.cloudflare.com/

Why are we okay with content filtering in schools?

In Poland where I live, parental control basically doesn't exist. Children routinely watch movies, play games and visit websites that they're theoretically not supposed to visit. Parents know about it and don't really see an issue with it. I've seen several boarding school networks, none of them had any filtering whatsoever. The only filters I've seen were on computers in IT classrooms, but nobody uses those for non class-related activities anyway. As far as I know, we don't even have a law banning selling x-rated content to minors.

different countries different morales different way of educating childen, ymmv at the outcome!

Content filtering is by no means critical and shouldn't be used at all. All it does is punish students who don't know how to use Tor. Every school I've been to besides my highschool had either no filter or a DNS or HTTPS based filter, and most students used VPN apps which are likely worse for them (spyware etc.) than not having filtering. My highschool used Fortinet which also did SNI blocking and tried to block Tor, requesting new bridges allowed me to connect. At least Fortinet quickly reclassifies false positives though.

Maybe on some browsers. I've MITM my connections on Firefox for a very long time and have never run into anything related to transparency logs. There must be some setting I have disabled in the browser. The only way I can tell that the cert is not legit is looking at the fingerprint and the only sites I run into issues with are the few still using HPKP. I've never used Chrome. Maybe Chrome checks transparency logs and submits violations?

It's not 100% related but certificate pinning (HKPK) is only enforced for CA trusted by browser. It is ignored if the leaf certificate is signed by a user-imported CA (or deployed by enterprise policies). Maybe the same applies for SCT?

It actually works and is in use, but only for CAs that are trusted by default, not ones that you or your BOFH manually add to the trusted list.

That's how it's done in corporate environments to monitor trafic.Http or https you have no privacy.

The users can see the certificate in their browser though

It feels like merkle trees[1] could help here.

We could split each transparency log into blocks, issuing a new block every 24 hours. Every block header would contain a hash of the root node of it's Merkle tree, the hash of the previous header and a digital signature. Storing 1000 latest headers for 5 transparency logs would take less than a megabyte, so most browsers would be fine with this.

When sending a certificate, the server would also send the header hashes for the block the certificate appears in, as well as the contents of any intermediate merkle tree nodes.

In the rare case where we encounter a certificate issued in the latest 24 hours, we would directly ask the transparency log for a hash list of all certificates issued in a given 1 minute period (taken from the issuance date in the certificate).

Yes it would help, and you have described Bitcoin's Simplified Payment Verification (SPV) protocol: https://bitcoin.org/bitcoin.pdf#page=5

Reply on news.ycombinator.com