Deprecating TLS 1.0 and 1.1
Every major browser drops them next year. We are following, with a twelve-month notice period and a list of exactly who is affected.
TLS 1.0 is twenty-one years old. It has been deprecated by the PCI Council since 2018, and Chrome, Firefox, Safari and Edge have all announced removal during 2020. We are turning both 1.0 and 1.1 off on the gateway on 1 December 2020.
That is twelve months of notice, which is longer than we need and shorter than someone will want.
Who this affects
Zero point three per cent of requests in the last thirty days negotiated TLS 1.0 or 1.1. That is not zero, and we know exactly which accounts they belong to.
Every affected account has been emailed individually with the specific keys and source addresses involved, rather than a general announcement that everyone ignores. If you did not get an email, you are not affected, and you can confirm that yourself — the dashboard now shows negotiated TLS version per request in the usage view.
What is actually wrong with them
TLS 1.0 predates a lot of understanding about how these protocols fail. It is vulnerable to BEAST, its CBC constructions have produced a decade of padding oracle attacks, and it can be downgraded. Mitigations exist for all of these and each one is a workaround for a design that should be retired.
TLS 1.1 fixed the initialisation vector problem and little else. Nobody deploys 1.1 deliberately; it is what you get when a library negotiates down.
What to do
Almost always, this is a runtime upgrade rather than a code change. Anything running a current version of OpenSSL, .NET, Java 8 or later, or any maintained language runtime already negotiates 1.2 or 1.3 by default.
The systems that genuinely cannot are usually embedded devices or an application server pinned to an ancient runtime for reasons that have nothing to do with TLS. If that is you, tell us — we would rather find a path for you over twelve months than have you discover this on 1 December.