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 (26)

  1. Anonymous says:

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

  2. Anonymous says:

    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.

  3. Anonymous says:

    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.

  4. Nick: "Unavoidably intrusive" is absolutely not justified unless there's a high degree of confidence that a user is under attack.

    Nagging millions of end-users with crypto arcana is NOT the way to move the web forward (and a great way to keep users on less-secure browsers).

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

  6. Anonymous says:

    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…

  7. Anonymous says:

    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.

  8. Anonymous says:

    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.

  9. Anonymous says:

    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.

  10. Yuhong Bao says:

    @Jeff: ECDHE is supported with RSA certificates in newer versions of SChannel. Plain DHE was never supported.

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

  12. Anonymous says:

    to MSFT ie and network designers, please:

    1 add socks5 and dns over socks feature

    2 enhance tpl to surport any ulr blocking not just third party url and provide better UX on management

  13. Anonymous says:

    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.

  14. Anonymous says:

    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 = http://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 = http://www.facebook.com

    TLS 1.2, AES/128bit; ECDH_P256/256bit = http://www.twitter.com

    TLS 1.2, AES/128bit; RSA/2048bit = account.windowsazure.com

    TLS 1.2, AES/128bit; RSA/2048bit = http://www.nokia.com

  15. Anonymous says:

    @Yoshihiro – so basically it keeps secure users on secure sites secure… but on 3/4 Microsoft sites it really doesn't matter because Microsoft doesn't support TLS 1.2 anyway.

    I think what would be better is if an iframe to a 3rd party is not on a high level of TLS, then apply a pink hue to that iframe to warn users that there might be security issues.

  16. Anonymous says:

    @Yuhong The current list I have does not show them listed. "Cipher Suites in Schannel" at:

    msdn.microsoft.com/…/aa374757(v=vs.85).aspx

  17. Anonymous says:

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

  18. Anonymous says:

    More secure becomes more looser…

  19. Anonymous says:

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

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

  21. Here's a great post on the practicality of current attacks against HTTPS ciphers: googleonlinesecurity.blogspot.co.uk/…/a-roster-of-tls-cipher-suites-weaknesses.html

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

  23. Anonymous says:

    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.

  24. Yuhong Bao says:

    @Jeff: But yes I complained to Marsh Ray of MS about not having *any* AES-GCM RSA suites listed.

  25. Anonymous says:

    Hi,

    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 ?

    Otherwise great product… No other hiccups so far.

    Nalin.

  26. Anonymous says:

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