RFR: 8254631: Better support ALPN byte wire values in SunJSSE

[Bradford Wetmore]

On Thu, 26 Nov 2020 20:26:36 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Certain TLS ALPN values can't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 Character Set which converts characters larger than U+00007F into multi-byte arrays that may not be expected by a peer.
>> 
>> Full details are available in:
>> 
>> - Bug:  https://bugs.openjdk.java.net/browse/JDK-8254631
>> - CSR:  https://bugs.openjdk.java.net/browse/JDK-8256817
>
> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 341:
> 
>> 339:  * The ApplicationProtocol {@code String} values returned by the methods in
>> 340:  * this class are in the network byte representation sent by the peer and
>> 341:  * may need to be converted to its Unicode format before use.  For example,
> 
> I think there are two possible directions to use the bytes, concerting application ALPN representation to network byte representation, or concerting network bytes to application representation.  The 1st sentence, I may focus on the the network byte representation description.
> 
> "The ApplicationProtocol {@code String} values returned by the methods in this class are in the network byte representation sent by the peer.  If an ALPN value is not encoded in network byte ..., an conversion may be required.  For example, ..."

Discussed with Xuelei, the concern was it wasn't clear that you could compare using byte[] or Strings, and possible byte encodings that might be received.  I believe these have been addressed in the current version.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1440