Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

[Simone Bordet]

Hi,

On Wed, Dec 2, 2015 at 1:04 AM, Bradford Wetmore
<bradford.wetmore at oracle.com> wrote:
> Filling in a few more details [for server parsing]
>
> SSLContext.getInstance("protocol"); // returns a context with
>                                     // "protocol" and possibly
>                                     // other protocols enabled.
> SSLEngine ssle = SSLContext.createSSLEngine(...);
>
> Read ClientHello from Socket/SocketChannel/AsynchronousSocketChannel/etc.
>
> Parse ClientHello for requested protocol/alpn/ciphersuites
>
> choose protocol/alpn/ciphersuite value(s)

I'm trying to give this a go in Jetty and I stumbled into this
problem: when Jetty parses the ClientHello, it parses the ciphers in
the TLS format of 2 bytes.

For example, the ClientHello contains the cipher (0x00, 0x00).
I would need a way to convert the 2-bytes duple into the corresponding
cipher string.
For this example, it would be: "TLS_NULL_WITH_NULL_NULL".

Turns out that the JDK can do this via:

CipherSuite cipher = sun.security.ssl.CipherSuite.valueOf(byte1, byte2);
String name = cipher.name;

Unfortunately, class CipherSuite is package local, and in sun.* package.

Would be great if there was a standard way of going from the duple to
the string.

Having the cipher string would allow applications to compare what
parsed with application configurations strings, and it would match
with methods such as SSLEngine.getEnabledCipherSuites(), etc. which
handle String[].

Having the JDK to provide this facility would guarantee that the
naming is always consistent, and that it is always up-to-date with the
JDK in use.

Looking forward to your comments.

Thanks !

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