TLS ALPN Proposal

Simone Bordet simone.bordet at
Tue May 26 08:00:09 UTC 2015


On Tue, May 26, 2015 at 2:30 AM, Bradford Wetmore
<bradford.wetmore at> wrote:
> Darn those Chicken/Eggs [1]!
> Yes, you are correct.  The steps for the current server code:
> 1.  The ClientHello is parsed, and the SNI matcher callback is called. It
> does not return which value was matched in the ServerHello, just whether a
> SNI name was matched or not:
>     The "extension_data" field of this extension SHALL be
>     empty.
> 2.  Begin generating the ServerHello, choose the Protocol Version.
> 3.  Iterate through the list of client's ciphersuites and call the Server's
> KeyManager (KM) callback until the KM returns key material we can use.  A
> return string selects the proposed ciphersuite.
> So we currently don't know the selected ciphersuite until the KM has been
> called (possibly multiple times).
> If we choose the ALPN before the ciphersuite, the ciphersuite selection may
> end up being inappropriate (HTTP/2 blacklist).  If we choose the ciphersuite
> first, then the ALPN value wasn't used to drive the certificate selection.
> Two suggestions in preferred order below.
> In each of these cases, unfortunately there is currently no indication of
> the proposed Ciphersuite, so we need to modify the behavior of
> getHandshakeSession().getCipherSuite() to fill in the proposed CipherSuite
> before the call to the KM.  This seems ok with the current wording, but we'd
> need to make that explicit.  This value will change for each ciphersuite/KM
> choice attempt.
> Each suggestion below is followed by our previously proposed ALPN callback
> to make the actual ALPN value selection:
> 1a.  Add a parallel method to ExtendedSSLSession:
>     public List<String> getRequestedApplicationProtocolNames();
> along with the previously proposed selected name:
>     public String getApplicationProtocol()
> (I'll be changing these names.  I'm open to suggestions).
> When the KM is called, the TLS protocol (e.g. TLSv1.2) has already been
> selected.
> Both of the major selection parameters (protocol/proposed ciphersuite) are
> now available, and applications have access to the ordered ALPN list to see
> what the client's requested values were.
> -or-
> 1b.  Keep API as is, and make two callbacks.  This first is an advisory
> value, the TLS protocol version and proposed ciphersuite will be available
> in getHandshakeSession().  The second callback sets the final value that
> will be sent.
> I think 1.a is my preference.

I am not sure I follow this. Can you please sketch the steps/algorithm
that will be done in your proposed solution ?

Simone Bordet
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

More information about the security-dev mailing list