[8u] RFR 8202343: Disable TLS 1.0 and 1.1

Martin Balao mbalao at redhat.com
Fri Jan 22 19:20:30 UTC 2021


On 1/22/21 12:40 PM, Martin Balao wrote:
> Even when JDK-8234728 applies cleanly, it fails to pass and it's far
> from a trivial backport. In fact, my current investigation is suggesting
> that JDK-8234728 is failing to properly execute
> HandshakeHashCloneExhaustion with TLS 1.3; and is making it to
> trivially-pass. TLS 1.3 uses the HKDF class to derive keys, which gets a
> MessageDigest instance. However, because of JDK-8157579, there is a
> fallback scheme for non-clonable MessageDigest implementations. As a
> result, the MessageDigest instance used is not DigestBase$<SMTH> (from
> the test BaseDigest.java file) but one from the SUN provider. Looks to
> me that this is different than in TLS 1.2 or below, where the
> TlsPrfGenerator class is used to derive keys and we have no
> fallback-scheme for non-clonable MessageDigests. I've still not verified
> this last statement, though. Verifying this last statement would confirm
> HandshakeHashCloneExhaustion author's intention of using
> DigestBase$<SMTH> instead of any other MessageDigest implementation.
> Note: 8u does not have the JDK-8157579 fallback-scheme and is exposing
> the bug.

I've further investigated these initial findings/assumptions and have a
more conclusive idea of the problem.

JDK-8234728 [1] is intended to make some tests work with TLS 1.3. There
is HandshakeHashCloneExhaustion among them.

In TLS 1.3, a HKDF instance is created for key derivation. This instance
has a HMAC object inside, which is an instance of the HmacCore class.
When a HmacCore instance is constructed, a MessageDigest instance is
obtained [2]. The instance obtained is a non-clonable one, from the
test's BaseDigest class [3]. However, there is a fallback scheme for
non-clonable MessageDigest instances introduced by JDK-8157579 [4] that
changes the previous instance to one from the SUN security provider
(i.e.: sun.security.provider.SHA2$SHA256 class). For the handshake hash,
the right test's DigestBase class is used (the fallback scheme is only
in HmacCore class).

In TLS 1.2, key derivation is done with the TlsPrfGenerator class. The
MessageDigest instance used for key derivation is from the test's
BaseDigest class [5].

The previous two findings made me think there could be a problem.

Further looking at what HandshakeHashCloneExhaustion is testing, the use
of a clonable MessageDigest instance for HKDF key derivation (instead of
the test's BaseDigest one) does not make the test to trivially-pass:
there are still several uses of the non-clonable instance which require
the code to properly handle it. I've verified with the debugger how
during the recording of the HandshakeHash,
CertificateVerify::T13CertificateVerifyMessage requires an instance of a
MessageDigest and the same one being used for the handshake is returned
(that is: DigestBase$SHA256). So if the HandshakeHash does not handle
this well, the MessageDigest state would be corrupted by the
CertificateVerify use -at least-.

In 8u (contrary to newer releases which have JDK-8157579) TLS 1.3 HKDF
will use the same test DigestBase$SHA256 instance. To backport
JDK-8234728 to 8u, we need to implement the engineGetMacLength API
through proper delegation (so we don't get a default length of 0 and
fail later while deriving keys).

In conclusion, there is nothing to fix in jdk/jdk -implementing
engineGetMacLength there would be dead code, technically- but we would
need to make adjustments when backporting 8234728 to 8u.


[1] - https://bugs.openjdk.java.net/browse/JDK-8234728
[2] -
[3] -
[4] -
[5] -

More information about the jdk8u-dev mailing list