Changing IE's SSL cipher order

IE11 is the first major browser that supports AES-GCM cipher suites and has them enabled by default in a stable/release version. I thought that AES-GCM was new in IE11, but I just came across a site that shows that IE already supported the ciphers at least in IE9 in 2011: http://sim.ivi.co/2011/07/internet-explorer-preference-of-tls.html
Because AES-GCM is a TLS 1.2 ciphersuite, it only enables if you enable TLS 1.2 manually, and only since IE11 is it enabled by default.
I also came across a way to change IE's cipher order, which can be quite handy. Normally the used SSL cipher determined by the server and only a small percentage has no cipher-preference, which means the browser determines the used cipher. However with sites that support AES-GCM ciphers, I found that the percentage of servers having no cipher prefence is actually quite high, and IE's default cipher order is not determined by strength, so changing the default order is a good way to improve security on some sites.

You can edit the default order by launching gpedit.msc -> Computer Configuration -> Administrative Templates -> Network -> SSL Configuration Settings. Open SSL Cipher Suite Order and set it to Enabled. UPDATE: See post #5 if you have a version of Windows that doesn't have Group Policy Editor.
Here is my edited order:

Code:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_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_SHA256
TLS_RSA_WITH_NULL_SHA

If you have any suggestions for improvement please let me know. Also, I wasn't sure whether to prefer DHE_DSS ciphers or plain RSA ones. Normally DHE supports Forward Secrecy, but here's a quote from SSLlabs on DHE_DSS:

Below is the proper format, you can copy/paste it if you like.

Code:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_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_SHA256,TLS_RSA_WITH_NULL_SHA

Keep in mind that you need to reboot before the new order becomes enabled.
EDIT: after reboot, you can confirm if it worked by checking out the new order here: https://www.ssllabs.com/ssltest/viewMyClient.html
EDIT2: If this is all too technical for you, here is a nice explanation: http://blog.cloudflare.com/staying-on-top-of-tls-attacks

 

Wow didn't even know this was possible or that they added it in IE9... thanks for the post. Good to know that I can just enable TLS 1.2 for Windows 7 users and they already have GCM.

 

Yes, I didn't know either before this. I don't know about IE11, as I'm still on 10, but 10 only supports the ECDHE_ECDSA variants, I've also seen websites with RSA, DHE_RSA and ECDHE_RSA variants that don't support the ECDHE_ECDSA variants, so if IE11 doesn't support those, I hope they soon will add support.
Update: it was even in IE8:

http://www.carbonwind.net/blog/post...rowsers-and-their-SSLTLS-implementations.aspx

 

Is there a way to do this in Windows 7 Home Premium without the group policy editor?

 

I didn't think so but I just found a nice website that shows corresponding registry keys for everything in Group Policy Editor
http://gpsearch.azurewebsites.net/default.aspx?ref=1#58

Go to HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002 -> Create a new String Value and name it Functions -> Right-click modify and paste your desired cipher order in the proper formatting(the same as with gpedit.msc, all cipersuites in a single long line, separated by commas and NO spaces.)

 

Ah, I have a project Will I essentially accomplish the same thing by installing IE 11?

 

I installed IE 11 release preview for Win7, but the cipher order was still the same as with IE 10.

 

Thanks. I'll probably just continue using Firefox for "transactions" and avoid IE's limitations.

 

Limitations? It's way ahead of Firefox in regards to TLS protocol support, and a little bit better than Chrome in regards to cypher support. What limitations do you speak of?

Not that it guarantees the website you're using will support them, you need to check that yourself.

 

BoerenkoolMetWorst said:

Normally the used SSL cipher determined by the server and only a small percentage has no cipher-preference, which means the browser determines the used cipher. However with sites that support AES-GCM ciphers, I found that the percentage of servers having no cipher prefence is actually quite high, and IE's default cipher order is not determined by strength, so changing the default order is a good way to improve security on some sites.


If I'm understanding this IE doesn't present the ciphers in optimal order. In other words if the website doesn't prioritize and it falls to the browser to choose the cipher then it may wind up that a less secure protocol is used. I believe that is why BoerenkoolMetWorst suggested that the ciphers be reordered for IE. If I'm not understanding then please clarify.

As to IE being ahead of Firefox I'm not sure how that's the case. FF25 supports TLS 1.2. Granted it's not the default, but it can easily be made the default, plus there are quite a few extensions that can be added to FF, such as Calomel SSL Validator, that provide a lot of feedback where as one knows nothing when using IE.

 

It's nothing to do with optimal, it's user preference. Also, this list will affect 1% of websites on the internet, probably less. Nearly all websites set their own preferred list. This tweak is really for fun/power users.

It FINALLY supports TLS 1.2 in an off-by-default manner because it isn't finished, it also doesn't support any of the high end cyphers IE supports, which are being discussed in this thread, such as GCM.

As it stands right now, using IE will yield the strongest TLS security of any browser on the market when browsing Google websites, as you can see from Googles list here. This needs to be checked on a site-by-site basis. But because Google implements and prioritizes ECDSA GCM cyphers (a good thing), IE8-IE11 on Windows 7 or Windows 8 with TLS 1.2 enabled will provide the most security.

 

elapsed is correct and the sites I was talking about with a high percentage of no cipher preference are sites supporting the new AES-GCM, which Firefox doesn't support anyway.

 

Well, thanks to you and Elapsed for clarifying

Can you and/or Elapsed say more about TLS 1.2 support being "unfinished" in Firefox 25? Is it just that AES-GCM hasn't been implemented, or are there other issues? Will it be finished in v26 and will the AES-GCM ciphers be included?

 

I don't think anyone can answer that for you other than developers.

 

You specifically said TLS 1.2 was unfinished in FF v25 - what did you mean?

 

You can visit the bugtracker if you're curious, there's a reason it's not on by default.

 

Can you kindly link to the bugtracker where there is more information about why TLS 1.2 is not on by default?

 

Perhaps it can be found here:
https://bugzilla.mozilla.org/show_bug.cgi?id=861266

 

That was a very interesting read, thank you. It sounds like they're getting close RE TLS 1.2 default "ON". It's pretty complex behind the scenes.

 

You cannot copy&paste this string, because the Group Policy Editor only allows 1023 chars:

http://f.666kb.com/i/ck2q5yf7a7uh1y3ax.png

So when pasting your recommended string you would truncate "TLS_RSA_WITH_NULL_SHA".

I would recommended the following changes: Remove any RC4 cipher from the list, e.g use

Code:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,SSL_CK_DES_192_EDE3_CBC_WITH_MD5,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA

 

Thanks for pointing that out, though in this case is doesn't matter much really since Null ciphers aren't really encryption, it would be best to remove those as well.
https://en.wikipedia.org/wiki/Null_cipher

Removing RC4 ciphers is a good idea as well, there are still quite a few sites with no AES ciphers, but they usually still support 3DES so you can still connect to those sites.(And I read that 3DES is still more secure than RC4, the reason it is used so little is because it uses more resources than RC4 and AES.)

There may be a few sites that only support RC4 though, so I wouldn't recommend removing it for the average Joe. MS removed RC4 from IE11 in Windows 8.1, but they turned it on again later because of broken sites. I don't know however if 3DES was still enabled when they removed it.

Perhaps it's also good to remove the ciphers with CK as authentication instead of RSA, but I can't find much info on CK.

I just also noticed some peculiarities about IE's Cipher support, as you know they still support RC4, but only the RSA ones, not the versions with Forward Secrecy.
And with AES-GCM, they only support the one with elliptic curves ECDHE_ECDSA, but not ECDHE_RSA, DHE_RSA or just plain RSA(though that one is reasonable.)

I can't seem to edit my first post anymore so here I have my original list with a few changes:
-Null ciphers removed
-Ciphers with CK authentication removed
-In the original list 3DES was preferred over RC4 with MD5, but not over RC4 with SHA1, so now it is preferred over both RC4 variants.

Code:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_RC4_128_MD5

And also a version with RC4 removed as well:

Code:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA

 

What are the chances that a massively talented person (such as yourself) could incorporate all of this into a .REG file so that the changes could be easily imported/implemented into the registry?

 

To clarify for the not so technical users here; When connecting to a secure HTTPS website, the used protocol for encryption and authentication is usually chosen by the server, but in some cases the server has no preference. In that case the protocol is chosen according to the preference of the browser. The tweak in this thread makes sure the most secure protocol available is being used by changing the browser preference.

Thanks for the compliment I actually never created a .REG file, but I found there is a very easy way: just go to the registry key you want a .REG file for, and click Export
I have attached the files to this post, but you have to change the extension, because Wilders doesn't allow to attach .reg files.

 

Thx, cool you managed the reg file

 

Many thanks for the files BMW After renaming and importing I went to the Qualys SSL client test. This is the result:



SSL Labs logo

Home Qualys.com Projects Contact

You are here: Home > Projects > SSL Client Test

SSL/TLS Capabilities of Your Browser (Experimental)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko

Details

Protocols*

TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 Yes
SSL 2 No
(*) This test reliably detects only the highest supported protocol.

Cipher Suites (in order of preference)

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Forward Secrecy 256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Forward Secrecy 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Forward Secrecy 256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Forward Secrecy 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Forward Secrecy 128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x6a) Forward Secrecy* 256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x3 Forward Secrecy* 256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x40) Forward Secrecy* 128
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) Forward Secrecy* 128
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) Forward Secrecy* 168
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
(*) Cannot be used for Forward Secrecy because they require DSS keys, which are effectively limited to 1024 bits.

Protocol Details

Server Name Indication (SNI) Yes
Secure Renegotiation Yes
TLS compression No
Session tickets No
OCSP stapling Yes
Signature algorithms SHA256/RSA, SHA384/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA, SHA1/ECDSA, SHA1/DSA
Elliptic curves secp384r1, secp256r1
Next Protocol Negotiation No
Application Layer Protocol Negotiation No
Handshake format SSL 3+



Does this jive with the imported data? And I wonder why the test shows SSL 3.0 supported when I have it disabled in the Internet Options?