Defer disabling TLS 1.0/1.1 by default?

Fri Apr 2 21:15:58 UTC 2021

I'm a mere Java user and developer, I'm not a JDK person. I'm also
only on jdk-updates-dev, so if this message ended up in mod-queues,
apologies! I'm replying as a TLS person. I work at AWS too, leading
our TLS work, and we took a look at this as part of the upcoming
changes for Amazon Corretto.

The short version is this:  we think about 1% of applications and
traffic "out there" are still using TLS1.0/TLS1.1. Given where
browsers are at, I think this percentage is an under-estimate of the
usage on Java applications - I suspect it's even higher there. When we
dig in with customers "Why are you still using TLS1.0 or TLS1.1" the
most common reasons are legacy appliances and applications. Think of
hardware load balancers that were never updated, or can't be, to
support TLS1.2 or better. Compliance mandated traffic inspection
devices that force TLS1.0 in certain industries are another reason.
For these applications, the change will break them, and they'll get a
low-level exception. The users can re-enable TLS1.0 and TLS1.1, but
they may suffer an outage because they likely weren't expecting a
breaking change low in the networking stack.

Retiring TLS1.0 and TLS1.1 is worthy, but I'd suggest that doing it in
one pass is premature right now. The browsers are each at different
degrees of support, some have "nuisance" warnings, some have no
warnings at all. They've all punted a few times on when TLS1.0 and
TLS1.1 may be hard disabled, but so far it's available in some form in
all of them. I don't know of any other programming language (e.g. Go,
Python, etc) that's doing something similar either.

I tend to be an absolute paranoid zealot about security, but I don't
lose sleep terribly over the issues that are in TLS1.0 and TLS1.1. I
do want to retire the protocols ... but ideally without breaking
anyone. If there's a way instead to do multiple passes and ship a JDK
that measures TLS1.0 and TLS1.1 usage - as the browsers do - I'd love
that. Then I could work with users to identify workloads where they
are relying on TLS1.0 as a last resort and be proactive about the
change. This doesn't have to be spyware phone-home measurements, even
a local counter would be valuable. When we make these kinds of changes
to AWS services, we go through a similar process: we see who is still
using the old protocols and reach out to customers to work with them
to update and ensure they won't be impacted. OpenJDK isn't a managed
service, but we could help consumers help themselves at least.

Since it will likely come up - here's a summary of the known security
issues that are in TLS1.0 and TLS1.1:

1. The BEAST attack, which is in TLS1.0 only.  The BEAST attack is a
sophisticated attack that utilizes both active traffic interception
and manipulation of retries and responses to Browsers (the “B” in
BEAST stands for “Browser”). In general, it’s not the kind of attack
that Java applications are vulnerable to.Even so, OpenJDK actually
includes mitigations for the BEAST attack, but the "other" side of a
TLS connection may not.

2. The SHA1/MD5 Transcript hash. To ensure that a sender or receiver
isn’t being tricked by any kind of attacker in the middle, TLS uses a
secure record of all the data sent and received called a transcript
hash. In TLSv1.0 and TLSv1.1 this hash uses either a novel combination
of the MD5 and SHA1 algorithms, or the SHA1 algorithm alone. Both MD5
and SHA1 are considered broken.

In Cryptography we like to have extremely generous security margins,
and the bar for what is considered “broken” and what is actually
practical are often very different. In this case, researchers estimate
that it takes about 150 trillion trillion (that’s 150 trillion, times
a trillion) operations to brute-force a TLSv1.0 or TLSv1.1 transcript
hash. These hashes aren’t fixed, like the hashes on a certificate,
they are unique to every SSL/TLS session. To use this weakness an
attacker first has to intercept all communications between the sender
and receiver. They put themselves in the middle. Then, during the
handshake, the attacker must perform 150 trillion trillion operations
to “crack” the hash before allowing either side to proceed past the
handshake. This also must happen without either side timing out or
noticing the delay.

Advanced dedicated SHA1 crackers can crack approximately 100 billion
SHA1 hashes per second per processor. Even with these devices, it
would take about fifty thousand processor years to crack a single TLS
transcript hash. Performing the attack within 30 seconds would require
over 500 million such devices operating in parallel. There are also no
commercial devices capable of targeting the novel MD5/SHA1
combination, which is much more typical in TLSv1.0 and TLSv1.1. In
short, cryptographers are rightly concerned about this issue.
Processors will only get faster, and at some point, this attack may
fall within the capabilities of large actors such as nation states and
organized crime. But this issue is not a serious risk or threat for
most java applications.

3. TLS1.0 and TLS1.1 support only the CBC ciphers which are vulnerable
to Lucky13 and Sweet32. Turning off TLS1.0 and TLS1.1 actually doesn't
fully mitigate these - these ciphers can be used over TLS1.2 also. But
TLS1.2 does have better alternatives (e.g. AES-GCM). Lucky13 isn't a
practical attack against TLS, even in extremely favorable
circumstances for an attacker. Regardless, OpenJDK includes
mitigations and uses a constant-time padding algorithm which is what
matters.  That leaves Sweet32, which is specific to 3DES. This issue
impacts applications that send very large amounts of data, and again
requires an active interception from an attacker. Many large websites
with great security teams continue to maintain 3DES as a last-resort
for compatibility with legacy systems, and I can see the reasoning.

Other background: My experience is that many Java applications use TLS
for confidentiality, but often do not consider traffic interception
important in their threat model. It's very common to see self-signed
certificates being used, for example, which make any application
vulnerable to interception.  The kinds of places where TLS1.0 and
TLS1.1 are still used tend by their nature to be private networks that
have other security controls in place.

There are no TLS1.0 or TLS1.1 differences relating to how certificates
are handled. OpenJDK is also immune to downgrade attacks. An attacker
can't make it choose TLS1.0 or 1.1 if the other end supports TLS1.2 or
better.

On the whole, with all of those trade-offs in balance, it feels risky
to me to disable TLS1.0 and TLS1.1 right now. To be clear though: it
is better to use TLS1.2 than to use TLS1.0 and TLS1.1, and I'm very
glad that OpenJDK does it right. People should fix or remove those
legacy appliances in their networks, and I know customers that are. We
all know that attacks only improve over time.  But I don't think
there's quite any clearly exploitable or very concerning issue that
rises to the level of "this shouldn't even be supported in the
language right now". I also don't see it as a few "bad" users out
there holding back the rest of us. Keeping TLS1.0 and TLS1.1 in the
default set in no way prevents applications from using TLS1.2 or
better. But opinions can differ here. Others may prefer to be more
forceful with changes and to take on a mission of clearing cruft
faster.

We've been having internal discussions about this and wanted to bring
it here to the community and be open about it.

On Fri, Apr 2, 2021 at 1:22 PM Mathiske, Bernd <mathiske at amazon.com> wrote:
>
> We have recently been made aware of increasing concerns by customers that disabling TLS 1.0/1.1 in the upcoming round of OpenJDK updates on April 20, as is the plan of record, could still cause outages. So we are considering keeping TLS 1.0/1.1 enabled by default in Amazon Corretto for now.
>
> Can this default configuration change be deferred in general?
>
> Are there any concerns regarding Amazon Corretto keeping TLS 1.0/1.1 enabled by default?
>
> Should we offer an alternate build that conforms with disabling by default and have the two lines converge again at a later date?
>
> My understanding is that in principle TLS 1.2/1.3 is not more secure than 1.0/1.1 and therefore we are not looking at a security fix here, correct?
>
> We are aware that the default setting can be manually changed by every user, but considering automated intake of binary artifacts we anticipate that this will not always be applied and disruptions will still occur.
>
> (sent to jdk-updates-dev@,  jdk8u-dev@, and security-dev@)
>
> Bernd
>
>

-- 
Colm