Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 38B2817C8F for ; Fri, 18 Sep 2015 13:40:48 +0000 (UTC) Received: (qmail 5324 invoked by uid 500); 18 Sep 2015 13:40:47 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 5248 invoked by uid 500); 18 Sep 2015 13:40:47 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 5238 invoked by uid 99); 18 Sep 2015 13:40:47 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Sep 2015 13:40:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 53D3FF3F8B for ; Fri, 18 Sep 2015 13:40:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.901 X-Spam-Level: ** X-Spam-Status: No, score=2.901 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=apachelounge.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id i9tKBzxRqTrs for ; Fri, 18 Sep 2015 13:40:32 +0000 (UTC) Received: from land10web.com (land10web.com [80.101.236.247]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTP id 6AD6242BEC for ; Fri, 18 Sep 2015 13:40:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apachelounge.com; s=default; t=1442583683; bh=CtptKZkOp9BGDZXAujlaQCngbvSQ2P/i1zSB/yWrCm0=; h=From:To:Subject:Date; b=150oslCzpu6TpPJ6O4NVTvVH2iRV06A0OWcA12BJHPqMm8r01AeelcZLX2WabXP6X z5hSdwYnOtfyX4fUH1BVuGA/LgCglujHyBJcWWL9rrjf4/PObYGm9BbJ1fXZqBebn0 jMpSr2Ko8UeaL3FS+FTrUfPRs0RArJs8K2zLFuMk= X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=127.0.0.1; From: Steffen To: Subject: Re: AW: 2.4.17-protocols-http2/ - SNI issue Date: Fri, 18 Sep 2015 15:41:21 +0200 Message-ID: <55fc1481.b94.1e98.4562@land10.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_SW_1490_1442583681_mpa=" X-Originating-IP: 127.0.0.1 X-Mailer: SurgeWeb - Ajax Webmail Client This is a multi-part message in MIME format. ------=_SW_1490_1442583681_mpa= Content-Type: text/plain; charset=utf-8; format=flowed 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 >>> : >>> >>> I think I found it. Just writing a test case to confirm... >>> >>> >>> >>>> >>>> Am 18.09.2015 um 11:35 schrieb Steffen : >>>> >>>> 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 : >>>>>>> >>>>>>> On Wed, Sep 16, 2015 at 11:24 AM, Plüm, Rüdiger, Vodafone Group >>>>>>> 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 >>>> >>>> >>> >>> bytes GmbH >>> Hafenweg 16, 48155 Münster, Germany >>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782 >>> >>> >>> >> >> bytes GmbH >> Hafenweg 16, 48155 Münster, Germany >> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782 >> >> >> > ------=_SW_1490_1442583681_mpa= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Servername www.land10web.com

No directive Serv= erAlias  

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, P= l=c3=bcm wrote:

What are your settin= gs for

 

Servername

 =

And=

 

ServerAlias

 

? Do they have all= the stuff that is in the SAN?

<= span style=3d"font-size:11.0pt;font-family:"Calibri",sans-serif;co= lor:#00B050;mso-fareast-language:EN-US"> 

Regards

 

R=c3=bcdiger

 

Von: Steffen [mailto:info@apachel= ounge.com]
Gesendet: Freitag, 18. September 2015 13:20
An:<= /b> dev@httpd.apache.org
Betreff: Re: 2.4.17-protocols-http2/ - SN= I issue

 <= /o:p>

Indeed subjectAltnames are very common in use.=

 

Win= dows 10 IE(Edge) browser same issue.

 

User sees in Chrome:

Misdirected Request. The client needs a new connecti= on for this request as the requested host name does not match the Server Nam= e 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

SSLStrictSNIVHostChe= ck off

SSLEngine on 

SSLHonorCipherOrder On

SSLUseStapling on

SSLCipherSuit= e .......

SSLCompression off<= /o:p>

SSLCertificateFile ......

SSLCertificateKeyFile ......=

...

...<= /o:p>

....

 

Steffen

 

On Friday 18/09/2015 = at 12:58, Stefan Eissing wrote:

O= k, what is happening for Steffen is not a bug, but a missing feature. The qu= estion is how we move forward.

The certificate at apachelounge.com ha= s 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 ta= b on server2, chrome sees the altName on the server1 cert and *reuses* that= connection to send the request for server2.

httpd sees that the requ= est is not in the same vhost as the one belonging to the SNI server1 and ref= uses to serve it with a 421. Which rfc7540 intended for this, telling the cl= ient to use a new connection.

Question to Steffen:
- what error do= es 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 altNa= mes 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, b= ut 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 di= rective to allow 2 (urgs)

//Stefan


<= blockquote style=3d"border:none;border-left:solid #006312 1.5pt;padding:0cm = 0cm 0cm 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt">

Am 18.09.2015 um 11:36 schrieb Stefan Eissing <stefan.eissin= g@greenbytes.de>:

I think I found it. Just writin= g a test case to confirm...


= Am 18.09.2015 um 11:35 schrieb Steffen <info@apachelounge.com>:

Debug log at= tached.



On Wednesday 16/09/2015 at 12:06, Pl=c3=bcm wrote:




-----Original Message-----
From: Stefan Eissing [<= span style=3d"font-family:"Tahoma",sans-serif;color:#888888">mailto:st= efan.eissing@greenbytes.de]
Sent: Mittwoch, 16. September 2= 015 11:38
To: dev@httpd.apache.org
Subject: Re: 2.4.17-protocols-= http2/ - SNI issue

Good point. Limited online today. If someone wa= nts 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=c3=bcm, R=c3=bcdiger, Vodafone Group
&= lt;ruediger= .pluem@vodafone.com> wrote:



-----Original Message-----From: Steffen
Sent: Mittwoch, 16. September 2015 11:14
To: dev@httpd.apach= e.org
Subject: 2.4.17-protocols-http2/ - SNI issue

[]


[ssl:error] [pid 3428:tid 3952] AH02032: Hostna= me http://www.apac= helounge.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 t= he logs with some kind of hex tool if there is really no
difference betwe= en both strings? The logic to detect a difference in the
code is just a u= sual 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 no= t the 2.4.x branch.



ISTM tha= t the test should be:
        &nb= sp;     if (strcasecmp(host, servername)
  =             &nbs= p;   || (sslconn->server
      = ;            &nb= sp;   && !ssl_util_vhost_matches(host, sslconn->server)= ))

instead of:
        &nb= sp;    if (strcasecmp(host, servername)
   =             &nbs= p;  || !sslconn->server
       = ;           || !ssl_util_v= host_matches(host, sslconn->server))

Not sure sslconn->server i= sn't NULL here for the first request.


I shouldn't be. Maybe setting the loglevel t= o Debug could help to see the other SNI stuff that was going on before and i= f it correctly identified the correct vhost via SNI.

Regards

R= =c3=bcdiger


<ser= ror.log>


<green/>bytes GmbH
Hafenweg 16, 48155 M= =c3=bcnster, Germany
Phone: +49 251 2807760. Amtsgericht M=c3=bcnster: HR= B5782



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


 =


------=_SW_1490_1442583681_mpa=--