TLS extensions API, ALPN and HTTP 2.0

[Simone Bordet]

Hi,

On Wed, Sep 17, 2014 at 4:11 PM, Michael McMahon
<michael.x.mcmahon at oracle.com> wrote:
> Okay, I see the point you are making. It's more a question of whether
> the constraints themselves are appropriate.

And convince the HTTP/2 editors :(

> I've another question. In the work you've done so far, did you allow
> for the possibility of separate certificates to be selected per ALPN
> instance?
>
> I'm guessing that if multiple applications are to be supported
> over one TCP port (client or server) then different certificates might be
> needed for each application. Or is that not a reasonable assumption?

If I understand you correctly, you are saying that you want a
connection with SNI=foo.domain.com to *not* trigger ALPN, but a
connection with SNI=bar.domain.com to trigger ALPN ?

We don't support this right now in Jetty, but the current ALPN API
probably does: at the moment of selecting the protocol, the
application can retrieve the SNI and decide what protocol to select.
See for example:
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-alpn/jetty-alpn-server/src/main/java/org/eclipse/jetty/alpn/server/ALPNServerConnection.java#n49
There you can call getSSLEngine(), which will be able to return a
number of information about the handshake (such as the cipher chosen).

Makes sense ?

-- 
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