IBM's cloud faces a test on Thursday: Turning something off without turning users off too IBM's cloud faces a big test this week: turning something off without botching the job. The "something" in this case is TLS 1.0 and 1.1, the known-to-be-ineffective cryptographic protocols that the world's abandoning just as fast as it can. In 2017 IBM gave its cloudy customers just a few days' notice of its intention to turn …
On old legacy software, where for e.g. .NET you potentially need to use a newer version e.g. only on greater than 4.0 does default become 1.2 and some old versions not even aware of 1.2 in any way (and so even if specifying TLS ratehr tahn using default you need to either do your own TLS1.2 hackery or to play nicely with .NET then upgarde ) and so often also run into all sorts of minor but irritating compatibility issues (especially if lots of other components all based on older .NET versions)
So what initially appears trivial can be far more extensive than a 10 minute re target and recompile job.
Not surprised users moaned if only given a few days notice initially.
.. Though they should have been doing it anyway, TLS 1.0 has been a big security hole for ages now and so refactoring to minimum of 1.2 should have been on everyone (who used TLS) to do list anyway, so you would hope by now that its no problem. After all the (often getting put back) PCI date for TLS 1.0 being finally dead is only a few months away so anyone doing TLS card processing on TLS 1.0 is cutting it fine (and taking a big risk)
While I haven't spent a lot of time looking(I have poked on occasion), I keep seeing people cite TLS 1.0 is very insecure yet don't post any links to exploits for it. I have seen others write the opposite, TLS 1.0 is generally fine, and the want to upgrade is generally paranoia.
I see a reddit thread which cites BEAST though mitigations are available for that on TLS 1.0 (as I put them in myself for Citrix Netscaler two or three years ago(and verified with SSL LABS testing) when we could not upgrade beyond TLS 1.0 due to a blocking Netscaler bug unrelated to TLS).
I'm sure there are lots of apps out there that don't even support TLS 1.0, but run on SSL v3 or maybe even older than that. Most likely such apps are not nearly as sensitive(came across one internal app a few days ago that was like that - SSL running on an older JVM).
So maybe someone here can cite an attack specific to TLS 1.0 that has no mitigations other than using a newer TLS. Things like BEAST and POODLE don't count as there are mitigations within TLS 1.0 implementations. But it is good for security scans to specifically scan for these vulnerabilities like SSL Labs.
Sure PCI folks will be forced to drop TLS 1.0, but PCI also does a lot of other things that are questionable when it comes to security (frequent password changes being my biggest complaint).
I also feel that hard dropping TLS, or any security thing is also bad for user experience, systems should degrade gracefully - if your client doesn't support the encryption then the server should be able to show a friendly error message describing what the situation is and how to fix it.
But no, the PCI security scans are pretty stupid when it comes to something like that.
The error messages the client gets back even to a technical user are often unintelligible. I have been working with SSL (on web servers anyway) for 20 years and even I get confused. What compounds the issue even more is when clients drop support (e.g. firefox dropping support and giving cryptic error messages when connecting to a server with older SSL -- in that situation the obvious solution is to present the server in the same way you would a self signed cert - give the user the ability to override the security issue and continue their work if they desire).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
