Issues with ALPN implementation in JDK 9

[Simone Bordet]

Hi,

On Wed, Jun 15, 2016 at 10:03 AM, Andrew Haley <aph at redhat.com> wrote:
> On 14/06/16 14:57, Simone Bordet wrote:
>> * Lack of facilities to convert TLS protocol bytes to protocol strings.
>> This class already exist in JDK, sun.security.ssl.ProtocolVersion, it
>> would just need to be exposed in javax.net.ssl.
>>
>> * Lack of facilities to convert TLS cipher bytes to cipher name strings.
>> As above, sun.security.ssl.CipherSuite exists, needs to be exposed publicly.
>>
>> Note that for the 2 bullets above, a recent message from Mark Reinhold
>> to jdk9-dev confirmed that JDK 9 is *not yet* feature complete, so I
>> hope they can be considered for inclusion.
>
> It's very late,

It's not too late, like Mark Reinhold said.

> and they certainly won't be considered unless
> someone proposes it.

I just did.

>  But can't we simply clone this class anyway?

Sure, but then every ALPN implementer out there will have their own,
they will need to be kept up to date when a new TLS protocol or a new
cipher is introduced in the JDK, etc. etc.
The TLS ciphers in the JDK have non-standard names for historical reasons, etc.

The classes are trivial, and can be tiny wrappers around the existing
ones like TLSProtocolNames and CipherSuiteNames.

> Incidentally, I can't tell which (if any) of the issues you describe
> are specific to JDK 9 (i.e. they would not be problems in JDK 8.)

Not sure what you mean here.
Unless you parse the TLS protocol in JDK 8, there is no particular
need for those classes.
With JDK9 we now need to parse the TLS protocol to handle ALPN, so
those classes would be handy.

-- 
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