TLS ALPN Proposal

[Michael McMahon]

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 oracle.com> 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 http1.domain.com 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 
negotiation.
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 
sslEngine.getHandshakeSession().getApplicationProtocol()
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 
black-listed
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 
configure
them any way they want.

- Michael.