TLS ALPN Proposal
michael.x.mcmahon at oracle.com
Mon May 25 13:57:42 UTC 2015
On 25/05/15 12:34, Simone Bordet wrote:
> 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
>> ought to be able to choose a different certificate depending on the
>> application name
>> that gets negotiated. Is that possible with this API?
> 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
An incoming TLS connection without the ALPN extension is just assumed to
> 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
and that implementation could presumably call
and select the client cert using that information. It doesn't do that
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
have any problem. HTTP/2 apps can still create their own SSLContexts and
them any way they want.
More information about the security-dev