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:


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.

  1. Open your group policy editor by entering gpedit.msc at a command prompt.
  2. Choose Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.
  3. There's only one item here: SSL Cipher Suite Order. Open it.
  4. Select Enabled.
  5. 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:
    And the second item is:
    Cursor your way through the list. Change that first 128 to 256. Then cursor forward a bit more and change the 256 to 128.
  6. Feel free to change other orders, too, but keep your changes within algorithm types.
  7. 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 (13)
  1. Anonymous says:

    Azi a fost pentru mine "ziua Steve Riley", am fost la doua sesiuni de prezentari si la un "panel discussion".

  2. Anonymous says:

    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

    Key: Functions

  3. Anonymous says:

    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.

  4. susan says:

    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.

  5. Rafal says:


    P521: Is it a mistake? Perhaps it should be P512 ?

  6. Scott says:

    "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…

  7. anony.muos says:

    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 editor

  8. cryptoguy says:

    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).  

  9. api says:

    //sample code to set TLS cipher suite on vista

    #include <windows.h>

    #include <stdio.h>

    #include <bcrypt.h>

    void main()


    NTSTATUS ntStatus;


    DWORD cbBuffer=0;

    //set TLS_RSA_WITH_AES_256_CBC_SHA as prefered








    printf("BCryptResolveProviders() failedn");


    //will fail if TLS_RSA_WITH_AES_256_CBC_SHA already TOP


    //query for prefered provider







    &cbBuffer, &pBuffer);


    printf("prefered TLS suite = %Snreboot requiredn",pBuffer->rgpProviders[0]->pszFunction);



    //now reboot the machine and you’re good to go


  10. Alun Jones says:

    A couple of points to make here:

    1. 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.

    2. For some environments, only FIPS compliant algorithms are accepted – see article for some good information on that.

    3. 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.

    4. 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.

  11. Claes says:

    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 ?) ?

  12. EricLaw [MSFT] says:

    While the "NULL" ciphers are in the list, Internet Explorer is hardcoded to refuse zero-bit ciphers.


  13. vimal says:

    please tell me how to select cipher suites in IE 6.

Comments are closed.

Skip to main content