Subject: Re: Fwd: Re: TLS ALPN Proposal v3

From: Bradford Wetmore <[email-masked]>
Date: Tue, 21 Jul 2015 17:52:25 -0700

We are working on our ALPN/H2 implementation for JDK 9, and want to 
clarify some assumptions about intended ALPN/H2 interactions/operations.

RFC 7301 (ALPN) suggests that the ALPN value be chosen so that 
certificate selection may take the chosen ALPN value into account:

     1. Introduction
     ...Further, it would be
     advantageous to allow certificate selection based on the negotiated
     application protocol.

and

     4. ...By placing ownership of protocol
        selection on the server, ALPN facilitates scenarios in which
        certificate selection or connection rerouting may be based on the
        negotiated protocol.

If I'm reading the OpenSSL/NSS code right, they both do:

1. Protocol Selection
2. Extension Processing (including ALPN selection)
3. Ciphersuite selection

For SSL/TLS implementations such as OpenSSL/NSS that do iterative 
ciphersuite selection, that means that a blacklisted ciphersuite could 
be chosen for HTTP/2.  This is discussed in RFC 7540:

    Note that clients might advertise support of cipher suites that are
    on the black list in order to allow for connection to servers that do
    not support HTTP/2.  This allows servers to select HTTP/1.1 with a
    cipher suite that is on the HTTP/2 black list.  However, this can
    result in HTTP/2 being negotiated with a black-listed cipher suite if
    the application protocol and cipher suite are independently selected.

So a couple of questions:

1.  Are server sockets expected to support *BOTH* HTTP/2 and HTTP/1.1?

Depending on that answer:

2.  Are you expecting clients/server to try non-blacklisted ciphersuites 
first?  e.g. select H2 for ALPN, prioritize H2-appropriate suites first, 
select a suite and hope for the best?

I suppose we could do some pre-connect probing and disable any H2 suites 
that we know won't have appropriate key material.  If there are no 
H2-appropriate suites left, we can delete H2 from the server's ALPN 
list.  But that ciphersuite selection may fail for other reasons.

3.  If a ALPN of H2 is received along with a blacklisted suite, are 
clients expected to provide their own fallback by opening a second 
connection with H2 not in the ALPN list?

Connection#1:  {"h2", "http/1.1"}
Connection#2:  {"http/1.1"}

Thanks,

Brad

---

From: "Jason T. Greene" <[email-masked]>
Date: Tue, 21 Jul 2015 23:20:13 -0400 (EDT)

> On Jul 21, 2015, at 7:57 PM, Bradford Wetmore <[email-masked]> wrote:
> 
> 
> We are working on our ALPN/H2 implementation for JDK 9, and want to clarify some assumptions about intended ALPN/H2 interactions/operations.
> 
> RFC 7301 (ALPN) suggests that the ALPN value be chosen so that certificate selection may take the chosen ALPN value into account:
> 
>  1. Introduction
>  ...Further, it would be
> For SSL/TLS implementations such as OpenSSL/NSS that do iterative ciphersuite selection, that means that a blacklisted ciphersuite could be chosen for HTTP/2.  This is discussed in RFC 7540:
> 
> 1.  Are server sockets expected to support *BOTH* HTTP/2 and HTTP/1.1 ?

They are not required to, other than the minimal h1 portions required if they support h2c. It is quite common / desirable to support both though on the same port, hence the usage of alpn.

> 2.  Are you expecting clients/server to try non-blacklisted ciphersuites first?  e.g. select H2 for ALPN, prioritize H2-appropriate suites first, select a suite and hope for the best?

If a client wishes to support connecting to a server that may be either h2 or h1, and it wishes to allow blacklisted ciphers for legacy compatibility reasons (another quite common scenario) then the client needs to send alpn support for h2 and a cipher list containing the h2 allowed (and required) ciphers ordered first, and blacklisted ciphers ordered last. This ensures that a client will not have to reestablish a connection, which is important for preventing downgrade attacks. The client should abort the connection if the server selects a blacklisted cipher with h2.

Likewise a server that wishes to support both old and new clients will need to ensure that h2 is only selected when h2 allowed cipher suites are presented by the client. If only blacklisted ciphers are sent in the clienthello, even if the client advertises h2 the server should select h1. Alternatively it can be less tolerant and allow the negotiation of h2 and immediately abort the h2 connection with inadequate_security.

That said, the unfortunate reality is that the TLS library may not have the necessary hooks to negotiate the application protocol and the ciphersuite together, and so the rules are designed to allow h2 implementations that use such TLS libraries to exist and still be considered h2 compliant. While such a combination could lead to a blacklisted cipher being chosen with an h2 connection, the administrator is expected to configure the environment (e.g by tailoring the cipher suite) to disallow such possibilities. 

> 
> I suppose we could do some pre-connect probing and disable any H2 suites that we know won't have appropriate key material.  If there are no H2-appropriate suites left, we can delete H2 
> 
> 3.  If a ALPN of H2 is received along with a blacklisted suite, are clients expected to provide their own fallback by opening a second connection with H2 not in the ALPN list?

No that would open the door to a possible downgrade attack. The server should only select h2 with allowed ciphers if configured properly. If it does not the h2 client should terminate the connection with inadequate security. 

That said it also makes a lot of sense to allow users to override the strict checking in the case of debugging or specialized non-Internet setups.

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 22 Jul 2015 07:51:01 +0200

Uhm, yeah. That is certainly the PoV of the spec. For the current value of "blacklisted".

I am looking forward to see that evolve and how the wg will do a global software update of the internet and enterprises then.

//Stefan

> Am 22.07.2015 um 05:20 schrieb Jason T. Greene <[email-masked]>:
> 
> If only blacklisted ciphers are sent in the clienthello, even if the client advertises h2 the server should select h1.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 22 Jul 2015 06:01:44 +0000

Our implementation takes the more permissive view that clients should only offer cipher suites they're comfortable using, and servers should only select cipher suites they're comfortable using.  That has nothing to do with the application protocol in use -- the lists are the same for h1 and h2.

The server's config should certainly prefer better cipher suites, but if only blacklisted cipher suites are present on a client request, it still works if the server is configured to allow those ciphers.

-----Original Message-----
From: Stefan Eissing [mailto:[email-masked]] 
Sent: Wednesday, July 22, 2015 7:51 AM
To: Jason T. Greene <[email-masked]>
Cc: Bradford Wetmore <[email-masked]>; [email-masked]
Subject: Re: TLS ALPN Proposal v3

//Stefan

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jul 2015 00:54:39 -0700

This is a common set of conclusions to reach.  You certainly aren't
the first to conclude that this is not great.  If you consider all
pieces in isolation, you do get into a bind.

It's true that you can't completely disable all the bad cipher suites
if you ever hope to communicate with a legacy client.  That makes this
harder.

The right way to address this problem is to prioritize allowed cipher
suites over non-allowed cipher suites on both client and server.  You
have to prioritize on both ends because of variations in the way that
different servers implement cipher selection.

> 1.  Are server sockets expected to support *BOTH* HTTP/2 and HTTP/1.1?

Absolutely.

> select a suite and hope for the best?

Are you talking about fallback logic?  That is, one connection attempt
without the blacklisted suites for h2 and then maybe a second with all
the suites you support and NOT h2.

That shouldn't be necessary if you are prioritizing correctly.  There
are alternatives (more below).

> 3.  If a ALPN of H2 is received along with a blacklisted suite, are clients
> expected to provide their own fallback by opening a second connection with
> H2 not in the ALPN list?

I believe that Firefox will not do this.  It's a hard failure.

--

Speaking as an NSS developer, there is an established pattern there
that should work for this.

When processing the named_curve (soon named_group) extension for
elliptic curves, NSS will disable EC cipher suites if it does not find
a commonly supported curve.  This avoids the situation where you
select an EC cipher suite that you cannot use.

At the server, you could disable cipher suites that did not meet the
requirements based on the ALPN selection.  This is relatively
straightforward in NSS, though you have to provide a custom ALPN
callback, rather than relying on the NSS-provided callback.

That isn't of much use to a client, who is largely at the mercy of
servers (a curse that clients cannot avoid, I'm afraid).

---

From: Patrick McManus <[email-masked]>
Date: Wed, 22 Jul 2015 10:30:55 +0200

> > select a suite and hope for the best?
The client, by virtue of making the offer, will sometimes offer a set of
things that cannot be arbitrarily combined. It is on the server, making the
selection, to only select a compliant combination.

So a client could send (indeed probably will send) a client hello for tls
1.2 (which implies 1.2 or 1.0 are acceptable), and alpn offer of h1 and h2,
and both aes-gcm and rsa-rc4. There are totally legal responses that could
include all of those things, but not all combinations are legal responses.

It would be, minimally, impolite of a client to send things in the hello
that cannot be used in any combination - e.g. a 1.0 client hello with a h2
alpn.. I'm not sure if it would technically be a violation of h2 though if
h2 were never negotiated. That starts to get into whether or trees falling
in the forest make a sound..

> clients
right. If the server selects h2 it needs to speak h2. That means not using
the black listed suites among many other requirements of 7540.

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 22 Jul 2015 10:46:53 +0200

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?

Given the focus that h2 gets from major CDNs, I think this is not some esoteric gedankenmodell, but a real world scenario.

//Stefan

> Am 22.07.2015 um 10:30 schrieb Patrick McManus <[email-masked]>:
> 
> On Wed, Jul 22, 2015 at 9:54 AM, Martin Thomson <[email-masked]> wrote:
> 
> The client, by virtue of making the offer, will sometimes offer a set of things that cannot be arbitrarily combined. It is on the server, making the selection, to only select a compliant combination.
> 
> So a client could send (indeed probably will send) a client hello for tls 1.2 (which implies 1.2 or 1.0 are acceptable), and alpn offer of h1 and h2, and both aes-gcm and rsa-rc4. There are totally legal responses that could include all of those things, but not all combinations are legal responses.
> 
> It would be, minimally, impolite of a client to send things in the hello that cannot be used in any combination - e.g. a 1.0 client hello with a h2 alpn.. I'm not sure if it would technically be a violation of h2 though if h2 were never negotiated. That starts to get into whether or trees falling in the forest make a sound..
>  
> 
> right. If the server selects h2 it needs to speak h2. That means not using the black listed suites among many other requirements of 7540.
>  

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

---

From: Patrick McManus <[email-masked]>
Date: Wed, 22 Jul 2015 11:06:21 +0200

On Wed, Jul 22, 2015 at 10:46 AM, Stefan Eissing <
[email-masked]> 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.

> , 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 :)

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 22 Jul 2015 11:59:22 +0200

> Am 22.07.2015 um 11:06 schrieb Patrick McManus <[email-masked]>:
> 
> 
> >On Wed, Jul 22, 2015 at 10:46 AM, Stefan Eissing <[email-masked]> wrote:
> >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

---

From: Patrick McManus <[email-masked]>
Date: Wed, 22 Jul 2015 13:32:19 +0200

On Wed, Jul 22, 2015 at 11:59 AM, Stefan Eissing <
[email-masked]> wrote:

> But I sense a certain implicated feeling of safety in h2 client/server
> security requirements where reality is not that simple.

https provides transport security between the TLS endpoints. That is its
scope. There are many ways the endpoints can fail to provide equal security
beyond that - you mention one, There are a million more - many of which
have nothing to do with and are much harder than transport.

Obviously the weakest link is the point of vulnerability, and h2 has
updated itself to current best practices so that if it is the weakest link
that chain will be fairly strong (for now). That's good. I expect new
protocols to enforce best practices as best they can and I'm realistic that
some people will build fragile chains that include both h2 and plaintext..
the important thing is that h2 is appropriate to use in a strong chain.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 22 Jul 2015 23:37:14 +1200

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

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

Ditto. :-)

Amos

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 22 Jul 2015 13:49:28 +0200

> Am 22.07.2015 um 13:32 schrieb Patrick McManus <[email-masked]>:
> 
> 
> 
> > On Wed, Jul 22, 2015 at 11:59 AM, Stefan Eissing <[email-masked]> wrote:
> > But I sense a certain implicated feeling of safety in h2 client/server security requirements where reality is not that simple.
> 
> https provides transport security between the TLS endpoints. That is its scope. There are many ways the endpoints can fail to provide equal security beyond that - you mention one, There are a million more - many of which have nothing to do with and are much harder than transport.
> 
> Obviously the weakest link is the point of vulnerability, and h2 has updated itself to current best practices so that if it is the weakest link that chain will be fairly strong (for now). That's good. I expect new protocols to enforce best practices as best they can and I'm realistic that some people will build fragile chains that include both h2 and plaintext.. the important thing is that h2 is appropriate to use in a strong chain.

I like the chain link analogy. Have to let it sink in a bit...

//Stefan

<green/>bytes GmbH