Defer disabling TLS 1.0/1.1 by default?
colm at apache.org
Mon Apr 5 23:44:41 UTC 2021
On Mon, Apr 5, 2021 at 11:11 AM Martin Balao <mbalao at redhat.com> wrote:
> I'll let others share their opinions but wanted to make a comment on
> this. While I agree to some extent on the benefit of having aggregated
> data of TLS 1.0/1.1 usage specific to OpenJDK, I don't see feasible to
> retrieve such usage stats from the OpenJDK side. In addition to privacy
> concerns, there would be the question of how representative the data is
> (for technical and non-technical reasons) and the infrastructure needed
> to handle it. Knowing if the reason for not upgrading is OpenJDK would
> be more beneficial and actionable to us. My understanding is that the
> latter is not the case: we have a well tested implementation of TLS 1.2.
Totally agree that a phone-home spyware metric is a bad idea, although
some browsers have been able to do those while preserving privacy it's
not the kind of thing that should happen in a JVM. I can only imagine
the IDS's that it would trip. But I do think a local metric would be
useful. I've been through a lot of deprecations; SSLv2, SSLv3, MD5,
SHA1, RC4, 3DES, and I know from talking to other vendors and TLS
teams that the approach of "measure first" is pretty standard. Every
time I've been surprised by what I've found ... and I'm keen to work
with people. It only makes things more clear.
> As you said, many users will decide to implement the
> backward-compatibility configuration and keep using it. Removing the
> protocols from a default configuration looks to me a middle ground
> between doing nothing and the auditor enforcing compliance. Security
> updates often require users to reassess decisions and, eventually, make
> changes. All of that for a good reason. The point that I want to make is
> not on the number of users affected but to nuance the disruption impact
> they may have: the change should be catch in testing environments and
> the backward-compatibility configuration should be well documented -and
> straight forward to apply, as in this case-.
I do think it will cause outages; many don't read the release notes or
roadmaps, even more don't have the expertise to even know that they
are using TLS1.0 and 1.1. They trust that a vendor wouldn't do it
lightly and won't be expecting a breaking change this low in the
networking stack. Infrastructure in testing setups doesn't always
match what's in production, so it's setting off my spidey-senses. I'm
loath to cause outages without very compelling reasons and a lot of
work to minimize the risk.
More information about the jdk-updates-dev