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 Sat, 19 Sep 2015 10:35:23 GMT
Yep, build 2.4.17-protocols-http (Exported revision 1703949) with mod_h2 
(v0.9.7, nghttp2 1.3.2)

A quick initial test result:  no anymore Misdirected Request's, so it looks 
promising.

I already saw in the log AH01991: SSL input filter read failed, have to 
figure out when this happens (maybe not an issue)

Coming week I do further testing.

Steffen



-----Original Message----- 
From: Stefan Eissing
Sent: Friday, September 18, 2015 3:50 PM
To: dev@httpd.apache.org
Subject: Re: 2.4.17-protocols-http2/ - SNI issue

Please update 2.4.17-protocols-http and hopefully this will improve your 
situation with the patch by Yann.

//Stefan

> Am 18.09.2015 um 15:41 schrieb Steffen <info@apachelounge.com>:
>
> Servername www.land10web.com
>
> No directive ServerAlias
>
> Use it as SSL front-end and reverse-proxy to the different domains 
> (vhosts) in a non SSL Apache..
>
> Same config works all fine with 2.4.16-.
>
>
> Regards,
>
> Steffen
>
> On Friday 18/09/2015 at 13:56, Plüm wrote:
>> What are your settings for
>>
>> Servername
>>
>> And
>>
>> ServerAlias
>>
>> ? Do they have all the stuff that is in the SAN?
>>
>> Regards
>>
>> Rüdiger
>>
>> Von: Steffen [mailto:info@apachelounge.com]
>> Gesendet: Freitag, 18. September 2015 13:20
>> An: dev@httpd.apache.org
>> Betreff: Re: 2.4.17-protocols-http2/ - SNI issue
>>
>> 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
>>
>>
>>
>>
>
>

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782




Mime
View raw message