TLS ALPN Proposal

Michael McMahon michael.x.mcmahon at
Mon May 25 13:57:42 UTC 2015

On 25/05/15 12:34, Simone Bordet wrote:
> Hi,
> On Mon, May 25, 2015 at 12:08 PM, Michael McMahon
> <michael.x.mcmahon at> wrote:
>> Hi Brad,
>> A couple of initial comments/questions.
>> 1) Certificate selection is one feature envisaged by ALPN. ie a client or a
>> server
>>      ought to be able to choose a different certificate depending on the
>> application name
>>      that gets negotiated. Is that possible with this API?
> Interesting.
> I can definitely see choosing the ALPN protocol based on the SNI name
> sent by the client.
> For example, a server able to speak http/1.1 and h2 receiving a
> request for wants to force http/1.1.
> This would be possible, IIUC, using
> sslEngine.getHandshakeSession().getRequestedServerNames() in the
> ApplicationProtocolSelector implementation.

Perhaps, though it seems there are specific ALPNs for HTTP/1.1 ("http/1.1")
and for HTTP/2 ("h2"). So, I think you would use ALPN itself to do that 
An incoming TLS connection without the ALPN extension is just assumed to 
be HTTP/1.1

> I see less common choosing the certificate given the application
> protocol, but I understand it's mentioned in RFC 7301.

There aren't very many different "applications" envisaged yet. There are
a couple of NAT related protocols registered. But, actually having 
thought about it
again, client certificate selection happens in the 
X509ExtendedKeyManager class
and that implementation could presumably call 
and select the client cert using that information. It doesn't do that 
now obviously
but I think it could in future if necessary.

> ALPN definitely needs the cipher to be negotiated to support HTTP/2,
> so I hope it's not a chicken-egg problem.

I've been assuming that (by default) we just need to avoid using the 
ciphers and make sure to propose at least the one mandatory cipher; then 
we shouldn't
have any problem. HTTP/2 apps can still create their own SSLContexts and 
them any way they want.

- Michael.

More information about the security-dev mailing list