Re: TLS ALPN Proposal v3

> On Jul 21, 2015, at 7:57 PM, Bradford Wetmore <bradford.wetmore@oracle.com> 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
>  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 ?

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.

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

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.


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

Received on Wednesday, 22 July 2015 03:20:41 UTC