Re: TLS ALPN Proposal v3

> Am 22.07.2015 um 11:06 schrieb Patrick McManus <mcmanus@ducksong.com>:
> 
> 
> >On Wed, Jul 22, 2015 at 10:46 AM, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
> >You assume that a client talks to a server and that these two determine the security of the connection at connection setup.
> 
>  
> >But does it also imply that CDNs may only talk h2 to clients if the backend connection they might possibly need is also h2 with all security requirements followed? >And if the backend connection needs to be setup/reopened and fails some requirements, must all client connections be dropped?
> 
> 
> unless I am seriously misunderstanding the state of the art (or your comment) the CDN presents itself as the origin (e.g. it has a TLS cert valid for the origin). Whether it satisfies a request locally, via gateway as some version of HTTP, or through gatewaying ftfp is immaterial to the communication with the client. The CDN-based-origin could speak h2 to the client in all those scenarios but it would have to do so over tls 1.2 and with a cipher suite acceptable to rfc 7540.

As I understand it, a CDN will pass your basic request through whenever it touches some "personal" resource and handle all the decorations through its cache. That means, and I might be wrong, that the sensitive traffic that h2 tries to protect is exactly the one that gets sent through the backend connection. The CDN poses as origin, but it is not really "the one", it just has copies of the keys.

I am all for privacy and good ciphers and all. But I sense a certain implicated feeling of safety in h2 client/server security requirements where reality is not that simple. Of course, CDNs will try to secure connections and encourage customers to upgrade to latest standards. But will they be tempted to offer h2 to users for customers that are still on h1? I think they will. So the safe Firefox h2 request jumps out the backbone of a CDN via h1 to the customers site.

And the story is the same for every h2 reverse proxy that is not co-located in the very same data center, I assume.

Using h2 as a stepping stone for upgrading the http security in general is good. And it is an excellent feature in a browser and a good place to put it (especially when I see my mother using the web). But a general purpose server might work in quite different environments and might need some more flexible interpretations of the standard regarding this. Leaving the secure configuration to the server admin who is hopefully aware of its implications.

So, if, after taking usual orders and preferences into account, client and server agree to a cipher that is not compliant to 7540, I am not convinced to write any code to stop that.

>  >, I think this is not some esoteric gedankenmodell, but a real world scenario.
> 
> I don't know what that means (beyond the obvious guess), but I like the way it sounds in my head :)

;-) German nouns are best, we leave the verbs to the anglo-saxons...

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

Received on Wednesday, 22 July 2015 09:59:48 UTC