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 |
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 <[hidden email]> 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 |
Free forum by Nabble | Edit this page |