I get it, older versions of TLS and SSL are insecure and we should not be using them. However I needed to get on an HPE Server iLO management interface last week and I
was met with this.
Firefox Error: SSL_ERROR_UNSUPPORTED_VERSION Microsoft Edge, Chrome, and Opera Error: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Microsoft Internet Explorer Error: This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening, try contacting the website’s owner. Your TLS security settings aren’t set to the defaults, which could also be causing this error.
Firefox Solution : SSL_ERROR_UNSUPPORTED_VERSION
I advise you just do this to get to the page you need to and set it back afterwards. In your browser windows enter about:config, Type TLS into the search bar and locate security.tls.version.min and change its value to 1, Then tick to save.
And now, I can get to where I want to go.
IE Solution : SSL_ERROR_UNSUPPORTED_VERSION
Yeah, I know Internet Explorer is supposed to be dead, but it’s still there and you can utilise it to solve this problem, from your internet options in IE > Advanced > you can then enable TLS 1.1. and 1.2.
You will still get a warning but now you can click past it.
Related Articles, References, Credits, or External Links
Both SSL and TLS are cryptographic protocols designed to secure communications over a network (remember the internet is just a network). Originally we had SSL version 1 and version 2. But they were, (to be honest) ‘a bit bobbins’ and full of security holes, so never really took off. Version 3 however did and was widely supported. The problem with version 3 was, (again) that was also ‘bobbins’. All this came to a head with the Poodle exploit and people started getting rid of SSLv3.
So, what about TLS? Well TLS v1.0 was largely based on, (but not compatible with) SSLv3. TLS 1.1 replaced v1.0 (circa 2006). Problems with it prompted TLS 1.2 (circa 2008). Then that was the standard until TLS v1.3 (circa 2018).
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. You can corrupt a strong protocol with a weak cipher and render it less secure. 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 are ‘Probably’ Reading this Because…
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.
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. 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. 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.
TLS 1.0 and TLS 1.1 might be ‘depreciated’ but it’s still widely used, disabling them will probably cause you more problems than the older SSL protocols, so test, test, and test.
ISOLATE: If you have old legacy applications and you need to retain them for compliance or financial reasons, then consider simply MITIGATING the risk by taking them off the local network, and running them in isolation.
DOCUMENT: If you need TLS 1.1 then that’s fine just because a scan picked it up, does not mean that you HAVE TO run to the server room and disable it. Most compliance standards are fine with you not fixing something, providing you document what it is and why it’s still enabled.
Windows TLS 1.2 Support: Clients from Windows Vista, and Servers from Server 2008 support TLS 1.2. but all the way to Windows 8.1 and Server 2012 R2 it requires an update, so make sure you are fully up to date before attempting to use TLS 1.2.
Exchange: Support for TLS 1.1 and 1.2 wasn’t added until Exchange 2013 (CU8) and Exchange 2010 (SP3 RU9). Beware Some (Older) Microsoft Outlook clients will only work with TLS 1.0
Windows Client (Internet Explorer) Disabling SSL3 and TLS 1.0, TLS 1.1
Before disabling protocols on the server, it’s good practice to disable those protocols on the clients, some time beforehand, the easiest way to do this is via Group Policy.
Windows Server Disabling SSL3 and TLS 1.0, TLS 1.1
Just as I was hunting around for an NFR version of Cisco ISE 1.3, they released 1.4. I wasn’t sure if I could upgrade my NFR version without breaking it so I thought I would ‘have a go’.
Solution
If you read the documentation for the upgrade of 1.2 to 1.4, I suggest you skip straight to the tasks to do AFTER upgrade, as it has a habit of resetting things back to default, best to make sure you know how everything is setup that might break before you start.
This upgrade took me a long time! The best part of an afternoon!
1. Before we do anything let’s take a snapshot, just in case it all goes to hell in a hand cart.
2. Gotcha! The upgrade fails if you have any expired certificates, even disabling them wont help, you need to delete all expired root certs before you start.
3. Copy the upgrade file from an FTP server to the ISE device, it wont show you any progress bar, go and get a coffee, if it does not error it’s probably copying over OK :).
4. When you get the prompt back you can check it’s there with a ‘dir’ command.
5. Before you can upgrade you need to create a repository for the upgrade;
[box]
ISE-01/admin# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
ISE-01(config)# repository upgrade
ISE-01(config-Repository)# url disk:
% Warning: Repositories configured from CLI cannot be used from the ISE web UI and are not replicated to other ISE nodes.
If this repository is not created in the ISE web UI, it will be deleted when ISE services restart.
ISE-01(config-Repository)# exit
ISE-01(config)# exit
[/box]
6. Then you need to ‘prepare’ for the upgrade.
[box]
ISE-01/admin# application upgrade prepare ise-upgradebundle-1.2.x-to-1.4.0.253.x86_64.tar.gz upgrade
Getting bundle to local machine...
md5: 35a159416afd0900c9da7b3dc6c72043
sha256: e3358ca424d977af67f8bb2bb3574b3e559ce9578d2f36c44cd8ba9e6dddfefd
% Please confirm above crypto hash matches what is posted on Cisco download site.
% Continue? Y/N [Y] ? Y
[/box]
7. Start the upgrade, this takes ages, go and have at least three coffees.
A few days ago I wrote about disabling SSL v3.0 to force your clients to connect with the more secure TLS v1.0. But what if your AnyConnect clients chose to connect with a weaker encryption cipher? The ciphers your firewall offer (by default) will vary depending on what OS your ASA is running.
Solution
1. To see what your cipher you are connected with look on the statistics tab, below we are connecting with the AES 128 encryption protocol and using SHA1 for hashing.
2. Where as here we are connecting with the more secure AES 256 and using SHA1 for hashing.
2. I force this by use of the ‘ssl encryption {option 1} {option 2} {etc.}’ approach. Below the first command indicated had AES 128 as the first encryption cipher, and the second command has AES 256, by specifying which order, you specify the order that the ASA offers the remote AnyConnect client.
WARNING: Removing ciphers can cause problems connecting to ASDMsee this article.
Ciphers supported by AnyConnect 4
TLS 1.3 is supported in the software, but not supported on ASA until version 9.3(2)
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-SHA256
AES256-SHA256
AES128-SHA256
Related Articles, References, Credits, or External Links
