TLS ALPN Proposal
simone.bordet at gmail.com
Tue May 26 08:00:09 UTC 2015
On Tue, May 26, 2015 at 2:30 AM, Bradford Wetmore
<bradford.wetmore at oracle.com> wrote:
> Darn those Chicken/Eggs !
> 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
> 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
> 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.
> 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 ?
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