Re-wire ?
Never knew software had wires... re-write maybe ?
IBM has announced it will again try to wean its cloud off the known-to-be-insecure TLS 1.0 and 1.1, but will also keep them available for some services. Big Blue has to try again because its first attempt gave users just a week to prepare. Users quickly complained that was nowhere near enough time to set their houses in order …
I'm sure that even as I type, the person left behind in IBM is typing in as clear and unambiguous language manageable the specifications for the change necessary. When I was liaising with the Chennai company that had received our outsourcing contract, the mantra was: 'You get what you specify'. The people there were good (while they were there that was) but nothing could be left to be assumed.
Clear, full specs are voluminous and hard because so many things can normally be left out (date format, for example).
Yes - someone working on complex tasks on unknown systems under time pressure can't afford to stop and ask whether you intentionally excluded certain steps or merely forgot them. A lot of offshore staff get a hard time for not using 'common sense' but they are not paid to guess what someone really meant at any particular point of a run book.
Of course, having people capable of creating clear, complete and unambiguous instructions or requirements talking to the customer may offset any savings from moving the execution to a low wage economy but blame the person who left that bit out of the cost case at the beginning.
The advantage of TLSv1.2 over TLSv1.1 & TLSv1.0 is small, and irrelevant in practice. Both, TLSv1.0 and TLSv1.1 have all security properties guaranteed for TLSv1.2 rfc5246 Appendix F.
https://tools.ietf.org/html/rfc5246#appendix-F
While allowing TLSv1.2 is trivial for servers, proposing TLSv1.2 for clients still results in interop problems. Send a ClientHello with ClientHello.client_version = TLSv1.2 and no TLS extensions to a Microsoft Schannel 2008R2 or 2012R2, and it'll choke and abort the handshake. Send the very same wrapped as SSLv2Hello, and it'll succeed the TLS handshake (albeit selecting TLSv1.1).
Similarily, if you have (accidentally) enabled SSLv2 in addtion to TLSv1.2 in MSIE 11, and try to connect to a server that supports and negotiates TLSv1.2 in response, Microsoft SChannel (MSIE) chokes and aborts.
btw. just look at the huge amount of Microsoft Software that requires non-trivial end-user opt-in to enable TLSv1.2:
Stuff based on WinHTTP, such as WebDAV in Microsoft Office needs a hotfix *PLUS* adding registry keys:
https://support.microsoft.com/en-us/kb/3140245
Situation with Microsoft .NET is similar:
https://blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support/
https://docs.microsoft.com/en-us/dotnet/framework/whats-new/#windows-communication-foundation-wcf
Stop whining about TLSv1.0. All attacks are either purely theoretical, or desperately require all three web browser design flaws (1) unlimited automatic silent downgrade dance, (2) execution of arbitrary attacker-supplied active content and (3) universal cross-site-request-forgery for silly demos.
Thanks for all the silly excuses you regt@rds came up with for running outdated, obsolete, AND vulnerable tech. I've got news for you, NONE of them count.
It is as simple as this: Your software still requires TLS 1.0 support ? Then you have these two options:
1. I will update asap.
2. I will make all versions that cannot be updated obsolete.
It is as simple as that. You should already be planning implementing TLS 1.3!!!