On 25/05/15 12:34, Simone Bordet wrote:
Hi,
On Mon, May 25, 2015 at 12:08 PM, Michael McMahon
<michael.x.mcma...@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.
