Re: TLS ALPN Proposal v3

On 22/07/2015 9:59 p.m., Stefan Eissing wrote:
> 
>> Am 22.07.2015 um 11:06 schrieb Patrick McManus:
>> 
>> 
>>> On Wed, Jul 22, 2015 at 10:46 AM, Stefan Eissing 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.

No. Perhapse some CDN operate that way, but its not part of HTTP. There
is no such thing as personal responses in HTTP. Just variant objects for
resources.
How the CDN fetches any given variant of a resource is also immaterial
to the h2 selection.

If you are only sending sensitive info over h2 (or h2c) then you are
doing it wrong. HTTP/2 is the successor to HTTP/1. When available you
should send all messages over it instead of HTTP/1.


> 
> 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.
> 

The intention is that they can do so. As Patrick said the frontend and
backend connections are unrelated.

Several very prominant CDN even offer HTTPS port 443 to clients, then
send the traffic over unencrypted port 80 to the backend servers. Oh
shock horror - its "only" protected by a hardened VPN private network.



If you look at the list of permitted h2 ciphers closely you will see
that it is just setting a minimum TLS version of 1.2. And disallowing
the ciphers 1.2 permits which are already known to be easily broken today.
 Any security conscious server is already restricting itself to that
RFC7540 set. Nothing particularly controversial. Nor is it particularly
about privacy. The same restrictions will happen naturally on HTTP/1
connections with up to date software.

The whole ALPN problem is that HTTP/1 servers still need to support
legacy clients without TLS/1.2 support. So can't outright forbid the
older ciphers and protocols being used. Despite the RFCs already out
there banning RC4, MD5, etc.


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

The story is in fact the same for any HTTP software. Its simply how HTTP
works. Proxy and gateway are written into the protocol.


> 
> 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.

The problem is that once anyone significant does relax the criteria
there is a growth in pressure for all other servers to implement
similarly lax security. Since the prohibited ciphers are *already* known
to be broken, why would you want to encourage their continued use in
*new* software releases?

The WG members had some long debates over this topic already. (I'm
getting De ja Vu just reading this thread.). It was forced on us by our
timing vs TLS/1.3 standardization. The truce agreed to was what you see
written in the RFC, with best current practice implementation being the
cipher and ALPN sorting as described by Martin earlier.

Although some of us like the overall outcome less than others this is
the agreed *minimum* standard of security implementations required for
HTTP/2 with TLS (h2).


> 
>>> , 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...
> 

Ditto. :-)

Amos

Received on Wednesday, 22 July 2015 11:38:13 UTC