Tag Archives: insecure

Windows Server: Disabling SSL 3.0, TLS 1.0, and TLS 1.1

Posted on by
7

KB ID 0001675

What are these protocols?

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

Note: Before disabling anything enable TLS 1.2

Enable TLS 1.2

Execute the following PowerShell commands;

[box]

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null    
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null  
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null

[/box]

What this actually does is create some registry settings;

Disabling SSL v2.0 and SSL v3.0

Note: SSL 2.0 is normally disabled by default on modern versions of Windows.

Execute the following PowerShell commands;

[box]

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null 
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null 
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null

[/box]

What this actually does is create some registry settings;

 

Disabling TLS 1.0

Note: Depending on your setup this may impact production, test it first!

Execute the following PowerShell commands;

[box]

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null 
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null

[/box]

What this actually does is create some registry settings;

Disabling TLS 1.1

Note: Depending on your setup this may impact production, test it first!

Execute the following PowerShell commands;

[box]

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null 
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client' -name 'Enabled' -value '0' -PropertyType 'DWord' -Force | Out-Null 
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client' -name 'DisabledByDefault' -value 1 -PropertyType 'DWord' -Force | Out-Null

[/box]

What this actually does is create some registry settings;


Then REBOOT THE SERVER. Because NONE OF THE ABOVE WILL TAKE EFFECT until you do

Help Something’s Broken!

To revert your settings, execute the following PowerShell;

[box]

Remove-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\' -Recurse
Remove-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\' -Recurse
Remove-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\' -Recurse

[/box]

Then REBOOT THE SERVER.

Related Articles, References, Credits, or External Links

NA

Mac High Sierra – Telnet and FTP Missing?

Posted on by
13

KB ID 0001364

Problem

Why have Apple removed Telnet and FTP, yes they are old, yes they are insecure. For remote management you should be using SSH and for  file transfers you should be using SFTP or FTPS. However what if I want to telnet to a mail server on port 25 and test email flow? What if I need to connect to a Cisco switch that does not have a K9 operating system, and only supports Telnet?

-bash: telnet: command not found
-bash: ftp: command not found

Well I can install Secure CRT, (or use the Excellent Royal TSX.) But, I’m stuck in my ways and want it back where it belongs, i.e. in my Terminal Window!

Solution

Download the Executables ‘Here‘.

Extract the files and make sure they are ‘executable’, i.e. they look like this;

If not, you can use ‘chmod +x’ to make them executable;

Copy the files to: /usr/local/bin

All working again.

Related Articles, References, Credits, or External Links

NA

Windows – How to Join a Wireless Network

Posted on by

KB ID 0000676 

Problem

You can still right click the networking icon in your task tray and manually join a wireless network, but with the new UI there is a much more user friendly way.

Solution

1. Bring up the Settings menu (Press Windows Key+I, or swipe in form the left on a tablet/tablet) > Select the available networks icon.

2. Select the wireless network you want to connect to.

3. If you want to always connect to this network tick the box and select ‘Connect’.

4. If your router has a PIN number for access (check its documentation) then you can enter that here, and follow the instructions. The PIN number is usually shown on the router/access point on a sticker. However if you use a WEP or WPA password, then select ‘Connect using security key instead’.

Note: The system for joining a wireless netork using a PIN number, is very insecure! just to a Google search for “hacking wireless with reaver”, I suggest you disable this feature if you can.

5. Type in your WEP/WPA Key > Next.

6. All being well, you should now be connected.

Related Articles, References, Credits, or External Links

NA

Cisco ASA – Disable SSLv3 (Force TLSv1.0) – Mitigate POODLE

Posted on by

KB ID 0001052

Problem

By default the Cisco ASA will allow connection via SSLv3. The POODLE exploit works by forcing SSL to fall back to SSLv3 and then decrypting that communication. However you are still not completely protected as per this Threat Validation, so the ASA platform can still be attacked via TLSv1.0. Note: At time of writing TLSv1.2 is not supported, but it is on the road-map for version 9.3(2).

So this procedure will not completely eliminate the threat, but it’s as mitigated as it’s possible to be at this time, (And TLSv1 is considered more secure than SSLv3 anyway).

Solution

1. You can check your firewall is contactable via SSLv3, here I’m on MAC OSX and I’ve got OpenSSL installed. If I try to initiate an SSLv3 connection it works.

[box] openssl s_client -connect {IP_or_Hostname} -ssl3 [/box]

Or if you have nmap installed you can use that as well;

[box]nmap –script ssl-enum-ciphers {IP_of_Hostname}[/box]

2. Below you can see I’m confirming the SSL settings (i.e. it will accept SSLv3). Then I force the firewall to only accept TLSv1.0.

[box]

Petes-ASA# configure terminal
Petes-ASA(config)# ssl client-version tlsv1-only 
Petes-ASA(config)# ssl server-version tlsv1-only

[/box]

You can see, afterwards when I view the SSL options, only TLSv1 will be accepted.

3. If you prefer to use the ADSM, then you will find the same settings at, Configuration > Remote Access VPN > Advanced > SSL Settings;

The SSL version for the security appliance to negotiate as a ‘server’ = TLS V1 Only

The SSL version for the security appliance to negotiate as a ‘client’ = TLS V1 Only

 

4. Don’t forget to ‘Apply’ and then save the changes.

Cisco ASA Testing for SSLv3

Simply perform the tests that I did above;

1. Proving the absence of SSLv3 with OpenSSL.

2. Proving the absence of SSLv3 with nmap.

Related Articles, References, Credits, or External Links

NA