Issues with ALPN implementation in JDK 9

Simone Bordet simone.bordet at gmail.com
Wed Jun 15 08:35:19 UTC 2016


Hi,

On Wed, Jun 15, 2016 at 10:15 AM, Andrew Haley <aph at redhat.com> wrote:
> The problem I have with reading posts about JDK9 problems is that I
> can't tell the *severity* of the problems.  I don't know if something
> is a total blocker or an inconvenience.  When someone uses an internal
> sun.* class they may be doing something which must be done in order to
> get access which would be impossible otherwise.

I don't understand this comment.

The main issue of this thread is the current impossibility to have a
clean and precise ALPN implementation with minimal code.
Sure we can fallback to less optimal solutions that won't work in all cases.
Sure we can duplicate the JDK logic and keep it up-to-date, invoke SNI
twice, etc.
But I don't see the point of settling for a less than optimal solution
when there is room to make it better, and the effort is minimal.

Is this issue a blocker ? Surely not, it is possible to rewrite from
scratch a JSSE provider.
Would I do that ? No, thanks.

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 think these changes will benefit all the people involved in network
servers having to play with ALPN.

We *are* still in time, according to Mark Reinhold.
The changes are simple.

We have not heard from Oracle yet, but I can prepare a webrev if that helps.

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz


More information about the security-dev mailing list