TLS ALPN Proposal v5

[David M. Lloyd]

On 09/25/2015 12:13 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> A: receive raw SSL packet on Socket or SocketChannel
>> A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info
>
> This requires the application to write a TLS parser. This is currently
> not necessary, nor provided.

It is already necessary to make many non-trivial SNI decisions.  I don't 
see ALPN as deserving higher treatment than SNI.

> You think this could be provided via a JDK utility class ?
> And if so, how can it be extended in the future when more TLS
> Extensions are defined ?

I don't think it's necessary, no.

>
>> A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher suite info
>
> The application must intersect the ciphers, application protocols...
> perhaps again this can be done by some JDK utility class.

The point of the approach is that it is unlikely that any JDK-driven 
logic will be adequate for all use cases.  It's better to let the 
application be a black box: ALPN+SNI+Ciphers -> app logic -> one ALPN 
protocol, one SNI name, only valid ciphers.

>> A: either proxy the connection, or obtain or create the relevant SSLContext
>> from the desired provider
>> A: construct server-side SSLSocket/SSLEngine from SSLContext
>> A: setApplicationProtocol(H2)
>> A: setEnabledCipherSuites(only allowed suites in desired order)
>> A: start handshake
>> J: receive ClientHello (buffered from A)
>> J: verify SNI is matched, fail otherwise (as today)
>> J: verify ALPN is matched, fail otherwise (new)
>
> There is a missing step here which is to verify the cipher
> (trySetCipherSuite() logic).

The application protocol implementation chooses only valid cipher suites 
for the protocol.  Why would it choose one that is not valid, 
considering that the protocol implementation itself is the only thing 
that "knows" what is valid or not?

> If that fails then we must try another application protocol.
> We cannot just fail the connection.
> How do we go from here to the top again to choose another protocol ?
>
>> J: send ServerHello (with the single, user-selected protocol)
>> ...
>>
>> This is very simple from the JDK perspective, and also much more flexible.
>
> Well, I kinda like it, but I have strong reservations that it cannot
> really "negotiate" the application protocol, meaning that if one
> application protocol fails, try the next, and then the next and so
> forth until one succeeds (or they all fail).

This validation should have happened before the JDK ever has a chance to 
be involved.
-- 
- DML