How to Fix Weak SSL/TLS Key Exchange vulnerability (Diffie-Hellman)
In this article will discuss about how to fix How to Fix Weak SSL/TLS Key Exchange in Windows vulnerability (Diffie-Hellman) in windows server operating system.
In January 2016, Microsoft announced support for TLS 1.2 encryption for SQL Server 2008, 2008 R2, 2012 and 2014. That announcement has since been updated to include support for SQL Server 2016 and 2017. Previously, Microsoft only supported SSL encryption in SQL Server, however given the spate of reported vulnerabilities against SSL, Microsoft now recommends that you move to TLS 1.2.
The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are implemented by Schannel, an Internet Security Support Provider (SSP).
Weak SSL/TLS Key Exchange detected on servers over port 443 and also detected on SQL severs over port 1433 under Qualys QID 38863
Cipher Suite
A cipher suite is a collection of cryptographic algorithms used to establish a secure connection between the client and server. During the SSL/TLS handshake, both the client and host computer agree upon an encryption method from the cipher suites to create keys and encrypt information.
Key Exchange
TLS key exchange allows two parties to use a cryptographic algorithm by exchanging cryptographic keys. For example, a symmetric session key is generated during SSL/TLS handshake before an encrypted message is transmitted. RSA and Diffie-Hellman-Merkle are the top key exchange algorithms used.
Symmetric Encryption
Symmetric encryption encrypts and decrypts using the same (one) key. Compared to asymmetric cryptography, this is more efficient – it needs less encryption time, uses fewer resources, and can transfer large volumes of data, while also maintaining confidentiality. Cipher text is the same or smaller than the plain text.
Asymmetric Encryption
Asymmetric encryption uses two keys: a public and a private key. This means a message encrypted with a public key can only be decrypted with the corresponding private key. It provides better security as the keys are never shared and allow the user to authenticate data using digital signatures. It is slower than symmetric encryption and can only be utilized for small amounts of data. Cipher text is the same or larger than plain text.
What Happens During a SSL/TLS Handshake: Step-by-Step Process
The exact steps needed to complete a SSL/TLS handshake depend on the encryption algorithm used, but the basic process is as follows:
Step 1:
The SSL/TLS client will send the server a “ClientHello” message that details the client’s configuration settings, including the SSL/TLS version, the cipher suites it supports, the data compression technique it employs, and a string of random data referred to as “client random.”
Step 2:
The SSL/TLS server sends back a “ServerHello” message containing its own public key, digital certificate, session identifier, the cryptographic algorithm agreement (selected by the server from the client-supplied list of algorithms), and the “server random”.
Step 3:
The client performs authentication by contacting the server’s certificate authority (CA) to validate the web server’s digital certificate. This confirms the authenticity of the web server, thus, establishing trust.
Step 4:
During the ClientKeyExchange step, the client extracts the public key from the verified certificate and generates a new random sequence called the premaster secret. The premaster secret is then encrypted using the extracted public key and is sent to the server.
Step 5:
The SSL/TLS server decrypts the premaster secret using its private key.
Step 6:
Both the client and the server now use the premaster secret to configure a shared secret key.
Step 7:
Next, the client sends an encrypted “finished” message using the shared secret key. This message says that the client’s part of the handshake is complete.
Step 8:
Finally, an encrypted “finished” message is sent back to the client from the server using the previously agreed shared secret key, which indicates the end of the server’s side of the handshake.
Step 9:
Once the SSL/TLS handshake and negotiation is done, the server and the client communication continues, i.e., they begin to share files and messages using the session keys (symmetric encryption).
Diffie-Hellman (DH) Algorithm
Diffie-Hellman (DH) Algorithm is a key-exchange protocol for two parties communicating over a public channel, enabling them to establish a secret without having it transmitted over the Internet. Using symmetric cryptography, the two parties are able to encrypt and decrypt their communication or data using a public key.
THREAT:
Key exchanges that are cryptographically weaker than recommended are supported by the SSL / TLS server. For Diffie Hellman and RSA key exchanges, key exchanges should provide at least 224 bits of security, which translates to a minimum key size of 2048 bits.
IMPACT:
As a result, attacker could recover the session key and decrypt the session content.
How to Fix the Vulnerability
For Diffie Hellman and RSA key exchanges, the SSL (Secure Socket Layer) /TLS (Transport Layer Security) server configuration should only allow strong key exchanges and key exchanges should provide at least 224 bits of security.
Check for the registry key if exist.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS
SSL/TLS key exchange
Weak SSL/TLS Key Exchange when a TLS client connects to a TLS server, the client negotiates a mutually available encryption suite to use. The client lists its available cipher suites, the server responds, and the client chooses the most secure, mutually available one.
If said registry path does not exist then create the same. Follow below steps to create registry key.
1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. Locate and then click the following subkey: *HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms*
3. On the Edit menu, point to New, and then click Key.
4. Type PKCS for the name of the Key, and then press Enter. Select the PKCS key.
5. On the Edit menu, point to New, and then click DWORD Value.
6. Type ClientMinKeyBitLength for the name of the DWORD, and then press Enter.
7. Right-click ClientMinKeyBitLength, and then click Modify.
8. In the Value data box, type the new minimum key length (in bits), and then click OK. Note You do not have to restart the computer after you add or change this registry entry for the change to take effect. However, you do have to restart the computer if you delete the entry.
Conclusion:
Diffie Hellman and RSA key exchanges has been added to KEY-SIZE 2048 at the OS level. Weak SSL/TLS Key Exchange issue has been fixed successfully. Please feel free to contact if still issue persist or need any help.