How to reject connections to routes not specified?

Support
1

What happened?

I have Pomerium setup, as a binary, on an “edge” server, that reverse proxies our internal sites that need to be exposed to the world. Pretty standard.

I use LetsEncrypt and autocert, which works great.

However, I have a wildcard DNS record pointing to the instance, and when a user visits a url that is not a route specified in the config, they are presented with Pomeriums self signed cert.

This means, any routes I destroy, or host-names that resolve but aren’t actually routed present an “insecure” cert to the world.

What did you expect to happen?

Something else, I am not sure what. Either connection should be refused (wouldn’t work, since we are listening on the port) or some sort of server response. But as far as I understand, you can only respond AFTER the browser has connected, so there is no way to avoid the self-signed cert being offered up.

So, maybe it would be better to have the ability to define a route (so autocert does it’s thing) that you can then respond to with 404. Or would you use redirect for that?

That might solve one problem, the other being the wildcard cert… Should I rather change the way I advertise the DNS entries? i.e. Don’t use the wildcard record but rather list them explicitly?

How’d it happen?

  1. Setup pomerium with Autocert
  2. Pointed wildcard domain to Pomerium host
  3. Saw self-signed certs on urls which are not present in the routes config.

What’s your environment like?

  • Pomerium version (retrieve with pomerium --version):

    • pomerium: 0.18.0-1658889797+89a105c8
    • envoy: 1.21.3+4861429dfffb599f28b9399c34ea2a2c268bfb6d10aca0a53bc9b67d847a4595

  • Server Operating System/Architecture/Cloud: Ubuntu 18.04 on VM

What’s your config.yaml?

I can add this if needed, but I am not sure it’s going to tell much.

What did you see in the logs?

Nothing, just normal behaviour.

2

A custom 404 page might be possible, but it would not solve the problem. We’d still serve a self-signed certificate, because autocert will not retrieve a certificate for an arbitrary domain name.

I believe a redirect will suffer from the same problem. The browser will complain before doing the redirect.

Severing the TCP connection is also not possible. I looked into Envoy configuration and there doesn’t appear to be a way to implement this.

Possibly we could update the autocert code to provision a wildcard certificate. Lets Encrypt supports those, though I don’t remember the specifics of how that’s implemented.

3

Thanks for the reply @calebdoxsey, I thought that might be the case, that one cannot really stop the connection before the cert exchange has taken place.

Regarding wildcard certs, that might become more relevant if Pomerium supports wildcard domains in the routes, as per this feature request here.

Even if Pomerium does support it in the future, the LetsEncrypt setup is not as simple. One needs to use a DNS TXT record for verification, which makes things much more complex. Link

So, it seems my options are limited. Either stop using a wildcard domain (probably what I will go for) or manually issue a wildcard cert via LetsEncrypt with the DNS-01 challenge.

I hope this helps anyone else with similar issues, I don’t think there is anything more to “support” :slight_smile: Thanks @calebdoxsey

4

Hmmmm, thinking about it a little further, it should be theoretically possible to sever the connection before offering up the cert… envoy has to know what hostname has been requested, otherwise it couldn’t offer up the right certificate?

So I think I will look into this a bit more…