SSL HandShake ClientHello receives Encrypted Alert

My customer recently ran into a problem worth recounting. He had several machines which had a WCF application which made a secure SSL connection to a remote Web Service. However, a new set of machines built could not connect to the same endpoint using SSL. The new machines received the error: Could not create SSL/TLS secure channel

We took network traces on the failing system and found the Client Hello call received an Encrypted Alert from the remote web service:

- TLS: TLS Rec Layer-1 HandShake: Client Hello.

   - SSLHandshake: SSL HandShake ClientHello(0x01)

      HandShakeType: ClientHello(0x01)

      Length: 111 (0x6F)

    + ClientHello: TLS 1.0

 

- TLS: TLS Rec Layer-1 Encrypted Alert

  - TlsRecordLayer: TLS Rec Layer-1 Encrypted Alert

     ContentType: Encrypted Alert

   + Version: TLS 1.0

     Length: 2 (0x2)

     EncryptedData: Binary Large Object (2 Bytes)

The Encrypted Alert value can be seen with Netmon in the Hex Details:

We can convert the hex data to a meaningful message using the specification for TLS 1.0 from https://www.ietf.org/rfc/rfc2246.txt

7.2. Alert protocol

fatal(2)

handshake_failure(40) (28 to hex is 40)

So the remote server is reporting a handshake failure. So we asked, what is different about this client request and our working clients? The answer was our failing client was missing any RC4 ciphers:

       CipherSuitesLength: 20

     + TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA

     + TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA

     + TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA

     + TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

     + TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

     + TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

     + TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

     + TLSCipherSuites: TLS_DHE_DSS_WITH_AES_128_CBC_SHA

     + TLSCipherSuites: TLS_DHE_DSS_WITH_AES_256_CBC_SHA

     + TLSCipherSuites: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

The working client request contained these ciphers additionally:

TLS_RSA_WITH_RC4_128_SHA

TLS_RSA_WITH_RC4_128_MD5

And within the ServerHello, we can see the server has preferred the TLS_RSA_WITH_RC4_128_SHA=

- SSLHandshake: SSL HandShake ServerHello(0x02)

       TLSCipherSuite: TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 }

So what mechanism controls whether the client sends this RC4 cipher? The answer depends on a number of factors.

Microsoft Security Advisory 2868725

Published: November 12, 2013

https://technet.microsoft.com/library/security/2868725

 

This update supports the removal of RC4 as an available cipher on affected systems through registry settings. It also allows developers to remove RC4 in individual applications through the use of the SCH_USE_STRONG_CRYPTO flag in the SCHANNEL_CRED structure. These options are not enabled by default.

 

Update for Disabling RC4 in .NET TLS

Published: May 13, 2014 | Updated: July 8, 2014

https://technet.microsoft.com/library/security/2960358

 

My customer was at a later version of System.dll and Schannel.dll which contained these security updates and both systems were the same on version. Now, we went to check to see if the ciphers were disabled:

 

How to completely disable RC4

Clients that deploy this setting will be unable to connect to sites that require RC4, and servers that deploy this setting will be unable to service clients that must use RC4.

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]

 "Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]

 "Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]

 "Enabled"=dword:00000000

 

However, my customer did not have these values set on the working or failing system.

 

This caused us to look for another explanation altogether which could explain why .NET clients were failing to use the RC4 cipher. We discovered that in our failing environment the following registry key was enabled:

 

SchUseStrongCrypto

https://msdn.microsoft.com/en-us/library/windows/desktop/aa379810(v=vs.85).aspx

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto

Instructs Schannel to disable known weak cryptographic algorithms, cipher suites, and SSL/TLS protocol versions that may be otherwise enabled for better interoperability.

 

After setting this value to 0 and rebooting the system, the client began to send RC4 ciphers.This is very important to note: that you should not use weak ciphers. A detailed response on the topic from Microsoft may be found here https://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx.

 

Summary: (updated 3/4/2015)

 

1. Set your .NET Client to use SSL3 https://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.securityprotocol(v=vs.110).aspx

2. Set the following registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto = 0. This disables the new security update disabling RC4 Ciphers.

3. If the your application is 32bit running on x64 windows, you’ll need to modify the same key under the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319

Comments

• Anonymous
  May 02, 2016
  Very useful for linking the shady error with the cause (which is using weak or compromised ciphers).