TLS ALPN Proposal v5

[David M. Lloyd]

Sorry I didn't get the reply from Simone Bordet - it must have gone to 
only one of the two lists (which I'm not on).

On 9/25/2015 9:14 PM, Simone Bordet wrote:
> I don't follow ?
> SNI has APIs in JDK 8, you don't use SSLExplorer at all.

They're highly limited; you can only tell the socket/engine to accept or 
reject a connection based on the SNI information.  The ability to react 
to the server name in order to configure other parameters is highly 
limited, let alone being able to do things like select a different 
SSLContext altogether, or proxy the connection to another host.

> Also, SNI is a client-to-server information only, while with ALPN you
> have to reply to the client, so you have to modify the ServerHello.
> I don't see how you can do this without support from the JDK via APIs ?

Yes, you would have to add a method - *one* method - to 
SSLSocket/SSLEngine to specify the selected protocol; this would be done 
during setup before you initiate handshake (which is why you need to 
explore the Hello packet in the first place).

Better to start simple in any event. With this one single method change, 
we *could* have a 100% effective solution for all use cases.  There 
could be a fancier solution later, when time isn't ticking towards a JDK 
9 deadline.

> Are you saying that every application has to write its own TLS parser ?

Every *server* application, yes, though most users will rely on a 
security or server library to do this already.

Of course we could always add an SSLExplorer-like function to the JSSE 
API - that would be very nice - but the point of this suggestion is to 
keep things realistic and get the job *done*.

> Would not that be overkill and full of potential security issues if
> one does not get the implementation strictly correct ?

Nah, you don't have to do much other than look in the hello packet, make 
a decision, and then hand it off to the SSL context, which would then do 
a much more rigorous validation.  I don't think there's much risk here.

> Also, what if the JDK implementation refuses to use the cipher you
> chose along with the application protocol, for whatever reason ?

Then you'd get an alert, I'd expect.  But my point is that it's not the 
JDK's business to introspect the application protocol!  The JDK should 
only be looking at (TLS) protocol and cipher suite as it does today. 
It's up to the application protocol to determine if there are 
unacceptable cipher suites for that protocol.  Any other approach is 
inherently broken!  What if I add a new application protocol, and some 
cipher suites are unacceptable for it?  Should I just rely on the JDK 
for half the time?  Definitely not - the protocol implementation *must* 
be fully responsible for its own security policy.

On 09/25/2015 09:19 AM, Xuelei Fan wrote:
> 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.

Exactly - you may want or need to choose different SSL contexts, or even 
forward to another host, based on this information.  Relying solely on 
SNIMatcher (for example) is already not adequate by itself for many use 
cases.

Consider also that we're talking about server side code here: the number 
of potential users is small!  I believe that end users will only 
indirectly use this mechanism through server frameworks, meaning that 
only the framework authors are really the direct consumers.

-- 
- DML