JDK-8228757 : Fail fast if the handshake type is unknown
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 11,12,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-07-29
  • Updated: 2021-05-18
  • Resolved: 2019-08-19
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 14 JDK 8 Other
11.0.8-oracleFixed 13.0.4Fixed 14 b11Fixed 8u261Fixed openjdk8u302Fixed
Description
In the SSLSocketInputRecord.decodeInputRecord() implementation:
    // skip the first byte: handshake type
    byte handshakeType = handshakeFrag.get();

The handshake type was not checked until the handshake message get fully parsed.  It's nice to check that the handshake type is known here and fail fast.

Similar to SSLEngineInputRecord.decodeInputRecord() and DTLSInputRecord.parseHandshakeMessage().

Comments
Fix request (8u) I'd like to request a backport of this enhancement to 8u so we have parity between JDKs. The patch does not apply cleanly but has been review-approved here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013709.html No regressions found in jdk/sun/security/ssl tests category.
23-04-2021

8u RFR: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013706.html
23-04-2021

Fix request (13u) Requesting backport to 13u for parity with 11u, applies cleanly.
26-05-2020

Fix request (11u) I would like to downport this for parity with 11.0.8-oracle. Applies clean.
28-02-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/7cc5a5b4eee9 User: xuelei Date: 2019-08-19 19:57:11 +0000
19-08-2019