TLS ALPN Proposal v5

[Xuelei Fan]

CC security-dev.

On 9/25/2015 9:14 PM, Simone Bordet wrote:
> Hi,
> 
> 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.
> 
> 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 ?
> 
>> I imagine the client code simply specifying a list of protocols along with
>> today's list of cipher suites.
>>
>> The user-space server side logic would go like this:
>>
>> * Receive SSL ServerHello
>> * Examine the packet for ALPN and SNI information
>> * Read the list of cipher suites
>> * Evaluate
>> * Select an SSLContext based on protocol and/or server name
>> * Construct an SSLSocket or SSLEngine as appropriate
>> * Set a property on the SSLSocket/SSLEngine to indicate ALPN protocol name
>> * (optional) Change/sort the cipher suite list on the SSLSocket/SSLEngine as
>> appropriate
>> * Resume negotation by passing the ServerHello in to the SSLSocket/SSLEngine
>> as initial data
>>
>> It's not super elegant but it should work just as well as SNI works, and it
>> would cover 100% of use cases since the user has complete flexibility to
>> make a decision based on any combination of cipher suite selection, protocol
>> name, and host name, even potentially with the option to pretend that ALPN
>> wasn't recognized.
> 
> Are you saying that every application has to write its own TLS parser ?
> Would not that be overkill and full of potential security issues if
> one does not get the implementation strictly correct ?
> 
> Also, what if the JDK implementation refuses to use the cipher you
> chose along with the application protocol, for whatever reason ?
> 
> Thanks !
>