Re: http/1 opportunistic encryption

> Am 18.06.2015 um 10:26 schrieb Stefan Eissing <stefan.eissing@greenbytes.de>:
> 
> So, basically the trick would be to have a client call http: into a https: port, server sets cookie, client later reopens connection against http: and sends cookie in the clear. And with h2, the server can detect that http: was requested, and avoid setting the secure cookie.
> 
> Ok, thanks for the explanation.
> 
> I think, as a consequence, I need to disable the Alt-Svc support for http: in mod_h2, since scheme information is not available to others living inside Apache httpd and the described http/1.1 exploit will work exactly the same with h2 involved. I think some
> 
> Feedback to the spec itself, ch. 6.4:
> The confusion about the request scheme in real life servers has seldom anything to do with the protocol being served. "h2" and "http/1.1" requests will be, from an application point of view, be indistinguishable, especially for all of the existing web. Servers will add "h2" support in the most compatible way and that means taking care that existing applications continue to run.
> 
> Saying that the scheme confusion has anything to do with h1 vs h2, is not giving the complete picture. Admins who advertise h2 as Alt-Svc for http: resources might feel safe when indeed they are not.
> 
> And the advice for server implementations would then be to make sure that the TLSiness of the connection gets hidden from any application that processes such requests, regardless of the http version used. And additionally, that using port 443 for such a transport is not a good idea, because apps might use that as an indicators of httpsiness as well.
> 

Correction to my last paragraph: the transport port number needs to be hidden as well and, at least with h1, 443 should not be used.

>> Am 17.06.2015 um 18:25 schrieb Martin Thomson <martin.thomson@gmail.com>:
>> 
>> On 17 June 2015 at 01:50, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>>> Well, it's the server that announces the Alt-Svc, so it has to know what it's doing - as with everything else. I
>> 
>> 
>> The concern is that it might not be the server that provided the
>> announcement.  It could have been a rogue resource that set a header
>> field, or a MitM.  One attack of concern is where the server releases
>> a secure cookie into an insecure context.
> 
> <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

Received on Thursday, 18 June 2015 08:59:13 UTC