TLS ALPN Proposal v5

[Xuelei Fan]

On 9/25/2015 9:14 PM, Simone Bordet wrote:
> On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> > Well, SNI already basically works this way, so it's not so great a stretch.
> I don't follow ?
> SNI has APIs in JDK 8, you don't use SSLExplorer at all.

There are two typical cases for SNI and ALPN. One is that the same
server is used for difference SNI/ALPN. Another one is that different
server is used for different SNI/ALPN.

For example, there is a TLS server 101.101.1.1 for delegation. If SNI
www.example.com get requested, the delegation server may redirect the
connection to 192.168.1.100 (provide the service for www.example.com).
If SNI www.another.com get requested, the delegation server may redirect
the connection to 192.168.1.101 (provide the service for www.another.com).

Similarly, ALPN need to support the case as above.

Another example, there is a server 101.101.1.1. If SNI www.example.com
get requested, the server would act as the service for www.example.com.
If SNI www.another.com get requested, the server would act as the
service for www.another.com.

Similarly, ALPN also need to support the case as above.

Actually, it was a puzzle to me: whether a concrete server can support
both HTTP/2 and HTTP/1.1, or not. If HTTP/2 mode of the server does not
work, is it OK to fall-over to use HTTP/1.1 mode? I did not get the
answer from the HTTP/2 spec. The current design is based on the idea
that a concrete server may support both HTTP/2 and HTTP/1.1 at the same
time, and fall-over mode is necessary. Otherwise, the API and
implementation can be simplified a lot.

Xuelei