Configuring Secure Ciphers Suites and TLS

-

Hey everyone, today we're back on cipher suites. If you want a refresher of TLS and secure cipher suites overall, check out my previous post.

There are many instances in which you'll need to edit cipher suites on a system -- compliance efforts, CIS benchmarks, or simply ensuring your system doesn't use insecure suites. There are a few ways to go about this and I'll detail two of them now: IIS Crypto and the Windows registry.


IIS Crypto

My favorite way of editing TLS versions and cipher suites is using IIS Crypto. IIS Crypto allows you to select your desired TLS/SSL version, cipher suites, and backup the registry, all with a few mouse clicks. Only downside is that it's Windows only (even the command line version).


This is what IIS Crypto will look like on an unmodified Windows 10 system. Note the separate Server Protocols and Client Protocols sections. These are important to keep straight depending on what system is listening for connections and what system is initiating connections. If you modify just one of these on both a server and client you may break their ability to make a connection! 

Also, notice all the boxes are checked but seemingly "grayed out". This is IIS Crypto indicating that the default value is set. This is also true over on the Cipher Suites page. Yes, there are multiple pages with mostly redundant information on them that you need to ensure both are set accurately. More on that later. (Also, if you're curious about some of the functionality of IIS Crypto they have a great FAQ).


Check/un-check the desired protocols and cipher suites, then click Apply. You'll need to reboot your system for the changes to take effect (or check the "Reboot" box before clicking Apply in IIS Crypto).

Then you're done! Yes, it's really that easy. The hard part is troubleshooting connections you inevitably break because some software you have installed insists on using TLS 1.1 or won't work with ECDHE.

Windows Registry

So what is IIS Crypto actually doing that's making these changes? And what if I don't want to (or can't) install software to do this?

Don't worry. IIS Crypto is just conveniently modifying the registry so you don't have to.

Remember to backup your registry before making any changes and reboot after making these changes in the registry.

Protocols

Open Registry editor and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\

On a default install of Windows there will be nothing beyond the Protocols key. For every protocol you want to enable or disable you will need to create a few things:
  • One key under Protocols reflecting the name of the protocol (e.g. TLS 1.2)
  • Two keys under that key -- Client and Server
  • Two REG_DWORD values -- Enabled and DisabledByDefault
  • Set the Enabled value to 1 (binary) and the DisabledByDefault value to 0 (binary)
    • This enables TLS 1.2 as a client protocol and it will be enabled by default.
    • Swap these values if you want to disable the protocol.

Cipher Suites

Open Registry Editor and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\

Again, this will be empty by default.

For every cipher suite you want to enable or disable you will need to create a few things:
  • One key under Ciphers reflecting the name of the cipher in the following format:
    • Name VALUE/VALUE
    • E.g. SCHANNEL\Ciphers\AES 256/256
  • One REG_DWORD value -- Enabled
  • Set the Enabled value to 1 (binary)
    • This enables the cipher suite.
    • Make Enabled 0 (binary) to disable the cipher.

Cipher Suite Order

Lastly, we have the Cipher Suite order. This is found at:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

Again, by default this will not have any values set.

You can edit this directly or use Local Group Policy (or of course normal Group Policy when pushing this change out to several systems).

Create a value named Functions of type REG_MULTI_SZ. This is where you list your desired cipher suites. If you choose to go this route, remember four things:
  1. The order matters. First in the list will be tried first and so on. You may list 20 here but some applications may stop looking after 10. Prioritize appropriately.
  2. The cipher suites are comma separated values. 
  3. Do not include any spaces.
  4. The cipher suite(s) you want to use are named correctly. This can vary depending on your Windows OS (mostly around Elliptical Curve cipher suites as Windows 10/2016 no longer requires _P256, etc., designations on EC suites while 2012R2 and before does).
Credit: Microsoft
(https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs)


Final Thoughts

You can see why I like IIS Crypto or controlling this via GPO.

Some other things I couldn't dedicate an entire section to today but want to mention:
  1. Some applications will completely ignore your cipher suite preferences. For example, Google Chrome comes with its own set of cipher suites it will attempt to use when connecting with the world.
  2. If you run into trouble remember Wireshark can tell you exactly what is being proposed as acceptable cipher suites on both the client and server sides.
  3. Other parameters than those covered here can cause problems in connections -- for example, KeyExchangeAlgorithms.
  4. Linux/UNIX systems also need to be hardened to use TLS 1.2 with secure cipher suites. That's a post for a different day, but in case that's what you came here looking for here's a couple links to get you started:
    • https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-hardening_tls_configuration
    • https://community.tenable.com/s/article/How-to-check-the-SSL-TLS-Cipher-Suites-in-Linux-and-Windows
    • https://unix.stackexchange.com/questions/153917/openssl-updating-ciphers-suites
Hope this helps!

Comments

Post a Comment

Popular Posts

Hashcat - Cracking MD5 and NTLM Hashes

-
Image
Today we'll be exploring Hashcat -- "the world’s fastest and most advanced password recovery utility". This, along with similar tools, should be used only for password recovery, pentest engagements, CTFs, etc and never for illegal purposes. I could write an entire series about the capabilities Hashcat provides, but we will cover a few basic examples for now ( besides, Hashcat does a pretty good job of that themselves ): Crack MD5 hashes using the rockyou.txt wordlist. Crack NTLM hashes using the rockyou.txt wordlist. Crack NTLM hashes using a mask attack (modified brute force). I'll be using Kali Linux as Hashcat comes pre-installed, but Hashcat can run on Windows, macOS, and other Linux distributions as well. As you'll see, I'll be using some lists of hashes I made previously. Tools to generate hashes using dozens of algorithms are available online -- just save the output as a text file if you want to follow along. Cracking MD5 Hashes Using rockyou.txt Wordl
Read more

Configuring SSH Key Based Authentication

-
Image
Overview Most personal computers and many organizations running Linux servers utilize password-based authentication. This is what most of us are used to -- you enter a username and password in order to authenticate your account and gain access to a system. While straightforward and commonplace, this isn't the best solution in most cases. Today I'll be explaining why key based authentication is more convenient, more secure, and allows for automation of tasks without saving credentials in plain-text in a text file. Key based authentication involves the use of private and public keys ( public-key cryptography ). The private key is stored on the client and the public key is stored on the server in a special file ( ~/.ssh/authorized_keys ). This allows any system with the corresponding private key to login to the server where we just stored the public key. Our steps are: Generate key pair (public / private key). Transfer public key and add it to the authorized_keys file on the remot
Read more