Hi, On Thu, Jun 2, 2016 at 8:20 PM, Bradford Wetmore <bradford.wetm...@oracle.com> wrote: > 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.
Oh, no ! On net-dev we are still talking about changing the APIs for HttpClient and WebSocket client, so can I please ask that this does not get delayed another 5 years ? We explicitly asked on net-dev if there was a freeze, and they replied that it was still possible to change the APIs, so I presume it would be possible to add a simple class to javax.net.ssl ? It's a super simple class to expose, call it CipherNames, whose implementation will be trivial and based on sun.security.ssl.CipherSuite. Right now I am doing the same accessing CipherSuite via reflection on its private members. I don't know if I am late to the party or way too early, but I cannot believe that all others that are interested in ALPN in Java 9 went for a workaround instead of asking here whether the cipher names could have been exposed in a standard way. Considering the historical issue you mention it is important that there are no ambiguities in the cipher names, and having the JDK as the only source is really important. Can I ask you to reconsider this small change for JDK 9 ? -- 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
