The Dark Side of Certificate Transparency
I am a big fan of the idea behind Certificate Transparency [1]. The real problem with SSL (and TLS... it really doesn't matter for this discussion) is not the weak ciphers or subtle issues with algorithms (yes, you should still fix it), but the certificate authority trust model. It has been too easy in the past to obtain a fraudulent certificate [2]. There was little accountability when it came to certificate authorities issuing test certificates, or just messing up, and validating the wrong user for a domain based on web application bugs or social engineering [3][4].
With certificate transparency, participating certificate authorities will publish all certificates they issue in a log. The log is public, so you can search if someone received a certificate for a domain name you manage.
You can search certificate transparency logs published by various CAs directly, or you can use one of the search engines that already collect the logs and use them to search [1].
For example, here is an "interesting" certificate for "sans.org", issued by the infamous Symantec test CA [5].
So what is the "dark side" part?
Many organizations obtain certificates for internal host names that they do not necessarily want to be known. In the past, internet wide scans did catalog TLS certificates, but they only indexed certificates on publicly reachable sites. With certificate transparency, names may leak that are intended for internal use only. Here are a few interesting CNs I found:
vpn.miltonsandfordwines.com upstest2.managehr.com mail.backup-technology.co.uk
To find these, I just searched one of the Certificate Transparancy Log search engine, crt.sh , for "internal".
There are currently two options considered to "fix" this problem:
- Allow customers to opt out of having their certificate logged. This is a bad idea. Malicious customer would certainly opt out.
- Redact sub-domain information from the log. This is currently in the works, but the current standard doesn't support this yet. In the long run, this appears to be a better option.
But you should certainly regularly search certificate transparency logs (or any scans for SSL certificates) for your domain name to detect abuse or leakage of internal information.
[1] https://www.certificate-transparency.org
[2] https://security.googleblog.com/2015/03/maintaining-digital-certificate-security.html
[3] http://oalmanna.blogspot.ro/2016/03/startssl-domain-validation.html
[4] https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-certificates-from-comodo-via-dangling-markup-injection/index.html
[5] https://censys.io/certificates/1ceea0c068af62faa2974de81f8f7ba6973bb0186e3856bd1ae2c80633cdb3a1
Comments
www
Nov 17th 2022
4 months ago
EEW
Nov 17th 2022
4 months ago
qwq
Nov 17th 2022
4 months ago
mashood
Nov 17th 2022
4 months ago
isc.sans.edu
Nov 23rd 2022
4 months ago
isc.sans.edu
Nov 23rd 2022
4 months ago
isc.sans.edu
Dec 3rd 2022
3 months ago
isc.sans.edu
Dec 3rd 2022
3 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
isc.sans.edu
Dec 26th 2022
3 months ago
isc.sans.edu
Dec 26th 2022
3 months ago