
Remember if you provide a web based service it will also need testing with any browser that your staff, or even the public may be using to access your web based platforms. Simply disabling SSLv3.0, TLS v1.0,1.1, and/or 1.2 can have some negative effects, either on YOUR applications or in the browsers of your clients. THINK: Security is a good thing, (I’m all for it,) BUT just rushing to turn things off, can cause you problems, where possible test any remediation in a test environment, many old legacy (for legacy read ‘applications that are business critical, and you can no longer update or get support on’) may still be using these old protocols. If you’ve had a security audit, or a company had scanned your network and produced a report that says you are running insecure protocols and you need to do something about it. In some cases, you may need to do this, or you might simply enable a web cipher to fix a ‘ problem’ without understanding the consequences. You can corrupt a strong protocol with a weak cipher and render it less secure.

However: Just because you use the newest protocols does not necessarily mean you are more secure: Most documentation you read says TLS 1.2 ‘ Should’ be secure (that’s reassuring eh!) This is because these protocols are built on cryptographic ciphers and they are only as secure as those ciphers. Then that was the standard until TLS v1.3 (circa 2018). Problems with it prompted TLS 1.2 (circa 2008). So, what about TLS? Well TLS v1.0 was largely based on, (but not compatible with) SSLv3. All this came to a head with the Poodle exploit and people started getting rid of SSLv3. The problem with version 3 was, (again) that was also ‘ bobbins’. Version 3 however did and was widely supported. But they were, (to be honest) ‘ a bit bobbins’ and full of security holes, so never really took off.

Originally we had SSL version 1 and version 2. Both SSL and TLS are cryptographic protocols designed to secure communications over a network (remember the internet is just a network).
