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

[Bradford Wetmore]

Hi Simone,

I agree with you, it would be handy.  As part of the HTTPS 2.0 
prohibited suites for ALPN, I wanted to do just such a convenience 
mapping in javax.net.ssl.StandardConstants.java:

 
http://cr.openjdk.java.net/~wetmore/8051498/webrev.16/src/java.base/share/classes/javax/net/ssl/StandardConstants.java.frames.html

     public static final Map<Integer, String> cipherSuiteIntToString

but was shot down and finally gave up.  We'd need to consider more how 
to expose some of the TLS internals that we don't currently do right 
now.  (e.g. at the API layer or as a provider (SPI) call.)

One of the problems you may not have noticed is also historical, in that 
JSSE was first released around the time of the finalization of TLSv1, so 
there is a mix of SSL_/TLS_ prefix for the older algorithms.  The TLS 
standard name String "TLS_RSA_WITH_3DES_EDE_CBC_SHA" is actually the 
SSLv3/Java Standard Name "SSL_RSA_WITH_3DES_EDE_CBC_SHA", which was set 
during the original SSLv3 spec, which later became the "Historic" RFC 6101.

FYI, in JDK 9, you will lose the ability to call valueOf() due to 
modular encapsulation.

We can file a RFE to do this.  Since JDK 9 just went FC last week, it 
will likely need to be a JDK 10 RFE.

My workaround/suggestion for now is to implement your own:

1.  Grab the section 
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

2.  Compare with StandardConstants.java above to get the SSL_/TLS_ 
standard names.  The names in StandardConstants.java was complete 
through the end of 2015.

I hope to add this when I rework the SSLExplorer sample code for the JDK 
9 docs.

Cheers,

Brad



On 6/2/2016 7:34 AM, Simone Bordet wrote:
> 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 !
>