Re: How to disable httpd's default

[Crystal Kolipe]

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.

Re: How to disable httpd's default

[Crystal Kolipe]

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

[Steven Shockley]

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

[Crystal Kolipe]

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

[Anthony J. Bentley]

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

[Crystal Kolipe]

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]

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

[Anthony J. Bentley]

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

[Anthony J. Bentley]

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

[Crystal Kolipe]

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

[Yamadaえりな]

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?
>