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

[Simone Bordet]

Hi,

On Thu, Jun 2, 2016 at 8:20 PM, Bradford Wetmore
<bradford.wetmore at 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