Crystal Kolipe writes: > On Fri, Jan 14, 2022 at 01:49:01AM -0700, Anthony J. Bentley wrote: > > The natural next question would be what leaks when someone accesses the > > server using a made-up hostname. > > By 'made-up hostname', I'm assuming that you mean connecting to the server's > IP address and then having the TLS handshake include an SNI field containing > a domain name that is not listed in the public DNS for that IP, and for > which the server is not specifically configured. > > In that case, what are you concerned about leaking?
I understood the original question to mean a situation like: the server is intended to serve pages for a given set of hostnames, including over TLS; if an IP address or any other hostname is requested, then don't serve any of those pages and don't leak any valid hostnames through the certificate. That's a question I've had myself. > I didn't suggest a 'fake' certificate. I suggested a certificate with a > literal IP in the CN and SAN fields. This would be the correct certificate > to present when connecting to the literal IP, and in the case of a 'made-up' > hostname that the server doesn't actually host, a literal IP cert makes > sense too. 'Fake' was not a judgmental term. I was suggesting that if there is no intent to serve actual content when the user manually enters an IP address, then there's no need for the certificate to manually specify the IP; instead it makes more sense to generate a single catch-all certificate for all invalid cases (many hostnames and potentially multiple IP addresses). In that case, the reserved name "invalid" makes sense, doesn't it? Regardless, you're right, specifying the invalid block first and dropping the wildcard block does work as expected in this situation.
