JDK-8254631 : Better support ALPN byte wire values in SunJSSE
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-10-12
  • Updated: 2021-08-10
  • Resolved: 2020-12-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 15 JDK 16 JDK 8 Other
11.0.12-oracleFixed 13.0.9Fixed 15.0.5Fixed 16 b27Fixed 8u301Fixed openjdk8u302Fixed
Related Reports
CSR :  
JDK-8256817 - Better support ALPN byte wire values in SunJSSE
Relates :  
JDK-8267860 - Off-by-one bug when searching arrays in AlpnGreaseTest
Sub Tasks
JDK-8257548 :  
Release Note: Improve Encoding of TLS Application-Layer Protocol Negotiation (ALPN) Values - Resolved
JDK-8265351 :  
Release Note: Improve Encoding of TLS Application-Layer Protocol Negotiation (ALPN) Values - Resolved
JDK-8267255 :  
Update Oracle ALPN guide for JDK 8u - Resolved
Description
As pointed out here:

https://mail.openjdk.java.net/pipermail/security-dev/2020-October/022750.html

SunJSSE does not handle String conversion to byte[] well, and thus can't represent some of the GREASE values (RFC 8701: https://tools.ietf.org/rfcmarkup?doc=8701 )

For our implementation currently:

1.  Client can't send valid GREASE values.  We'll send a UTF-8 representation which won't be recognized by peers as GREASE.

2.  Server shouldn't crash, but will not report to our API consumers that GREASE values were received. 

[Update 11/24/2020-after further experimentation/bug fixing]

JSSE Client will send >0x7F bytes encoded as 2-4 UTF-8 bytes, which will only be recognized by JSSE peers.  Other impls may not know how to decode.

For JSSE Server, there are two cases:

1.  it can receive >0x7F either as 2-4 UTF-8 bytes (correct value returned in String to app), or
2.  as an incorrectly formatted UTF-8.  In that case, default "?" value returned to app.

For the first case, *IF* the server selects a ALPN value that contains a character with a >0x7F value, the app will crash when trying to create the ALPN extension reply.

Evaluate possible approaches.
Comments
Fix request (13u) Applies cleanly, but the javadoc parts are removed as documented in CSR JDK-8271938 sun/security/ssl/ALPN test passed PR is reviewed
10-08-2021
Fix request (15u) Applies cleanly, but the javadoc parts are removed as documented in CSR JDK-8271938 sun/security/ssl/ALPN test passed PR is reviewed
10-08-2021
Fix request (8u) I'd like to request an approval to have this bug in 8u. This backport would be beneficial to fix a bug affecting the release and also to improve parity between JDKs. The patch does not apply cleanly but was review-approved here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-May/013924.html
27-05-2021
8u RFR: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013698.html
22-04-2021
Fix Request (11u) Should get backported for parity with 11.0.12-oracle. Applies cleanly, but the javadoc parts need to get removed as documented in CSR JDK-8264177. Review thread: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-March/005513.html
31-03-2021
Thank you for the hint. I should have read the CSR first. Dropping the javadoc comments is my favorite choice :-)
30-03-2021
FYI [~mdoerr] CSR for the Oracle JDK backports: JDK-8264177 (chose to drop javadoc comments in favour of release notes)
29-03-2021
11u backport note: Should get backported for parity with 11.0.12-oracle. Applies cleanly, but needs modification: * // MEETEI MAYEK LETTERS "HUK UN I" (Unicode 0xabcd->0xabcf) ^ src/java.base/share/classes/javax/net/ssl/SSLParameters.java:657: error: bad use of '>'
29-03-2021
Changeset: fe5cccc1 Author: Bradford Wetmore <wetmore@openjdk.org> Date: 2020-12-02 04:14:28 +0000 URL: https://git.openjdk.java.net/jdk/commit/fe5cccc1
02-12-2020
See CSR JDK-8256817 for additional information.
26-11-2020
The proposal works for the original reporters. The email discusses the approach, but doesn't mention any doc/spec updates. If this change is made, we will need to update the docs and spec to formalize this behavior so that API users can have a consistent experience. A few more details on the underlying issue: There is an issue in our implementation when it comes to String<->byte[] conversion. The Java ALPN APIs used Strings for ease-of-use, but then hardcoded an internal String<->byte[] translation using UTF-8, which means the GREASE bytes 0x00-0x7F work fine. But... For outgoing messages, the bytes 0x80-0x8FF aren't represented correctly as they are converted to 2 byte values in UTF-8. (i.e. "0x8F 0x8F" becomes "0xc2 0x8a 0xc2 0x8a"). For incoming messages, values like "0x8F 0x8f" get mapped to "??" because the UTF-8 translation is bad. At the time the ALPN work was done, only ASCII values were in the IANA TLS ALPN database, so it wasn't noticed. We've proposed a workaround using ISO_5589_1 which isn't perfect (potential compatibility issue with older releases), but would allow for properly sending/receiving GREASE values. As currently implemented, we should be able to accept all GREASE values (i.e. no crashes), but the values won't be reported to the consumer correctly.
10-11-2020
Proposal made at: https://mail.openjdk.java.net/pipermail/security-dev/2020-November/023098.html When/if time permits, will propose this plus back ports to the current Oracle releases, and will encourage the OpenJDK maintainers to also do OpenJDK8/OpenJDK11 so that the String<->byte[] behavior is consistent.
10-11-2020