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