Re: How to disable httpd's default
You can make a rewrite to redirect all defaults to your main site (either https or non-https). ありがとう えりな On Fri, Jan 14, 2022 at 7:59 AM 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. > > Is there some way to do something like: > > server "default" { > listen on * port 80 > listen on * port 443 > block drop > } > > And then only serve specific domains? >
Re: How to disable httpd's default
On Thu, Jan 13, 2022 at 11:46:18PM +, i...@protonmail.com 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?
Re: How to disable httpd's default
Crystal Kolipe writes: > On Thu, Jan 13, 2022 at 11:46:18PM +, i...@protonmail.com 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. Manually generating fake certificates feels like the wrong solution for this.
Re: How to disable httpd's default
i...@protonmail.com writes: > I would like to avoid httpd giving anything if a user types in the IP > address of the server. httpd.conf(5) says: server name {...} Match the server name using shell globbing rules. This can be an explicit name, www.example.com, or a name including wildcards, *.example.com. >From that I would expect to be able to create server blocks enumerating valid hostnames, name the last block "*", and specify a self-signed certificate with a domain name of "invalid". So I tried it: server "example" { listen on * port 80 listen on * tls port 443 tls certificate "/etc/ssl/example.crt" tls key "/etc/ssl/private/example.key" } server "*" { listen on * port 80 listen on * tls port 443 tls certificate "/etc/ssl/invalid.crt" tls key "/etc/ssl/private/invalid.key" block } Results: - http://example/ displays index.html (expected) - http://127.0.0.1/ displays 403 (expected) - http://noexist/ displays 403 (expected) - https://example/ displays index.html, cert for example (expected) - https://127.0.0.1/ displays 403, cert for example (unexpected) - https://noexist/ displays 403, cert for example (unexpected) Is that a bug? I can "force" the desired behavior by duplicating the invalid block to mention that certificate first. But it doesn't seem like that should be necessary. server "invalid" { listen on * tls port 443 tls certificate "/etc/ssl/invalid.crt" tls key "/etc/ssl/private/invalid.key" block } server "example" { listen on * port 80 listen on * tls port 443 tls certificate "/etc/ssl/example.crt" tls key "/etc/ssl/private/example.key" } server "*" { listen on * port 80 listen on * tls port 443 tls certificate "/etc/ssl/invalid.crt" tls key "/etc/ssl/private/invalid.key" block } - http://example/ displays index.html - http://127.0.0.1/ displays 403 - http://noexist/ displays 403 - https://example/ displays index.html, cert for example - https://127.0.0.1/ displays 403, cert for invalid - https://noexist/ displays 403, cert for invalid
Re: How to disable httpd's default
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 +, i...@protonmail.com 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?)
Re: How to disable httpd's default
On Fri, Jan 14, 2022 at 03:21:03AM -0700, Anthony J. Bentley wrote: > From that I would expect to be able to create server blocks enumerating > valid hostnames, name the last block "*", and specify a self-signed > certificate with a domain name of "invalid". You just commented in another mail in this thread that you considered 'manually generating fake certificates' to be the wrong solution! > I can "force" the desired behavior by duplicating the invalid block > to mention that certificate first. But it doesn't seem like that > should be necessary. It's not. Put the invalid block first and remove the wildcard block at the end.
Re: How to disable httpd's default
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.
Re: How to disable httpd's default
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.
Re: How to disable httpd's default
On 1/13/2022 6:46 PM, i...@protonmail.com 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. Is there some way to do something like: server "default" { listen on * port 80 listen on * port 443 block drop } And then only serve specific domains? I've done something like this with haproxy using SNI routing, but for different reasons. Unfortunately this requires running haproxy as root, and haproxy has to be in the routing path. Having it on the same machine is probably ok. Note that this does not require haproxy to have the client certificates, since the hostname is transmitted in plaintext with SNI. Config snippets: frontend ft_ssl_vip bind :443 mode tcp tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } default_backend bk_ssl_default backend bk_ssl_default mode tcp source 0.0.0.0 usesrc clientip acl app_one req_ssl_sni -i one.example.com acl app_two req_ssl_sni -i two.example.com acl app_threereq_ssl_sni -i three.example.com use-server one if app_one use-server two if app_two use-server three if app_three use-server default if !app_one !app_two !app_three option ssl-hello-chk server one 1.2.3.4:443 check server two 4.5.6.7:443 check server three 7.8.9.10:443 check server default 11.12.13.14:443 So, server default can answer with whatever cert you want, and one, two, three can answer with their correct certs. Scanners won't connect to one, two, three unless they already know the host names. Of course, this is somewhat futile with Certificate Transparency, since all your host names will be listed publicly anyway.
Re: How to disable httpd's default
On Fri, Jan 14, 2022 at 08:59:00AM -0500, Steven Shockley wrote: > Note that this does not require haproxy to have the client certificates, > since the hostname is transmitted in plaintext with SNI. At the moment, yes, but at some point we might implement ECH...
Re: How to disable httpd's default
On Fri, Jan 14, 2022 at 07:50:36PM +, i...@protonmail.com wrote: > > It's not. Put the invalid block first and remove the wildcard block at the > > end. > > It doesn't work. Then the valid domains gets served with the > self-made certificate. It does work. You must have an error in your config file.