Hacker News new | ask | show | jobs
by mercora 1780 days ago
while it is easy to see the desired hostname for an SSL connection that makes use of SNI it is also very easy to simply connect to the address someone is communicating with and see what certificate is presented to you. it probably even works by just intercepting it... that keeps being practical as long as non SNI enabled connection or let alone ECH enabled ones are expected to work as well...
1 comments
tialaramex 1780 days ago
Unless it deliberately doesn't need a name (e.g. DoH servers like 1.1.1.1 or 8.8.8.8) TLS servers have no reason to respond to connections that don't specify a name with anything other than confused dismay. "Um, who are you calling?".

It's a misfeature of some common web server software that you get a "default" web site as if this was still 1998 and your web browser might not know about HTTP 1.1 yet. The specification doesn't suggest doing this as far as I know and it has caused numerous security problems.

Likewise ALPN. The client has to say which ALPNs they'd accept for this connection if any, and the server just picks one. The server is under no obligation to hint that it knows any particular ALPN or to let you connect without specifying.

link
mercora 1780 days ago
what i do is somewhat like you suggest. if haproxy cant determine which hostname it should serve it responds with a "503 Service Unavailable". However, if i expect someone to be able to actually receive that i still need to present a certificate to the client. i use wildcard certificates for this reason. the server wont tell you what names would actually work... you could just terminate connections or signal some kind of handshake error immediately instead though... most sites and services aren't likely to do that as its not very helpful in figuring out why it went wrong or explicitly will try to make it work for clients not supporting this. that's why i noted it being practical as long as incompatible clients are expected to work...
link
tialaramex 1780 days ago
TLS has a specific error "alert" unrecognised_name (112) that servers should send if the client doesn't provide a name they recognise (or indeed doesn't provide a name at all and they expected one).

If a web browser connects without specifying a name and it hoped to reach some.nonsense.example your wildcard certificate doesn't help it and it won't display your 503 Service Unavailable error, you aren't some.nonsense.example, it cannot proceed, so you shouldn't bother trying to "help".

link
mercora 1780 days ago
that's interesting i will investigate how to make use of that, thanks :)

EDIT: its really pretty easy to do apparently[0] although only unconditionally as it seems...

[0] https://cbonte.github.io/haproxy-dconv/2.4/configuration.htm...

link