On Fri, Jan 14, 2022 at 05:52:21AM -0700, Anthony J. Bentley wrote: > 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.
Yes, I understood the question in the same way. > > 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 I don't 100% agree with that assumption. > 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? Well, I don't think that we should assume that a literal IP address and an invalid hostname are best treated in the same way. Assuming that the server config is correct, and that all DNS entries are correct, then requesting an invalid hostname makes no sense. There is no sensible response, and the request is likely to be coming from an unwanted bot anyway. So no point in serving any content, and since they already know your IP, nothing to gain or lose by serving a cert with just that IP in the CN and SAN. In the case of a request for a literal IP, that does potentially have a genuine use-case. Somebody debugging a problem with a broken client, network issue, DNS resolution problem, etc, etc. Ideally in this case, you would serve no http content, but with a real CA signed cert with the literal IP. That way, the client knows that they actually reached the intended machine, (no MITM), and can assume that the decision to serve no content was intentional. Since such a cert is not available free of charge, and most people would not want to pay for one, you can either use a cert for your real domain, (which we do), or a cert for a junk domain that you don't use, or a self-signed cert. I think that a self-signed cert for the literal IP case looks more professional, but at the end of the day, I suppose it doesn't really matter.
