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.

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]".

At present, no feedback is given to users when insecure fallback to an older TLS/SSL version takes place to workaround broken TLS implementations.

This means that there is no mechanism or feedback loop for users and administrators to realise that they must patch/maintain/upgrade their servers to correct this.

Such a mechanism would be unavoidably intrusive but this is justified because insecure fallback is harmful to the security of the Web. Waiting for attrition alone to take place has not been effective so more visible behaviour is required.

A similar user interface to that which is shown when an invalid certificate is encountered would be appropriate.

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…

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.

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.

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.

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.

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

IE11 broke on my site. If you're going to disable browser detection then you need to fix all of your bugs that make you behave in non-standard ways. IE11 still behaves in non-standard ways.

In particular, if you are in a hidden iframe and call window.focus();window.print(), it will print the parent frame, not the hidden iframe. How am I supposed to print receipts and other customer data without displaying it on the screen? Displaying it on the screen is not an option.

For older versions of IE 10 and earlier, I made an UGLY 1px x 1px visible iframe and that actually will print properly. It's an ugly hack which thankfully my Firefox and Chrome users don't have to tolerate.

While you're at it, how about you guys actually port IE11 to XP and Vista so that I can just tell the customers who insist upon using IE that they need to upgrade their IE version? For many of them using Firefox or Chrome is not an option due to being in large corporate IT managed computer pools where they are stuck with XP or Vista and not allowed to install another browser for security reasons.

just updated to IE11 on my win 7 machine. ( 32 bit). Outlook client only runs on light mode. Even after un-ticking the box to say you want the regular web outlook. Possible bug / unintended feature ? Or I am being stupid …. Can we clear this up team ?