httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: SNI Host: header mismatch
Date Thu, 11 Jun 2015 16:08:28 GMT
Yes, it will work with the cert checks, not without. Sorry, if that was confusing. 



> Am 11.06.2015 um 17:56 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
> 
> On Thu, Jun 11, 2015 at 4:33 PM, Stefan Eissing
> <stefan.eissing@greenbytes.de> wrote:
>> Two things:
>> 
>> 1. the minimal thing to fix the situation is to return 421 instead of 400. H2 clients
will then open a new TLS connection for the request host. I don't know if this breaks any
HTTP/1 clients, however it should not.
> 
> I think this should be OK, HTTP/1 clients are prepared to received
> unknown error codes AFAICT.
> 
>> 
>> 2. Given that we answer not matching combinations with 421, the admin should be given
the opportunity to allow this via some directive. This makes it easier for her to do "anti-sharding"
for h2 clients.
>> 
>> ap_matches_request_vhost() / ServerAlias is not the right choice, if I understand
it correctly, since the non-matching request is really intended for another vhost and not
just a using a fancy name for the real SNI one.
>> 
>> If there were named SSL configurations, httpd could allow connection reuse for all
vhosts with the same SSL config. Alternatively, is there a good way to check that two vhosts
use the same certificate (key)? That could work as well.
> 
> That's why I (also) proposed to check the SNI against the current
> vhost's certificate's subject CN and/or AltNames (for wildcard certs).
> AIUI, the client should not reuse connections unless one of those matches.
> 
> Why wouldn't that work?
> 
> Regards,
> Yann.

Mime
View raw message