[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    RE: HTTP_MISDIRECTED_REQUEST
From:       Plüm, Rüdiger, Vodafone Group <ruediger.pluem () vodafon
Date:       2015-08-31 9:52:21
Message-ID: AB1691BE05AE7F4992697F2A0835627AC630C77D () VOEXM10W ! internal ! vodafone ! com
[Download RAW message or body]



> -----Original Message-----
> From: Stefan Eissing 
> Sent: Montag, 31. August 2015 11:48
> To: dev@httpd.apache.org
> Subject: Re: HTTP_MISDIRECTED_REQUEST
> 
> 
> > Am 28.08.2015 um 15:49 schrieb Eric Covener <covener@gmail.com>:
> >
> > On Fri, Aug 28, 2015 at 9:26 AM, Stefan Eissing
> > <stefan.eissing@greenbytes.de> wrote:
> >> If this works, one could think about introducing some kind of
> "equivalence number" to speed up the checking, since in certain HTTP/2
> setups there might be a good percentage of requests requiting this
> verification.
> >
> > Long term we need to block these name-based renegotiations because
> > we'll be at TLS1.3.  I don't know how to ween people off, but making
> > up an H2 requirement might be one way to ease people into it.
> 
> I am not the expert on TLS renegotiation, I am just aware that certain TLS
> parameters can be changed on an existing connection if both parties agree.
> And I am aware that this has been used in attacks and the feature seems to
> be frowned upon nowadays.
> 
> I see mod_ssl code that checks for renegotiations based on directory
> configurations, so it is request based. And it will fail miserably in
> HTTP/2 connections as there is no longer *the one current* request on a
> connection.
> 
> What would be the most common scenarios for TLS renegotiation be that we
> should users warn about when enabling HTTP/2? Is requiting a client cert a
> common use here?

Everything that you configure in directory context. Be it client certs or SSL ciphers.

Regards

Rüdiger


[prev in list] [next in list] [prev in thread] [next in thread]