
Certificate Transparency: a bird's-eye view - fanf2
https://emilymstark.com/2020/07/20/certificate-transparency-a-birds-eye-view.html
======
cle
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?

~~~
thayne
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.

~~~
cle
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.

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

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

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

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

------
arkadiyt
Fantastic summary. For anyone wanting to search CT logs, Sectigo operates
[https://crt.sh/](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](https://crt.sh/?Identity=%25.twitter.com&exclude=expired)

edit: s/Digicert/Sectigo - thanks jaas

~~~
angrygoat
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...](https://www.cloudflare.com/dns/dnssec/dnssec-complexities-and-
considerations/)

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.

~~~
funnybeam
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

