Hacker News Reader

Comment by AtNightWeCode | Hacker News Reader

Biggest? How about serving TLS certs when doing direct IP access? Or how about leaking sub domains in TLS certs?

I, as a mediocre hacker, cough, security advisor, cough, use certs to find vulnerable subdomains all the time. Or at least. I get to play around in your test envs.

Edit: Ok, the problem in the topic is also not good.

View on HN

I was wondering recently if it's better to use wildcard certs because of this. On the other hand, all sub-domains are discoverable through DNS anyways. Does it then make a difference if the sub-domains are logged in the certificate transparency logs?

How do you figure all subdomains are discoverable through DNS? The zone transfer record or whatever it is is usually disabled. And you can't bruteforce all subdomains - they might be too long/unpredictable.

I was mistaken about this apparently. There are tools though, that can discover subdomains using long lists of commonly used names and patterns. Anyways thanks for the correction.

Public DNS servers use rate-limiting in various ways. It should not be possible to do a large brute force attempt.

The title was "The browsers biggest TLS mistake"...

This strikes me as interesting even if it's a field I have very light understanding, and feel like I might fall victim to this. Asking for a friend, but if that friend uses Let's Encrypt to create certs for subdomains on a single vhost, what would that friend need to do to see the information you are seeing?

Certificate issuance transparency logs are public.

Every time a CA issues a new certificate, it gets logged in a public log.

Every time someone sets up nextcloud.example.tld, and gets an SSL cert issued by a CA, that gets logged in public. If nextcloud.example.tld resolves, and responds on tcp/80 and/or tcp/443, you’ve got yourself a potential target.

Reply on news.ycombinator.com