Joao, Willy, Am 17.05.19 um 12:14 schrieb Joao Morais: >> Absolutely, I've already read about this though I don't know the >> implementations details. Similar concepts have been discussed quite >> a bit on the HTTP WG, though I don't undertand the details of each >> variation. The main thing is that sometimes the browser will consider >> that the connection is safe to be used for another domain name because >> the first one is considered authoritative on it. I'm not sure whether >> it only learns this from the cert or also from some response headers >> though. This is also why I always say that routing on SNI is wrong >> and that only the Host header is relevant. > > Everything was working without a single problem because we in fact route our > requests based on Host header. The problem started when we need validate some > requests based on client certs and, randomly, the DN and SHA1 headers wasn’t > provided.
Yes, client certificates are my biggest concern as well, because it easily introduces security vulnerabilities: Connect to a domain without validation and provide a Host header with validation to circumvent it. That's why I decided early that I want to verify the Host header against SNI. For me it's easy, because I don't use multi-domain certificates and instead use one Let's Encrypt certificate per subdomain. So there is no legitimate request with mismatching Host vs SNI. Willy: I wonder if that's something HAProxy itself should detect: When a client certificate is provided for a connection and the Host header does not match the SNI then an 421 is sent automatically (that behaviour of course being configurable). Joao: For your case the 421 with the example configuration of my previous email should do the right thing according to the specification, but I never tested my patch in the real world. Best regards Tim Düsterhus
