Defer disabling TLS 1.0/1.1 by default?

[Martin Balao]

On 4/5/21 1:34 PM, Colm MacCárthaigh wrote:
> This is why I'd much rather add a measurement of TLS1.0 / 1.1 usage.
> Today it's hard to measure these; you can run tcpdump and figure it
> out but that's not a great option for a lot of environments. So often
> they have no idea how much traffic may be using it, just guesses. I
> sent a link to my email to a few people I know in the security
> industry and so far their estimates of usage here are actually much
> higher than mine, maybe even tens of per-cents. That's a lot of
> uncertainty for me. I feel like with a measure in hand, a number they
> could get out of their JVM, there'd be a tool we could all use to a)
> better measure impact and b) better drive results. Does RedHat have
> any visibility or numbers here? If there were firm data, we could just
> resolve this easily, but absent data I always prefer to assume the
> worst than the hope for the best.
> 

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.

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-.