Ssl – What determines the combination of ciphers available on an SSL server

authenticationiisiis-7sslssl-certificate

I have a site that has been bound to a new SSL certificate with SAN (4 additional names).
The certificate has a 2048-bit key.

The problem is that it works on some browser/OS combinations but not on others.

IE7 / Win XP – fail
IE6 / Win 2003 – fail
IE8 / Win XP / Corporate proxy – OK
IE8 / Win 7 / OTHER Corporate proxy – fail
IE9/10 / Win 7 – OK
Chrome / Win 7 – OK
Firefox / Win 7 – OK
Chrome / Android – OK

Note: The two corporate proxies are very different organisations, in two separate countries.

I have installed Fiddler on the IE6 / Win 2003 (2nd on the list) and have captured this from the Inspectors\Raw tab:

IE6:

CONNECT sorry.site.not.disclosed:443 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; FDM; .NET4.0C; .NET4.0E)
Host: sorry.site.not.disclosed
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache

A SSLv2-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Major Version: 2
Minor Version: 0
Random: EA AE EB C5 20 0C 46 90 7F C1 E0 EE 47 BE 05 63
SessionID: empty
Ciphers: 
    [10080] SSL2_RC4_128_WITH_MD5
    [700C0] SSL2_DES_192_EDE3_WITH_MD5
    [30080] SSL2_RC2_128_WITH_MD5
    [60040] SSL2_DES_64_WITH_MD5
    [20080] SSL2_RC4_128_EXPORT40_WITH_MD5
    [40080] SSL2_RC2_128_EXPORT40_WITH_MD5
    [00FF]  TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Compression: 
(not specified)
Extensions: 
    none

Chrome:

CONNECT sorry.site.not.disclosed:443 HTTP/1.1
Host: sorry.site.not.disclosed
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22

A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Major Version: 3
Minor Version: 2
Random: 51 4A 0D 68 FE C4 50 A9 26 43 9E 1A C2 E9 05 5C FE 5F CF 37 4D 20 96 FF 0E 2F 5E EB 16 C1 F2 20
SessionID: empty
Ciphers: 
    [C014]  TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
    [0088]  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
    [0087]  TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
    [0039]  TLS_DHE_RSA_WITH_AES_256_SHA
    [0038]  TLS_DHE_DSS_WITH_AES_256_SHA
    [C00F]  TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
    [0084]  TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
    [0035]  TLS_RSA_AES_256_SHA
    [C011]  TLS_ECDHE_RSA_WITH_RC4_128_SHA
    [C013]  TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
    [0045]  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
    [0044]  TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
    [0066]  TLS_DHE_DSS_WITH_RC4_128_SHA
    [0033]  TLS_DHE_RSA_WITH_AES_128_SHA
    [0032]  TLS_DHE_DSS_WITH_AES_128_SHA
    [C00C]  TLS_ECDH_RSA_WITH_RC4_128_SHA
    [C00E]  TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
    [0096]  TLS_RSA_WITH_SEED_CBC_SHA
    [0041]  TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
    [0005]  SSL_RSA_WITH_RC4_128_SHA
    [0004]  SSL_RSA_WITH_RC4_128_MD5
    [002F]  TLS_RSA_AES_128_SHA
    [C012]  TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
    [0016]  SSL_DHE_RSA_WITH_3DES_EDE_SHA
    [0013]  SSL_DHE_DSS_WITH_3DES_EDE_SHA
    [C00D]  TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
    [FEFF]  SSL_RSA_FIPS_WITH_3DES_EDE_SHA
    [000A]  SSL_RSA_WITH_3DES_EDE_SHA

Compression: 
    [00]    NO_COMPRESSION

Extensions: 
    server_name sorry.site.not.disclosed
    renegotiation_info  00
    elliptic_curves 00 06 00 17 00 18 00 19
    ec_point_formats    01 00
    SessionTicket TLS   empty
    NextProtocolNegotiation empty
    channel_id(GoogleDraft) empty
    status_request  01 00 00 00 00

When testing using SSLLabs, e.g. https://www.ssllabs.com/ssltest/analyze.html?d=mail.google.com

The site shows ONLY two options under cipher suites, and supports only TLS 1.0:

Protocols
TLS 1.2 No
TLS 1.1 No
TLS 1.0 Yes
SSL 3.0 No          
SSL 2.0 No

Cipher Suites (SSLv3+ suites in server-preferred order, then SSLv2 suites where used)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH 256 bits (eq. 3072 bits RSA)                                128         
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH 256 bits (eq. 3072 bits RSA)

I have contacted Verisign (Australia) and the chap claims that all Verisign certificates support SSLv1, v2, v3, TLS.

So why does the IIS server not present it? Using a SELF-SIGNED wildcard certificate, I was able to get the same IIS server to report on SSLLabs:

Protocols
TLS 1.2  No 
TLS 1.1  No 
TLS 1.0  Yes 
SSL 3.0  Yes
SSL 2.0   INSECURE           Yes

Cipher Suites (SSLv3+ suites in server-preferred order, then SSLv2 suites where used)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)          128         
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)          256         
TLS_RSA_WITH_RC4_128_SHA (0x5)      128         
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)         168         
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH 256 bits (eq. 3072 bits RSA)                128         
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH 256 bits (eq. 3072 bits RSA)                256         
TLS_RSA_WITH_RC4_128_MD5 (0x4)     128         
SSL_DES_192_EDE3_CBC_WITH_MD5 (0x700c0)                168         
SSL_RC4_128_WITH_MD5 (0x10080)       128

Where to look next?

Best Answer

On all Windows 2008 R2 servers that I've seen ssl v2 has been enabled by default and I've had to go and disable it myself. Doing so (disabling it) hasn't seemed to break IE6... obviously the machine has been hardened by someone

Qualys has a very decent online SSL scanner that will tell you exactly what protocols and even cipher suites you have enabled, and if there are any other cert errors and what renegotiation is allowed - https://www.ssllabs.com/ssltest/ - perhaps an overly limited combination of ciphers and protocols has been chosen.

When you say it fails - what do you mean? That there is a certificate error? Is the root CA trusted on the older client machines?

It is possible in IE to disable SSL v3 and other protocols, on those machines throwing errors, check in Tools / Internet Options / Advanced tab and see if SSL 3 and TLS 1 is checked.

Check the values of the following reg keys

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\DisableRenegoOnClient
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\DisableRenegoOnServer

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\AllowInsecureRenegoClients
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\AllowInsecureRenegoServers

see http://support.microsoft.com/kb/977377 and http://support.microsoft.com/kb/980436

Related Solutions

Ssl – Why does Window’s SSL Cipher-Suite get restricted under certain SSL certificates

If the certificate being used on the server was generated using the Legacy Key option in the certificate request form, the private key for that certificate will be stored in Microsoft's legacy Cryptographic API framework. When the web server tries to process requests using its new, Cryptographic Next Generation (CNG) framework, it appears that something related to the RSA private key stored in the legacy framework is unavailable to the new framework. As a result, the use of the RSA cipher suites is severely limited.

Solution:
Generate the certificate request using the CNG Key template in the custom certificate request wizard.

MMC | Local Computer Certificate Manager | Personal Certificates Folder | (right click) | All Tasks -> Advanced Operations | Create Custom Request | "Proceed without enrollment policy" | select "(no template) CNG key" | proceed to complete the certificate request according to your needs.

Verifying that the key is in the right place:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

Tools for verifying correct cipher-suites:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

SSL cipher-suite settings:
http://support.microsoft.com/kb/245030
http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx

This took us a week to figure out. I hope this saves someone the same trouble.

Ssl – RC4 cipher not working on Windows 2008 R2 / IIS 7.5

The issue why RC4 isn't working is that is has to be set to 0xfffffff or 4294967295 in the registry, not 1 to enable it.

Here's some PowerShell functions which were used to set our IIS installs up with the PCI compliant:

This function is used to enable/disable required protocols

function Set-IISSecurityProtocols {
$protopath = "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"
& reg.exe add "$protopath\PCT 1.0\Server" /v Enabled /t REG_DWORD /d 00000000 /f
& reg.exe add "$protopath\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 00000000 /f
& reg.exe add "$protopath\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 00000001 /f
& reg.exe add "$protopath\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 00000001 /f
& reg.exe add "$protopath\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 00000001 /f
& reg.exe add "$protopath\TLS 1.1\Server" /v DisabledByDefault /t REG_DWORD /d 00000000 /f
& reg.exe add "$protopath\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 00000001 /f
& reg.exe add "$protopath\TLS 1.2\Server" /v DisabledByDefault /t REG_DWORD /d 00000000 /f
& reg.exe add "$protopath\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 00000001 /f
& reg.exe add "$protopath\TLS 1.1\Client" /v DisabledByDefault /t REG_DWORD /d 00000000 /f
& reg.exe add "$protopath\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 00000001 /f
& reg.exe add "$protopath\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 00000000 /f

}

And this function is where you set what ciphers are allowed to be used, or not used

function Set-IISSupportedCiphers {
$cipherpath = "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers"
& reg.exe add "$cipherpath\NULL" /v Enabled /t REG_DWORD /d 00000000 /f
& reg.exe add "$cipherpath\DES 56/56" /v Enabled /t REG_DWORD /d 00000000 /f
& reg.exe add "$cipherpath\RC2 40/128" /v Enabled /t REG_DWORD /d 00000000 /f
& reg.exe add "$cipherpath\RC2 56/128" /v Enabled /t REG_DWORD /d 00000000 /f
& reg.exe add "$cipherpath\RC2 128/128" /v Enabled /t REG_DWORD /d 00000000 /f 
& reg.exe add "$cipherpath\RC4 40/128" /v Enabled /t REG_DWORD /d 00000000 /f
& reg.exe add "$cipherpath\RC4 56/128" /v Enabled /t REG_DWORD /d 00000000 /f
& reg.exe add "$cipherpath\RC4 64/128" /v Enabled /t REG_DWORD /d 00000000 /f
& reg.exe add "$cipherpath\RC4 128/128" /v Enabled /t REG_DWORD /d 4294967295 /f
& reg.exe add "$cipherpath\Triple DES 168/168" /v Enabled /t REG_DWORD /d 4294967295 /f
& reg.exe add "$cipherpath\AES 128/128" /v Enabled /t REG_DWORD /d 4294967295 /f 
& reg.exe add "$cipherpath\AES 256/256" /v Enabled /t REG_DWORD /d 4294967295 /f

}

Once these changes have been set (A reboot is required afaik) you then can set the priority in which the ciphers are used.

To immune the BEAST vulnerability it's reccomended you used RC4 first as outlined @ http://www.phonefactor.com/blog/slaying-beast-mitigating-the-latest-ssltls-vulnerability.php

This will be the case until either

All browsers patch the BEAST vulnerability
Or everyone starts supporting TLS1.2

Best Answer

Related Solutions

Ssl – Why does Window’s SSL Cipher-Suite get restricted under certain SSL certificates

Ssl – RC4 cipher not working on Windows 2008 R2 / IIS 7.5

Related Topic