Defer disabling TLS 1.0/1.1 by default?

[Martin Balao]

Hello,

Thanks @Colm and @Bernd for raising these well-founded concerns.

We at Red Hat are already disabling by default TLS 1.0 and 1.1 in our 8
& 11 OpenJDK builds. This is because of our strict security posture and
a unified crypto policy management in RHEL, that goes across different
products and libraries. Users can still re-enable these protocols making
fairly easy configurations.

I believe we will be more or less on the same side in regards to the
technical arguments, the security assessment and the risks taken by
keeping these protocols enabled. There is always a chance that something
unknown emerges and old protocols are more likely to be affected. But
it's clear that there is not an imminent, publicly-known and critical
security risk at this moment; and, thus, the reason why the change was
on Oracle's JDK crypto-roadmap since 2019 and has been postponed before
[1]. It's the same discussion that browsers and other libraries/runtimes
are having.

I see this more of a product-management discussion. The protocols are
old enough and, due to increasing security risks, need to be removed
from a default configuration at some point. There will be users
affected, always, and particularly with protocols so widely used in the
past. I hope we are all on the same page there. The question is about
timing and the balance between 1) the current security risk, 2) how many
users will upgrade their applications in an extra time-frame if we
postpone the change, and 3) how disruptive would be for a user to change
a configuration property for backward compatibility.

While I acknowledge that the change will disrupt some users, I tend to
take that as part of the risk of keeping legacy systems running in
production environments. With this change announced in advanced, I don't
see it more disruptive than when OpenJDK vendors deprecate support for a
legacy OpenJDK release and users are forced to upgrade. Contrary to
that, there is backward compatibility workaround that looks fairly
reasonable -users are already familiar to changing security properties-.

I believe we are late on the release cycle to postpone now. I wouldn't
have opposed if there were general agreement and a new target date later
this year; but I personally think that, in terms of the disruption
caused, the gain won't be significant.

Martin.-

--
[1] - https://java.com/en/jre-jdk-cryptoroadmap.html