TLS extensions API, ALPN and HTTP 2.0

[Michael McMahon]

On 17/09/14 16:25, Simone Bordet wrote:
> 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?

No, I was thinking something like the following:

foo.domain.com:443 supports two different server applications - "h2"
and something else (say some proprietary application "fooapp").
They require two different certificates and we want
TLS to choose the right cert for the right application.

Or it could be a client trying to connect to either of the two applications
above on port 443, and where the client wishes to use two different
client certs.

It is analogous to SNI because the choice of the cert has to occur
during the TLS handshake, which is why it needs to be built into TLS.
But, I assume that SNI is able to choose a cert based on the domain
name and doesn't need any additional help from the API.

- Michael


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