Changing the SSL cipher order in Internet Explorer 7 on Windows Vista
Recently, the question of using AES for SSL has come up in the newsgroups and at some conferences. When IE makes an HTTPS connection to a web server, it offers a list of cipher supported cipher suites. The server then selects the first one from the list that it can match. The default order that IE follows is this:
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
SSL_CK_RC4_128_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
When you study the list, you'll see that IE presents the algorithms in decreasing order of strength, but places the shorter bit-lengths first. Why? If longer bit lengths are more secure, shouldn't they be listed first?
Remember, encryption is the thing that buys you time against Immutable Law #3. But performing encryption itself takes time. So when choosing an algorithm and a bit length, one important consideration is to ask yourself this question: "How long do I need for my secrets to remain secret?"
We configure IE to use shorter bit lengths -- but never shorter than 128 bits, except for the last two that use no encryption -- because it gives you better performance than the longer bit lengths. In almost all cases, a 128-bit key is more than sufficient to protect the information you're exchanging over HTTPS.
However, if you require something longer, and want to change the default, you can. Here's how.
- Open your group policy editor by entering gpedit.msc at a command prompt.
- Choose Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.
- There's only one item here: SSL Cipher Suite Order. Open it.
- Select Enabled.
- Now here's where you need to tread carefully. You'll see that the list is the same as above, but rather than formatted nicely with carriage returns, they're simply separated with commas. The first item in the list is:
TLS_RSA_WITH_AES_128_CBC_SHA
And the second item is:
TLS_RSA_WITH_AES_256_CBC_SHA
Cursor your way through the list. Change that first 128 to 256. Then cursor forward a bit more and change the 256 to 128. - Feel free to change other orders, too, but keep your changes within algorithm types.
- OK your way out, close the group policy editor, and reboot.
Most of you probably won't need to do this -- I haven't. But for those who have regulatory requirements for using 256-bit AES, follow these steps and you'll be compliant.
Comments
Anonymous
January 01, 2003
Azi a fost pentru mine "ziua Steve Riley", am fost la doua sesiuni de prezentari si la un "panel discussion".Anonymous
January 01, 2003
Scott-- The TLS specifications require TLS_RSA_WITH_NULL_MD5 and TLS_RSA_WITH_NULL_SHA as part of any cipher suite. Every web browser includes these in its list of offerings. It's true that they don't provide encryption, but they do provide authentication. This is useful, for instance, if an application on a server wants to authenticate the user (and, of course, authenticate the server to the user) but doesn't require the data to be encrypted. Practically, however, these never get used. Unless specifically configured, web servers won't accept these suites. Someone-- Here's the registry key where these are stored. This is from my Vista Enterprise computer. I don't have an XP home computer to verify this on, and I also don't know whether editing the registry directly for this will work, but I suspect it will: Path: HKEY_LOCAL_MACHINESystemCurrentControlSetControl
CryptographyConfigurationLocalDefault�0010002 Key: FunctionsAnonymous
January 01, 2003
Claes, I suppose you could delete from the registry the ones you didn't want your browser to use. We haven't tested this, so I can't predict how it would behave. And I don't know of any websites that would return details on which suite was chosen. If anyone else knows, please comment. Thanks.Anonymous
November 07, 2007
Dumb question.. Why does it appear that Win2k8RC0 still defaulting to SSLv2 when it sets up SSL'd web sites? Shouldn't it default to SSLv3? External PCI/DSS scan tools knock down a web site for supporting SSLv2.Anonymous
November 07, 2007
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521 P521: Is it a mistake? Perhaps it should be P512 ?Anonymous
November 07, 2007
"except for the last two that use no encryption" Uh, what? Am I missing something here? Having a fallback to a non-encrypted link when the user will surely expect the link to be encrypted seems like a Bad Thing...Anonymous
November 08, 2007
It's so much fun how this workaround is not even possible on Windows XP Home, which does not allow one to use the group policy editorAnonymous
November 08, 2007
P521 refers to a particular pseudo-random elliptic curve defined in FIPS 186. Curve P-521 is defined over the prime field GF(p) where p=2^521-1 (a prime number).Anonymous
November 14, 2007
//sample code to set TLS cipher suite on vista #include <windows.h> #include <stdio.h> #include <bcrypt.h> void main() { NTSTATUS ntStatus; PCRYPT_PROVIDER_REFS pBuffer=NULL; DWORD cbBuffer=0; //set TLS_RSA_WITH_AES_256_CBC_SHA as prefered ntStatus=BCryptAddContextFunction(CRYPT_LOCAL, NULL, NCRYPT_SCHANNEL_INTERFACE, L"TLS_RSA_WITH_AES_256_CBC_SHA", CRYPT_PRIORITY_TOP); if(ntStatus!=0) { printf("BCryptResolveProviders() failedn"); exit(-1); //will fail if TLS_RSA_WITH_AES_256_CBC_SHA already TOP } //query for prefered provider ntStatus=BCryptResolveProviders(NULL, NCRYPT_SCHANNEL_INTERFACE, NULL, NULL, CRYPT_UM, 0, &cbBuffer, &pBuffer); if(ntStatus==0) printf("prefered TLS suite = %Snreboot requiredn",pBuffer->rgpProviders[0]->pszFunction); else exit(-1); //now reboot the machine and you're good to go }Anonymous
November 24, 2007
A couple of points to make here:
- If you're concerned about compliance, you generally won't succeed by simply changing cipher order - you will need to prevent the use of the non-compliant ciphers.
- For some environments, only FIPS compliant algorithms are accepted - see article http://support.microsoft.com/kb/811833/en-us for some good information on that.
- The ciphersuite used is a negotiation between the server and the client - while you can use the group policy features above to limit what the browser will choose, it's probably better to limit what the server will offer. There are a few reasons - there are fewer servers than browsers; GPO will only limit Internet Explorer and browsers that use SChannel rather than OpenSSL; limiting browsers may prevent them from accessing remote servers.
- NULL should never be used. The only time when it's appropriate is when you are a developer, and you are experiencing SSL alerts that you think could be related to incorrectly handling the data from the SSL encryption into the network stream. Then you can watch the stream in a network capture, and see whether you have indeed messed up the data. The NULL encryption protocols should never be used for HTTPS, IMHO.
Anonymous
January 30, 2008
One question (kind of comment - lack of info ...for me): WHEN the server has chosen one of the cipher suites; WHERE can "I" as client see which one that’s active? for a particular SSL session ? Where can "I" as a client control/set the "minimum" cipher suites combination (drop SSL if lower than I need and want ?) ?Anonymous
February 02, 2008
While the "NULL" ciphers are in the list, Internet Explorer is hardcoded to refuse zero-bit ciphers. -EricLawAnonymous
December 04, 2008
please tell me how to select cipher suites in IE 6.