SSL, TLS and a Little ActiveX: How IE7 Strikes a Balance Between Security and Compatibility

We’ve been talking for a long time about making sure IE7 is as secure as possible but still compatible with the Internet. The principle that helps us balance security and compatibility is to not impact existing websites unless we need to change IE to help protect end users. As we asked web developers and server administrators to make changes, they spoke frankly with us about what they could and what they couldn’t change. Today, we’ll look at a couple timely examples of how this principle played out in IE7.

1. Improved security to mitigate threats may impact some web sites

SSL 2.0 deprecated

One place we faced a tough decision was with SSL 2.0. Contrary to what we expected, SSL 2.0 is still in use on a number of web servers around the world. The problem is that if a site chooses to use SSL 2.0 an attacker could decrypt a transaction between IE and a SSL 2.0 web server. We’ve never heard any reports of SSL 2.0 sites or users being exploited but we decided to keep SSL 2.0 disabled in IE7 to protect users from that threat. When we did hear of web servers running SSL 2.0, we contacted server administrators about upgrading to newer servers.

It’s important that your web server admin upgrade from SSL 2.0 if you haven’t already. If for some reason you still need to use SSL 2.0, you can ask your users to re-enable SSL 2.0 on the advanced tab of the Internet options control panel.

Obsolete controls disabled through ActiveX opt-in

An important part of the ActiveX opt-in feature is doing good housekeeping of the ActiveX controls that come with Windows.  Many sites will benefit from IE7’s new native XMLHTTP control and sites can continue to use the MSXML 6.0 and 3.0 controls. The MSXML 5.0 control will not be enabled by default. The WMP 6.4 player is also disabled because its been replaced by the WMP 7+ generation controls. As we can infer from HD Moore’s month of browser bugs, using the newer controls and leaving older controls disabled helps reduce the chances of user being exposed to a security or stability issue in an older control.

Since this should be a straightforward change for most sites, we’re asking for your help in moving your pages towards the native object XMLHTTP, the latest version of MSXML or the newer WMP control. In the best case scenario, the change might be to simply swap in the native object for XMLHTTP or the newer CLSID for the current WMP control.

2. In many cases though, we can make security features that are still compatible with today’s web applications

Warning rather than blocking for mixed content for compat with web applications

Mixed content refers to a secure page, hosted over https that also includes unsecured http content. Since the plain http content isn’t protected with encryption, browsers have to warn users about the unencrypted content because it could be hijacked rewritten by an attacker. In practice, many websites still mix http content into https pages, typically to carry non-confidential information such as logo images.

In previous Betas of IE7, we blocked the unencrypted http content outright to give users the most secure default experience, to not even make users decide if they wanted the protection. Pages with mixed content showed the information bar and the http content simply didn’t come through unless the user clicked the information bar to reload the full page. We’ve spoken with many major commercial websites and explained the problem with the user experience. As a result you should see many fewer sites hosting mixed content.

At the same time, many of today’s blog publishing packages depend on the ability to mix http content into an https-based outer page. Blocking the plain http content on page load forced the blogger to reload the page and many folks lost draft posts. Getting updated blog software isn’t an easy task and blogging is now common practice for folks who aren’t necessarily part-timing as web server admins.

Because mixed content is important for some web applications, and straightforward fixes are not always available, we made a hard decision to revert to the warning prompt for mixed content in RC1. That means your banking site, your blog software or other secure site might show a modal prompt for mixed content as they did in IE6.

The responsibility for using mixed content wisely, if needed, rests on web developers and web server admins. We still hope to address to the mixed content prompt in a future release. As TLS improves the performance and economy of HTTPS web servers, we hope the industry can move away from mixed content all together.

TLS 1.0 can fall back to SSL 3.0 for compatibility with legacy web servers

One of the new features in Windows Vista is support for TLS 1.0 extensions. Web servers that support TLS extensions open up new scenarios in HTTPS like the ability to have multiple hosts on a single server and will allow servers and clients to negotiate more secure connections with improved performance. The problem we found is that some legacy web servers will simply reject connections that include a TLS 1.0 extension. Server patches are usually available to correct this problem but those patches need to be deployed extensively and that can take time.

Rather than have end users locked out of important websites because of TLS extensions, we worked with the Windows Networking team on a simple fallback mechanism that will allow the legacy servers to keep working. In the final RTM version of Windows Vista, if the server hangs up the connection after IE sent TLS extensions, IE will simply retry the connection using SSL 3. SSL 3 remains a secure fallback and we found the workaround to be effective.  Server operators should still ensure that they are running the latest updates on their servers for best performance.

Thanks,

Rob Franco
Lead Program Manager

edit:  adjustment in title