Issues with ALPN implementation in JDK 9

[Greg Wilkins]

On 15 June 2016 at 21:31, David M. Lloyd <david.lloyd at redhat.com> wrote:
>
>
>> I am proposing 3 simple changes to be done:
>>
>> 1) Introduce a TLSProtocolNames class that can convert from TLS
>> protocol bytes to TLS protocol names.
>> 2) Introduce a TLSCipherSuiteNames class that can convert from TLS
>> cipher suite bytes to TLS cipher suite names.
>> 3) Delay handshaker.started=true so that it would simpler and more
>> precise for an application to handle ALPN.
>>
>
> I agree with 1 and 2, at least in concept if not in specifics, but I think
> 3 is a mistake: if you've committed to an SSL context then it's already too
> late to make some possibly important decisions, and SNI can play a factor
> here too.  We can make this easier but I think that trying to do this all
> inside of the handshake process is going to cut off some important use
> cases.
>
>>
>>
Note that with 3 :

   - Not all decisions have to be made late.  Some logic will need to be
   executed before unwrapping hello, such as trimming the set of available
   ciphers to mutually acceptable ones.
   - You are still free to pick a protocol early - ie before hello unwrap
   if you can/want

The process we are working towards in jetty is three phase: firstly we trim
ciphers and protocol list; then we allow SslEngine to pick the specific
cipher (using certificates and/or SNI); finally we want to pick the
protocol based on the cipher AND the earlier work trimming
ciphers/protocols.

So definitely don't want to "do this all inside of the handshake process".
Just want to ability to make the final protocol choice after the final
cipher decision has been made in the hello unwrap.    Again, this would be
optional and you could do it all before if you don't want to support the
edge cases where this is needed.

cheers



-- 
Greg Wilkins <gregw at webtide.com> CTO http://webtide.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160616/e17b2486/attachment.htm>