httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steffen <i...@apachelounge.com>
Subject Re: 2.4.17-protocols-http2/ - SNI issue
Date Fri, 18 Sep 2015 11:20:13 GMT

Indeed subjectAltnames are very common in use.

Windows 10 IE(Edge) browser same issue.

User sees in Chrome:
Misdirected Request. The client needs a new connection for this 
request as the requested host name does not match the Server Name 
Indication (SNI) in use for this connection.

And then times out.

Btw.
The config has no vhost (SSL only), what works fine http/1.1 with 
2.4.16-
..
..
...
DocumentRoot ....
ServerName ....
Listen 443
SSLStrictSNIVHostCheck off
SSLEngine on
SSLHonorCipherOrder On
SSLUseStapling on
SSLCipherSuite .......

SSLCompression off

SSLCertificateFile ......
SSLCertificateKeyFile ......
...
...
....


Steffen


On Friday 18/09/2015 at 12:58, Stefan Eissing  wrote:
> Ok, what is happening for Steffen is not a bug, but a missing feature. 
> The question is how we move forward.
>
> The certificate at apachelounge.com has a long list of 
> subjectAltNames, probably common for a lot of sites. Chrome opens a 
> connection to server1, established h2, keeps it open. You open a tab 
> on server2, chrome sees the altName on the server1 cert and *reuses* 
> that connection to send the request for server2.
>
> httpd sees that the request is not in the same vhost as the one 
> belonging to the SNI server1 and refuses to serve it with a 421. Which 
> rfc7540 intended for this, telling the client to use a new connection.
>
> Question to Steffen:
> - what error does the chrome user see? Is it interrupting his 
> browsing?
>
> Questions to All:
> 1. logging an ERROR for this will spam the log more and more in the 
> future. We can use a DEBUG level if we are *not* on a 'http/1.1' 
> protocol. ERR for 'http/1.1'.
> 2. We can check if the r->hostname is in the altNames of the server 
> cert for the connection. Question is: what to do then? The request 
> processing will select the correct vhost based on r->hostname, but any 
> SSL parameters will not be triggered probably? Do we want to accept 
> that?
> 3. We can allow 2 only for non-http/1.1 connection protocols
> 4. We can allow 2 only for h2 connection protocols
> 5. We can add a config directive to allow 2 (urgs)
>
> //Stefan
>
>>
>> Am 18.09.2015 um 11:36 schrieb Stefan Eissing 
>> <stefan.eissing@greenbytes.de>:
>>
>> I think I found it. Just writing a test case to confirm...
>>
>>>
>>> Am 18.09.2015 um 11:35 schrieb Steffen <info@apachelounge.com>:
>>>
>>> Debug log attached.
>>>
>>>
>>>
>>> On Wednesday 16/09/2015 at 12:06, Plüm wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>>>>> Sent: Mittwoch, 16. September 2015 11:38
>>>>> To: dev@httpd.apache.org
>>>>> Subject: Re: 2.4.17-protocols-http2/ - SNI issue
>>>>>
>>>>> Good point. Limited online today. If someone wants to give this a 
>>>>> shot,
>>>>> please.
>>>>>
>>>>>>
>>>>>> Am 16.09.2015 um 11:36 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>>>>>>
>>>>>> On Wed, Sep 16, 2015 at 11:24 AM, Plüm, Rüdiger, Vodafone Group
>>>>>> <ruediger.pluem@vodafone.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Steffen
>>>>>>>> Sent: Mittwoch, 16. September 2015 11:14
>>>>>>>> To: dev@httpd.apache.org
>>>>>>>> Subject: 2.4.17-protocols-http2/ - SNI issue
>>>>>> []
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [ssl:error] [pid 3428:tid 3952] AH02032: Hostname 
>>>>>>>> http://www.apachelounge.com
>>>>>>>> provided via SNI and hostname http://www.apachelounge.com
provided via 
>>>>>>>> HTTP
>>>>>>>> are different
>>>>>>>
>>>>>>> The above is very weird as both times we see 
>>>>>>> http://www.apachelounge.com. Can
>>>>> you please check the logs with some kind of hex tool if there is 
>>>>> really no
>>>>> difference between both strings? The logic to detect a difference in

>>>>> the
>>>>> code is just a usual strcasecmp. So I sense some hidden characters
>>>>> somewhere, which might give us a hint where things go really wrong.
>>>>
>>>> Ahh I did miss that he used Stefans branch and not the 2.4.x branch.
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> ISTM that the test should be:
>>>>>>                          if (strcasecmp(host, servername)
>>>>>>                                  || (sslconn->server
>>>>>>                                          && 
>>>>>> !ssl_util_vhost_matches(host, sslconn->server)))
>>>>>>
>>>>>> instead of:
>>>>>>                        if (strcasecmp(host, servername)
>>>>>>                                  || !sslconn->server
>>>>>>                                  || !ssl_util_vhost_matches(host,

>>>>>> sslconn->server))
>>>>>>
>>>>>> Not sure sslconn->server isn't NULL here for the first request.
>>>>
>>>> I shouldn't be. Maybe setting the loglevel to Debug could help to see 
>>>> the other SNI stuff that was going on before and if it correctly 
>>>> identified the correct vhost via SNI.
>>>>
>>>> Regards
>>>>
>>>> Rüdiger
>>>
>>> <serror.log>
>>
>> <green/>bytes GmbH
>> Hafenweg 16, 48155 Münster, Germany
>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>
>>
>>
>
> <green/>bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>
>
>


Mime
View raw message