Certificate Transparency: a bird's-eye view | Hacker News Reader

Certificate Transparency: a bird's-eye view

emilymstark.com

31 pointsfanf213 comments

Most of this is beyond my understanding of TLS, but the first time I read about CT my first thought was, “So Google is pushing a technology that would let them know about every new HTTPS domain on the Internet?”

Am I right to be suspicious about Google’s motivations here? It may very well also be the case that CT also improves security, but part of me feels...dirty, knowing that I can’t opt out of this mechanism that sends data straight to Google about any new HTTPS domain I set up, so they can start indexing it. Is this just the cost of improving trust?

First of all, as I understand it anyone can access it, not just google. Secondly, if you don't want to be indexed by Google, there are better ways to do that (like a robots.txt). Finally, I suspect Google would be more interested in using this as a tool to figure out which sites not to index, because they have fishy (or phishy) certs, than trying to find obscure domains that have slipped under their radar.

I know there are mechanisms to customize Google’s crawler on a domain. That’s not what I’m objecting to, I’m objecting to the loss of control over my data.

You can actually opt out of that mechanism: you can use your own, untrusted CA. The point of CT is to improve trust, and I seriously have doubts trusting the 300 independant (?) CAs my browser "trusts" [0].

Sure, having an infinite, append-only log of domain names for which an HTTPS certificate ever was issued sounds like a GDPR issue. But if it also helps catch bad actors before they can even set up their phishing pages, I'm all for it.

[0] https://hg.mozilla.org/releases/mozilla-beta/raw-file/tip/se...

Google already knows about the domains, they run a web crawler...

How else would they know about it unless the CA told them?

Certstream[0] is pretty cool. An great way to monitor for phishing domains[1]

[0] https://certstream.calidog.io/

[1] https://github.com/x0rz/phishing_catcher https://blog.0day.rocks/catching-phishing-using-certstream-9...

Good general summary, but it misses some big issues with revocation checking.

OCSP servers are notoriously unreliable - and with the increasing use of tls I don't see that improving - and that required open failure for TLS connections in browsers. That kind of defeats the purpose of revocation checks as someone can kill the OCSP connection and browsers will have to continue. Even when EV certs were a thing OCSP responders had a tendency to go down.

The really big problem though is privacy - revocation checks require transmitting every server name you are accessing, and secure DNS (if it existed) would not be sufficient to hide where you are navigating.

CT "solves" this by at least requiring an SCT so we know that in principle any cert we do encounter has been posted somewhere where effected individuals can see a misissuance. This obviously doesn't stop misissuance, it just makes it visible and allows us to determine whether CAs have verification flaws, etc. It also doesn't do anything about revocation checking as that is still dependent on OCSP, so has the aforementioned problems. Part of the move to short term certificates is to reduce the need for revocation checks as the lifetime of threat is much more restricted, so someone has to repeatedly compromise a CA to maintain an attack.

One other mechanism browsers have is certificate kill lists, which came into existence following the CNNIC and Symantec misissuances - essentially in the event of high profile/major site misissuance vendors can post a more or less immediate "don't trust these certs" list that is fast and robust vs. OCSP.

Fantastic summary. For anyone wanting to search CT logs, Sectigo operates https://crt.sh/ for that. For instance here are all non-expired certificates containing a twitter subdomain: https://crt.sh/?Identity=%25.twitter.com&exclude=expired

edit: s/Digicert/Sectigo - thanks jaas

It's interesting that CT effectively publishes all of your HTTPS endpoints. Using your example, it's possible to see a bunch of twitter hosts it might be hard to find otherwise. This effect of CT has been surprisingly uncontroversial, in contrast to DNSSEC where enumeration concerns have probably delayed adoption:

https://www.cloudflare.com/dns/dnssec/dnssec-complexities-an...

I suppose you can get around enumeration concerns with CT by using a wildcard cert. It's always seemed odd to me to worry about information in a public database like DNS being retrievable on bulk anyway - that approach is just security by obscurity.

DNSSEC enumeration also exposes all the hosts in your zone, and CT exposes only the hosts with publicly verifiable certificates.

But not everyone uses wildcard certs so enumeration is a problem. Also lots of people use certs with internal hostnames on public servers (they shouldn’t but it does make some things easier and not everyone is aware of the security issues). When CT first came out I remember running searches for some of our client’s domains and being easily able to identify Exchange servers, RDP servers, etc along with the corresponding internal hostnames which makes it easy to identify potential targets for attack.

Obscurity does have a role to play in security - leaving your front door unlocked is unlikely to be a problem but if you publish that information in a publicly searchable database then you are making yourself a target

It is the new "zone transfer" without the IP addresses :)

There are companies that use private (not publicly resolvable) domains for which they create public certificates for internal hosts, that get published via CT.

Nice for OpsSec sleuthing.

Edit: how to find these "private domains"? Often public certificates contain more than one DNS names, of which one might be "private". YMMV

Reply on news.ycombinator.com