TLS ALPN Proposal v5

David M. Lloyd david.lloyd at
Fri Sep 25 14:48:28 UTC 2015

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 for delegation. If SNI
> get requested, the delegation server may redirect the
> connection to (provide the service for
> If SNI get requested, the delegation server may redirect
> the connection to (provide the service for
> Similarly, ALPN need to support the case as above.
> Another example, there is a server If SNI
> get requested, the server would act as the service for
> If SNI get requested, the server would act as the
> service for
> 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 

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.


More information about the security-dev mailing list