Re: svn commit: r1703871 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c

2015-09-19 Thread Stefan Eissing 
Thx! done.

> Am 18.09.2015 um 17:38 schrieb Yann Ylavic :
> 
> On Fri, Sep 18, 2015 at 4:31 PM,   wrote:
>> Author: ylavic
>> Date: Fri Sep 18 14:31:48 2015
>> New Revision: 1703871
>> 
>> URL: http://svn.apache.org/viewvc?rev=1703871=rev
>> Log:
>> mod_ssl: update the current handshake server once a full regenegotation
>> succeeds, it is the new reference for further renegotiation or SNI check.
>> 
>> Modified:
>>httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
>> 
>> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1703871=1703870=1703871=diff
>> ==
>> --- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
>> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Fri Sep 18 14:31:48 
>> 2015
>> @@ -850,6 +850,11 @@ int ssl_hook_Access(request_rec *r)
>> r->connection->keepalive = AP_CONN_CLOSE;
>> return HTTP_FORBIDDEN;
>> }
>> +
>> +/* Full renegotiation successfull, we now have handshaken with
>> + * this server's parameters.
>> + */
>> +sslconn->server = r->server;
>> }
>> 
>> /*
>> 
>> 
> 
> This one may be needed in 2.4.17-protocols-http2 too...

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

Re: Disable SSLv3 by default

2015-09-19 Thread Kaspar Brand 
On 17.10.2014 19:25, Kaspar Brand wrote:
> On 17.10.2014 12:02, Takashi Sato wrote:
>> SSLv3 is now insecure (CVE-2014-3566, POODLE)
>> Let's disable SSLv3 by default, at least trunk.
>>
>> SSLProtocol default is "all".
>> 
>> "all" means "a shortcut for ``+SSLv3 +TLSv1'' or - when using OpenSSL
>> 1.0.1 and later - ``+SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2, respectively."
>>
>> Should we remove SSLv3 from "all" ?
> 
> From a semantic point of view, I wouldn't do that. As long as we still
> allow SSLv3 to be used, "all" should really mean "all protocols which
> can be enabled in mod_ssl".
> 
> I'm fine with changing the hardcoded default (in ssl_engine_config.c) to
> SSL_PROTOCOL_ALL & ~SSL_PROTOCOL_SSLV3, though.

For the record: this is part of r1703952 which I just committed to trunk
(and will propose for backporting to 2.4 shortly, unless there are
objections).

> The other option would be to drop SSLv3 support completely, like we
> currently do for SSLv2 in ssl_engine_init.c:ssl_init_ctx_protocol(). In
> this case, "all" would no longer include SSLv3, of course.

This is left as a next step, which I consider appropriate for trunk, at
least.

Kaspar

Re: 2.4.17-protocols-http2/ - SNI issue

2015-09-19 Thread Steffen 
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 :

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:i...@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.eiss...@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
  &&