On Fri, Jan 14, 2022 at 01:49:01AM -0700, Anthony J. Bentley wrote: > Crystal Kolipe writes: > > On Thu, Jan 13, 2022 at 11:46:18PM +0000, [email protected] wrote: > > > I would like to avoid httpd giving anything if a user types in the IP > > > address of the server. > > > > > > At first I just made an empty page, which is fine for port 80, but if > > > the user then types https://xxx.xxx.xxx.xxx, then the certificate for a > > > domain shows, which doesn't fit the IP address. > > > > Why not create a dummy self-signed certificate that only has the IP > > address and no domain names? > > 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? The IP is already known, so presumably you are either concerned about leaking a hostname that is actually served, or details of the server and operating system in use. > Manually generating fake certificates feels like the wrong solution for this. 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. Of course, you can't easily or cheaply get a certificate for a literal IP address that is signed by a recognised CA. The original poster doesn't tell us his exact requirements or motives for setting up this server, so I'm assuming that it's a personal webserver. In that case, a self-signed cert for the fall-back literal IP case seems like the best option. In our case, we just present the cert for exoticsilicon.com for any requests to the literal IP, or any non-recognised domain. This leaks nothing as of course we have dns ptr records for the IPs, which resolve to subdomains of exoticsilicon.com. If you access the literal IP, or put an invalid hostname in SNI, the server presents the cert but serves no http content. The only exception is if you issue an invalid http request, for example, then you get a 400 error page served back. In our case that has been customised, so it shows references to exoticsilicon, but most users will just get a generic 400 bad request from httpd. So at most, you leak details of the operating system and webserver, and that works over plain unencrypted http as well, anyway, even using the 'block drop' directive, (which may in itself be a bug?)
