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.wetm...@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 !
