Hi,
On Mon, May 25, 2015 at 3:57 PM, Michael McMahon
<michael.x.mcma...@oracle.com> wrote:
> 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
Sure, but I can see a client looping over a list of domain names (e.g.
to check whether the sites support HTTP/2) and therefore not having
any knowledge of whether it should or not add the ALPN extension.
This client will always add it, but the server must force http/1.1 for
http1.domain.com.
> 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.
Sure, unless the protocol is not available because ALPN code has not run yet.
For what I understand, currently cipher selection and certificate
selection happen at the same time, please correct me if I am wrong.
If that's the case, then we have a chicken-egg problem: you can't call
ALPN code before the cipher is selected, but you need ALPN to select
the certificate.
If those two steps can be split, then ALPN code could be put in
between and all is solved.
--
Simone Bordet
http://bordet.blogspot.com
---
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
