IE11 Automatically Makes Over 40% of the Web More Secure While Making Sure Sites Continue to Work
Internet Explorer 11 is the first browser to make Internet connections more secure and reliable by reducing the use of vulnerable ciphersuites, such as RC4 and by using the latest security standards, TLS 1.2, by default. With these changes in IE11, you can have peace of mind when accessing your critical personal information on social media, banking, commerce, and other sites. These advances build on our continued work to make IE the most secure browser in key areas such as socially engineered attacks.
IE11 Reduces Use of Vulnerable RC4 Cipher Suite
IE11 takes a big step toward better security by reducing the use of the vulnerable RC4 cipher suite. RC4 is a stream cipher that is widely supported—and often preferred—by TLS servers. However, recent studies such as those by AlFardan suggest exploits in the RC4 key stream that can be used to recover some encrypted data. RC4 has other weaknesses as well, as discovered by Paul, Mantin, and Fluhrer. Based on these studies, the industry consensus is that RC4 has a variety of cryptographic weaknesses, and RC4 exploits are now practical.We have proposed changes to the TLS standard, so that other browsers and industry players can follow our lead in securing the Web.
The changes in IE11 increase security while still ensuring compatibility with the Web, in spite of the current widespread use of the RC4 cipher suite. IE11 does not offer RC4-based cipher suites during the initial TLS/SSL handshake. In this way, most connections successfully use non-RC4 cipher suites. We studied 5 million Internet sites and found that over 96% of sites can negotiate ciphers other than RC4. Notably, nearly 39% of these sites support non-RC4 even though they prefer RC4 – and for these, sites, IE11 substantially increases the security of the Web.
| Site Type | Number | Percentage | IE11’s Behavior |
| Total Sites in Sample | 5,000,000 | 100% | |
| Sites that currently use RC4 ciphers | 2,127,500 | 42.55% | |
| Sites that support non RC4 ciphers | 1,932,500 | 38.65% | IE11 makes sites more secure by negotiating non-RC4 cipher |
| Sites that only work with RC4 ciphers | 195,000 | 3.90% | IE11 ensures you can reach these sites by falling back to an RC4 cipher |
| Sites that currently do not use RC4 ciphers | 2,872,500 | 57.45% | IE11 continues to negotiate non-RC4 ciphers with these sites |
A study of 5 million Internet sites shows that IE11 automatically increases security for 39% of sites without affecting compatibility
For the rare cases where the browser cannot negotiate a non-RC4 cipher suite with the server, IE11 falls back to negotiating TLS 1.0 or SSL 3.0 with RC4 to ensure that you can still reach the sites you need. Microsoft is actively working with many of these sites to enable support for non-RC4 cipher suites.
Turning on TLS 1.2 by Default
IE11 further increases Web security by enabling TLS version 1.2 by default, building on IE’s leadership as the first browser to implement TLS 1.2 as an optional setting in IE8. You can access sites such as Outlook.com, Facebook, etc. using industry-leading security standards thereby keeping your personal information safe. TLS 1.2 increases security by supporting more advanced cryptographic suites. Most of the practical exploits that target TLS 1.0 and TLS 1.1 ciphers do not work on TLS 1.2 ciphers. For example, TLS 1.2 is not subject to the BEAST attack.
In IE11, you can take the advantage of added security in TLS 1.2 while getting the same performance provided with RC4 ciphers. TLS 1.2 provides new cipher suites that provide strong security and high performance. For example, the AES-GCM cipher suite is supported only on TLS 1.2 and performs just as well as RC4 ciphers. By enabling TLS 1.2 with AES-GCM, sites can provide strong security without introducing additional server load.
Tuning on TLS 1.2 out of the box in IE11 automatically increases the security level with nearly 16% of Web servers and this number should increase as additional servers and browsers begin to support and prefer TLS 1.2. Windows Server has supported TLS 1.2 since Windows Server 2008 R2 and we encourage servers to enable TLS 1.2 in IIS, which is a simple configuration change. Servers such as Apache also support TLS 1.2, and as the industry moves forward, other Web servers will support TLS 1.2 in the future as well. The change does not affect compatibility with existing servers, which down-negotiate TLS to the highest mutually-supported version. By default, IE11 supports TLS 1.2, TLS 1.1, TLS 1.0 and SSL 3.0.
Conclusion
IE11 makes 39% of Web sites more secure by discouraging the use of vulnerable RC4 based cipher suites and increases security on 16% of Web sites by negotiating TLS 1.2, the most secure version of TLS.
Try out IE11 to experience more secure browsing that uses the latest industry standards. We look forward to hearing your feedback via Connect, to help us move the industry forward and continue to enhance the browser.
Hasnat Naveed and Ritika Kapadia
Program Managers in Windows and Internet Explorer
Comments
Anonymous
November 12, 2013
As long as fallback to a less secure TLS version is possible I wouldn't call it "increases security", at most it would be something along the lines of "paving a path for more security in the future [once TLS < 1.2 support can be retired]".Anonymous
November 12, 2013
Can I know non-RC4 connection to specific sites ? I want to know which sites can connect by non-RC4 by using Internet Explorer 11.Anonymous
November 12, 2013
The comment has been removedAnonymous
November 12, 2013
The comment has been removedAnonymous
November 12, 2013
Breddo: You're right that fallbacks aren't great, but defeating passive attackers and forcing them to become active attackers (to cause protocol downgrades) is a step in the right direction.Anonymous
November 12, 2013
As SCHANNEL will not negotiate AES based cipher suites over SSL 3, there is often a downgrade attack to RC4 when fallback takes place. Such fallback should really not take place silently. With appropriate error text, which explains the 'arcana' and that it is a fault with the server, broken deployments would relatively quickly get mopped up. By offering a continue mechanism, compatibility is maintained. When you're the NSA or GCHQ, such active attacks don't seem too difficult to pull off...Anonymous
November 12, 2013
I certainly agree that being "intrusive" when connecting to a server that requires RC4 is overkill and a bad user experience. But wasn't Yoshihiro Kawabata simply asking if there was an easy way for IE11 to tell a power user what cipher suite was used? For example, maybe clicking the padlock could have details, although that icon goes away with mixed content. Perhaps there is or should be an elegant way to view that information from the Networking tab of the F12 dev tools. I don't see such information, but it would seem like a neat feature that I'd probably rarely or never use.Anonymous
November 12, 2013
Stephen, you've misunderstood. That is not being proposed. The protocol is different to the actual ciphersuite being negotiated within it. No warning would be shown when RC4 is negotiated assuming that the TLS implementation is not broken with regards to future handshakes, in volation of the specification for the version they implement.Anonymous
November 12, 2013
Is forward secrecy ever going to be supported with AES-GCM and RSA certificates in SCHANNEL? Currently only ECDSA is supported, which almost no certificate authorities offer.Anonymous
November 12, 2013
@Jeff: ECDHE is supported with RSA certificates in newer versions of SChannel. Plain DHE was never supported.Anonymous
November 12, 2013
Nick: The notion that "broken deployments would relatively quickly get mopped up" is unfortunately nothing but wishful thinking. The prevalence of mixed content warnings on real world content, 17 years after the warnings were introduced provides an instructive example. If you're the NSA or GCHQ, you can trivially order a CA to give you a root certificate, or compromise any of the hundreds of CAs that are trusted by the system. Or perform any of hundreds of other attacks. Stephen: Right-click the page. Choose Properties. The HTTPS information is shown in the CONNECTION field. Alternatively, use Fiddler to examine the HTTP CONNECT tunnel.Anonymous
November 12, 2013
The comment has been removedAnonymous
November 12, 2013
Eric, I completely, utterly disagree. The mixed content warning is too soft as it is easily dismissed and doesn't actually explain in the message what the problem is or its severity. It is for that reason that all these years later, nothing has been done. All it actually shows is that attrition does not work over 17 years when you don't have an appropriate response.Anonymous
November 12, 2013
I check Connection of some web sites by Internet Explorer 11 on Windows 7. TLS 1.0, RC4/128bit; RSA/2048bit = social.technet.microsoft.com TLS 1.0, RC4/128bit; RSA/2048bit = www.amazon.com TLS 1.0, AES/128bit; RSA/2048bit = skydrive.live.com TLS 1.0, AES/128bit; RSA/2048bit = login.live.com TLS 1.2, AES/128bit; ECDH_P256/256bit = www.facebook.com TLS 1.2, AES/128bit; ECDH_P256/256bit = www.twitter.com TLS 1.2, AES/128bit; RSA/2048bit = account.windowsazure.com TLS 1.2, AES/128bit; RSA/2048bit = www.nokia.comAnonymous
November 12, 2013
The comment has been removedAnonymous
November 13, 2013
@Yuhong The current list I have does not show them listed. "Cipher Suites in Schannel" at: msdn.microsoft.com/.../aa374757(v=vs.85).aspxAnonymous
November 13, 2013
@EricLaw Awesome! I knew Wireshark or Fiddler would get the job done, but right clicking is exactly the sort of thing I was wondering about. Thanks!Anonymous
November 13, 2013
More secure becomes more looser...Anonymous
November 13, 2013
According to the "How to Completely Disable RC4" section of the security advisory at blogs.technet.com/.../security-advisory-2868725-recommendation-to-disable-rc4.aspx the fallback to RC4 can be disabled by adding registry keys/values. Is that correct? ThanksAnonymous
November 14, 2013
@Manfred: You could test and verify (Fiddler will show you ALL of the ciphers offered to the server) but yes, I'd expect that if you disable RC4 in SChannel, it would never be offered, regardless of client.Anonymous
November 14, 2013
The comment has been removedAnonymous
November 14, 2013
@Jeff: Here's what IE11 on Windows 8.1 offers by default: A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below. Version: 3.3 (TLS/1.2) Extensions: renegotiation_info 00 server_name fiddler2.com status_request 01 00 00 00 00 elliptic_curves 00 04 00 17 00 18 ec_point_formats 01 00 signature_algorithms 00 0E 04 01 05 01 02 01 04 03 05 03 02 03 02 02 SessionTicket TLS empty ALPN spdy/3; http/1.1; NextProtocolNegotiation empty Ciphers: [003C] TLS_RSA_WITH_AES_128_CBC_SHA256 [002F] TLS_RSA_AES_128_SHA [003D] TLS_RSA_WITH_AES_256_CBC_SHA256 [0035] TLS_RSA_AES_256_SHA [0005] SSL_RSA_WITH_RC4_128_SHA [000A] SSL_RSA_WITH_3DES_EDE_SHA [C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 [C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA [C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA [C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 [C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 [C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 [C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA [C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA [0040] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 [0032] TLS_DHE_DSS_WITH_AES_128_SHA [006A] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 [0038] TLS_DHE_DSS_WITH_AES_256_SHA [0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA [0004] SSL_RSA_WITH_RC4_128_MD5 Compression: [00] NO_COMPRESSIONAnonymous
November 14, 2013
The comment has been removedAnonymous
November 14, 2013
@Jeff: But yes I complained to Marsh Ray of MS about not having any AES-GCM RSA suites listed.Anonymous
November 14, 2013
The comment has been removedAnonymous
November 15, 2013
@EricLaw @Yuhong That was my point. MS is promoting GCM use in TLS 1.2, but they don't offer a way to use it with RSA and forward secrecy. DSA is nice an all, but only a couple of CAs offer it.