Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2

Artikkeli
10/22/2005

In the past, we’ve called upon website operators to ensure they are using HTTPS securely. This time, I’d like to tell you about the changes IE7 has made to improve the security and user experience for HTTPS connections.

Safer Protocol Defaults

HTTPS uses encryption to secure your Internet traffic to protect it from snooping or tampering by others on the network. HTTPS uses either the Secure Sockets Layer (SSL) or the Transport Layer Security (TLS) protocols to protect data.

For Internet Explorer 7, the default HTTPS protocol settings will be changed to disable the weaker SSLv2 protocol and to enable the stronger TLSv1 protocol. (Users of IE6 can manually configure these stronger settings by using Internet Explorer’s Tools | Internet Options | Advanced menu.) Hence, by default, IE7 users will negotiate HTTPS connections using SSLv3 or TLSv1.

Generally, IE users will not notice any difference in the user-experience due to this change; it’s a silent improvement in security. Our research indicates that there are only a handful of sites left on the Internet that require SSLv2. Adding support for SSLv3 or TLSv1 to a website is generally a simple configuration change. On a secure site, you can examine what protocol is in use by clicking Properties on the File menu. Alternatively, you can use Microsoft Fiddler’s “Capture HTTPS CONNECTs” option to view a complete listing of which protocols and encryption algorithms your browser offers and which the server chooses.

User Experience changes

Whenever IE6 encountered a problem with a HTTPS-delivered webpage, the user was informed via a modal dialog box and was asked to make a security decision. IE7 follows the XPSP2 “secure by default” paradigm by defaulting to the secure behavior.

Most importantly, IE7 will block navigation to HTTPS sites that present a digital certificate that has any of the following problems:

Certificate was issued to a hostname other than the current URL’s hostname
Certificate was issued by an untrusted root
Certificate is expired
Certificate is revoked

Upon encountering a certificate problem, IE7 presents an error page that explains the problem with the digital certificate. The user may choose to ignore the warning and proceed in spite of the certificate error (unless the certificate was revoked). If the user clicks through a certificate error page, the address bar will floodfill with red to serve as a persistent notification of the problem.

In addition, users will no longer see the so-called Mixed-Content prompt, which read: This page contains both secure and nonsecure items. Do you want to see the nonsecure items? IE7 renders only the secure content and offers the user the opportunity to unblock the nonsecure content using the Information Bar. This is an important change because very few users (or web developers) fully understand the security risks of rendering HTTP-delivered content within a HTTPS page.

Improvements on Windows Vista

The new Windows Vista platform offers several HTTPS improvements above and beyond what is mentioned above.

First, Windows Vista includes several new cryptographic algorithms for HTTPS communications, including the Advanced Encryption Standard outlined in RFC3268. AES is a strong, efficient algorithm that offers support for key lengths of up to 256 bits.

Next, certificate revocation checking is enabled by default in Windows Vista. Revocation checking enables a Certification Authority to later revoke a digital certificate which was issued in error or used fraudulently. The performance of certificate revocation checking is enhanced thanks to support for OCSP (Online Certificate Status Protocol) which enables lightweight lookups.

Lastly, the TLS implementation has been updated to support Extensions as described in RFC 3546. TLS extensions improve performance, and add capabilities to the TLS protocol. The most interesting of the extensions is the Server Name Indication (SNI) extension, as it resolves one of the long-standing limitations for HTTPS hosting.

A little background: When a web browser initiates a HTTPS handshake with a web server, the server immediately sends down a digital certificate. The hostname of the server is listed inside the digital certificate, and the browser compares it to the hostname it was attempting to reach. If these hostnames do not match, the browser raises an error.

The matching-hostnames requirement causes a problem if a single-IP is configured to host multiple sites (sometimes known as “virtual-hosting”). Ordinarily, a virtual-hosting server examines the HTTP Host request header to determine what HTTP content to return. However, in the HTTPS case, the server must provide a digital certificate before it receives the HTTP headers from the browser. SNI resolves this problem by listing the target server’s hostname in the SNI extension field of the initial client handshake with the secure server. A virtual-hosting server may examine the SNI extension to determine which digital certificate to send back to the client.

TLS Extensions are a powerful, standards-compliant feature of the TLS protocol. Compatibility should be guaranteed by the RFC requirement that unknown TLS extensions must simply be ignored. Unfortunately, anecdotal data indicates that some TLS servers in the wild are not RFC-compliant and immediately fail the connection when TLS extensions are present.

The Internet Explorer team and others are working to evangelize compliance with the TLS specification to help ensure a smooth experience when using TLS Extensions in Windows Vista.

Call to Action

If your site requires SSLv2, please reconfigure it to permit SSLv3 or TLSv1 connections.
Ensure that the hostnames used for your secure pages exactly match the hostname in your digital certificate. For example, using the certificate for www.example.com on secure.example.com will result in an error page.
If your site supports TLS, please ensure that it has a standards-compliant implementation of TLS that does not fail when extensions are present. Testing for a non-compliant TLS server is as simple as navigating to any HTTPS page on the server using IE7 on Vista Beta 2. If IE7 fails to connect, TLS extensions are the most likely culprit.

Thanks for your help in securing the Web!

- Eric Lawrence

Comments

Anonymous
January 01, 2003

"IE7 will block navigation to HTTPS sites that present a digital certificate that has any of the following problems..."

Clarification requested: will this automatic action block by default navigation to the more explanatory and specific aid screen that a secure site may already have for that situation?

Brett Merkey
Anonymous
January 01, 2003
Security problems? Just get Firefox instead. Or Opera, or any of the other secure browsers!

When will we get yellow address bars when viewing a HTTPS site (like with Firefox)?
Anonymous
January 01, 2003
Something that is actually good in that all the major browsers agree to scrap support for SSL-2. See also http://wiki.mozilla.org/Necko:SSL_v2_Sites which addresses Mozilla's concern about disabling SSL-2 and a link to Opera's post about the same thing.
Anonymous
January 01, 2003
"very few users (or web developers) fully understand the security risks of rendering HTTP-delivered content within a HTTPS page."

Please elaborate... what are the risks?

Also I'd like to point out that many people are mistakenly under the impression that the page you put your information into needs to be secure. This is not the case, in fact only the page that the form is posted to needs to be secure. In other words, there is no need to encrypt the HTML form that is initially passed to your browser, you only need to encrypt your response from that form back to the server.
Anonymous
January 01, 2003
greg,

Take a look at the post that Eric links to in the first sentence of this post ("using HTTPS securely"). It addresses exactly those two issues.
Anonymous
January 01, 2003
It would be great if you could finally get MSIE to consider "about:blank" as secure (or at least not unsecure) items. I believe this is the main reason for "This page contains both secure and unsecure items" message being displayed.

Today I overcome this issue by creating a zero-length "empty.htm" which unfortunately causes an unnecessary (and sometimes quite costly) round-trip to the server.

Jarek
Anonymous
January 01, 2003
What if IE came out as a totally new browser? With a totally new GUI?

<a href="http://r2000.blogspot.com">R2000</a>
<a href="http://nybathrooms.blogpsot.com">Bathroom Review</a>
Anonymous
January 01, 2003
This is one of the best decisions taken to date regarding security in IE - it's about time. As Frank F pointed out above, Mozilla and Opera have already decided to disable support for SSL v2 in their browsers. Since IE is still the controlling majority in terms of usage, a swtch to SL v3 will make all those still using v2 upgrade or face complaints from IE7 users - a win-win situation.
Anonymous
January 01, 2003
@greg: you're totally wrong. If form is sent using non-secure protocol, attacker can modify form and make it leak data to him.
Same with non-secure items. They can be hacked and used to inject malicious code to trusted site.

About TLS Extensions - Great! Opera Software tried to introduce support for TLS1.1+Extensions long ago, but they've found out that (too) many sites have broken implementations. I hope Microsoft's evangelization will have stronger effect.
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
My worry is that these changes are sufficiently intrusive (and involve the software saying "You're too gullible to make your own decisions") that they'll negatively impact the user experience. Let's face it, those Mixed-Content scenarios are very common, including if memory serves correctly some Microsoft forms: do you not risk taking something that's an annoyance and making it into a major pain in the neck?
I'm unconvinced that the solution to security problems with IE is to make it as annoying as Outlook.
At least make these options configurable so that people who don't need nannying (or choose to forgo some of it) can avoid the nuisance aspect.
Anonymous
January 01, 2003
<<do you not risk taking something that's an annoyance and making it into a major pain in the neck?>>

IE7 will help keep the user secure and will ensure that the right security decisions are made.

As noted previously, a properly configured secure website will not see any change in the user-experience in IE7. Only sites which put the user's data at risk will find that Internet Explorer 7 warns the user about the problems.

As it turns out, for the mixed-content case, IE7 is ~less~ annoying than IE6, because by default, the user need not interact with a modal dialog which asks them to make a decision about whether or not to render insecure content. Instead, they see the page immediately. If there are missing elements that the user actually need to see (at the cost of making the data on the page non-secure) then they may do so using the Information Bar. As it happens, ~many~ instances of the mixed-content prompt are due to shopping sites that put insecure metrics-tracking scripts/images on their checkout pages.
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
MS asking us to use standards-compliant implementation of TLS.

LOL. You've put a smile on my face :-)
Anonymous
January 01, 2003
All I see is more elaborate warning messages and more people thinking the internet is trying to steal their identity and money.

"# Certificate was issued to a hostname other than the current URL’s hostname
# Certificate was issued by an untrusted root"

Most people wouldn't have a clue what this means. I would like to see warning messages that make sense for a change.
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
Hi Eric, thanks for the post on the phising issue, even if my InforCard question did go totally ignored once again - I'll refrain for mentioning the politician style selective answering of the question, lol. But seriously, what you said on the phising filter has helped put my mind at ease.
Look forward to all future posts and blog updates.
Thanks.
Anonymous
January 01, 2003
Hi Eric,

Call to Action, point 2. states : -
"Ensure that the hostnames used for your secure pages exactly match the hostname in your digital certificate. For example, using the certificate for www.example.com on secure.example.com will result in an error page. "

Will IE 7 continue support for wildcarded hostnames (RFC2595 2.4 Server Identity Check) in digital certificates, e.g. hostname for secure page = www.example.com, hostname in certificate = .example.com (or even w.example.com)?
IE 6 supports this on XP and on Win 2000 (with patch, see http://support.microsoft.com/kb/q258858/).

Thanks
Anonymous
January 01, 2003
<<even if my InforCard question did go totally ignored once again >>

My mistake. I should have mentioned that I don't know anything about InfoCard support, as that is outside my area of expertise.

<<Will IE 7 continue support for wildcarded hostnames (RFC2595 2.4 Server Identity Check) in digital certificates>>

Yes, absolutely.
Anonymous
January 01, 2003
Thanks Eric, that was all I was really looking for and sorry if I sounded a little of hand in my last comment, but it was meant in the best possible humour :).
P.S I really hope that last icon meant a smile, because I'm still a little new to all this and don't quite know all the lingo, or icons yet - lol is really about all I do know, lol.
Anonymous
January 01, 2003
A better explanation to users what a secure page is may be a good too. This explanation should be shown per user for each new secure site.

mailto:abef@sbate.com
Anonymous
January 01, 2003
<<But probably the best solution in the long term would be to enroll the Microsoft CA in the Firefox recognized CAs database.>>

Frenk-- I spoke to some folks over at the Mozilla foundation and in the security group here at Microsoft and learned what is going wrong. As it turns out, this is caused by a server misconfiguration & a Firefox design decision.

These servers' certificates are chained to a trusted root, but they do not have the Intermediate CA certificates installed on the server. For IE, this isn't a problem because IE uses the Authority Information Access extension in the server certificate to download the Intermediate CA certs, and those certs chain to the trusted third-party root.

Firefox doesn't support the Authority Information Access lookup (https://bugzilla.mozilla.org/show_bug.cgi?id=245609) and hence it doesn't discover the path to the trusted root, hence this dialog is presented.

I'll be working with the site owners to ensure that their configuration supports both IE and Firefox.
Anonymous
January 01, 2003
> Firefox doesn't support the Authority Information Access lookup

This is forgivable. The bug you cite in turn cites an RFC:

RFC 2459 4.2.2.1
"This extension may be included in subject or CA certificates, and it MUST be non-critical."

The Authority Information Access extension is also not one of the required extensions... or even one of the recommended extensions... for applications to claim support for RFC 2459. (See the RFC, intro to 4.2)

Why doesn't the server (IIS 6 according to the headers) include the intermediate certificates? Is this an accidental optimization for Internet Explorer?
Anonymous
January 01, 2003
Maurits: Yup, as noted this is both a Firefox design decision (not a bug) and a server misconfiguration on Microsoft's part.

The simplest fix is to configure IIS to send correct intermediate certificates. I've requested that the server teams make this change.

Thanks!
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
ielmazi: As I do not own crypto in Windows, I'm not permitted to say one way or another. I'll ask the folks who own Crypto for a statement.

I can say that Microsoft is aware of the NSA Suite B requirement.
Anonymous
January 01, 2003
ielmazi: I've asked the crypto team and this was their response:

At this time, Microsoft does not have a statement around support for Suite B in the TLS-APIs.

Vista's support for Suite B algorithms in the CNG (Next Generation Crypto) API was announced at the PDC earlier this year.
Anonymous
January 01, 2003
>there are only a handful of sites left on the Internet that require SSLv2

I ran one of those sites until earlier this year. It should be made clear that this was done due to IE's problems. Around Win95 or the first Win98, IE had problem with any SSL site that had SSLv3 enabled, even if the server supported both SSLv2 and SSLv3. It will fail on SSL handshake and show blank page. Only solution was to disable to advertise SSLv3 capability completely to make it work on those broken IE browsers.
Anonymous
January 01, 2003
JBurger-- Interesting. If you have any KB articles describing this, I'd like to see them purely for historical interest.

As it happens, the SSL handshake process is such that the client indicates to the server what SSL version it supports, and the server chooses a version in its reply. (Hence the client advertises its version, and the server merely chooses the highest version it can use <= the client's advertised version).

Our database does note a number of long-ago fixed bugs where some web servers would break when IE offered to perform SSLv3 because the servers were expecting to see only SSLv2 offered.

While such servers were fixed long ago to correctly handle SSLv3, unfortunately similar issues live on. If you follow the Opera blogs, you'll note that there is a "hall of shame" of servers which break when the client advertises support for TLSv1.1. The problem is that these servers never expected to see a handshake version higher than 3.1 (which is TLSv1).

IE has offered SSLv3 by default since at least IE5.0.

Thanks!
Anonymous
January 01, 2003
How to repro:

1) Install google toolbar
2) Open one blank tab in IE7
3) Open another blank tab in IE7

Toggle between them:

GDI resource usage increases with each toggle (use bear.exe or GDIobj.exe to see)

This leak is in IE6 and IE7 beta 1

mike_diack@hotmail.com
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
<<I would really appreciate it if IE had an option where Administrators could disable automatic plugin or addon installation.>>

These options are controlled by Security Zones and are absolutely available for control via Group Policy. You can manually set the options using Tools | Internet Options | Security. Select the Internet Zone and choose to customize the various settings for ActiveX controls.
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
I'd also like to mention that, while a lot of people are flaming a lot, I think this all sounds great and I can't wait to get IE7. I'll probably install Windows on a partition here (been a Linux user for 6 years) just for that. (At the moment I run IE6 in Wine.)

I wish my MSDN subscription wasn't 9 years old and long expired, so I could get it now, lol

Anyway, as a web designer (and more importantly, as a sys admin) I really do appreciate the work ya'll are putting into securing and updating this thing.
Anonymous
January 01, 2003
Outlook Express certainly could do with improved spam rules.

I certainly would like some method of filtering mail with complex expressions like "red" and either of "blue" or "green".

I also wish it could filter mail on encoding, like all Base64 mail to a particular folder.
Anonymous
January 01, 2003
With IE7, is there going to be any change from client forcing SSL renegotiation every 2 minutes?
I haven't seen or looked into this for awhile, but I assume the behavior is still there....?
Pretty sure I looked into this again when IE6.0 first came out, but maybe not in IE6 SP1

http://support.microsoft.com/default.aspx?scid=kb;en-us;265369#appliesto
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
Hello Eric,

Such in the case you have over read my suggestion from my last post, I am wondering why DWebBrowserEvents2::SetSecureLockIcon is not fired in BHOs?

Blocking mixed-content by default is a very reasonable and good decision in my opinion.

Viktor
Anonymous
January 01, 2003
Will IE7 give users more control over VBScript and possibly JavaScript? As some of you may know, some of the main things that make a browser like Firefox safer is that VBScript isn't allowed at all, just like ActiveX, which is also bad because certain pages won't run correctly. I know you've made it so that in IE7 beta(and IE6) users will be prompted on ActiveX controls, could you do the same for something like VBScript? JavaScript is also considered dangerous at times, will users have more control over this feature on any page loaded without having to disable it fully?
Anonymous
January 01, 2003
Arh...I'm sorry to have posted so off topic, please forgive me.
Anonymous
January 01, 2003
Internet Explorer has always had an option to prompt you before running script. Furthermore, you can use Zones to group sites that you'd like to permit to use script and those that may not.

That being said, both Javascript and VBScript alone are generally safe. The risk is when those languages are used to activate other objects that may have security bugs. Hence the ActiveX lockdown.
Anonymous
January 01, 2003
I may have my cert configured wrong...but whenever I access my exchange server, I use certificates so it doesn't have to go clear text. I used Microsoft's CA that came with Windows 2003...so I meet one of those criteria.

Will my users be unable to get their email unless I allow their emails to go Clear Text?

Any tips, email me at will@rochestercomputerguy.com
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
Windows Vista sounds great and all but when will the public be able to get a Beta version of Windows Vista and Internet Explorer?

As for the https that sounds good.Also i hope the https problems will be solved and i hope that Internet Explorer 7 looks better then its Beta version 1. Cause lets face it if you don't make it to the public liking then you will no longer have a IE fanbase to work off of.Firefox is starting to gain more market share so what are you going to do about it?
Anonymous
January 01, 2003
Hey this question is about the IE 7 beta. Will you guys be ustilizing the new MSDN product feeback center for this beta. (http://lab.msdn.microsoft.com/productfeedback/default.aspx)
I am not in the IE 7 beta but was in the windows installer 3.0/3.1 and Microsoft Update beta and think that the feeback center is much better than the current beta place/newsgroup way of doing things and seemd to work well for the Visual Studio 2005 and accompanying compenets.
Anonymous
January 01, 2003
> Turn off particular addon base on domains.

I second that
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
Hi, just found an aticle which details new research showing how people are begining to spend less time online, or are giving up purchasing anything at all over the Internet due to security concerns.
I hope this will provide you with extra emphasis to continue your efforts in making IE 7 as secure as it can possibly be, to help restore peoples confidence in the Internet. Thanks.
P.S If anyone is interested, the article is here: http://news.softpedia.com/news/Security-Issues-Lead-to-a-Decrease-of-Internet-Usage-11198.shtml
Anonymous
January 01, 2003
Happy Birthday, Mr. Bill Gates!!!!
Anonymous
January 01, 2003
Tony K. - The IE team blog isn't the right place to talk about OE. Try their blog, the URL is http://spaces.msn.com/members/bryanstarbuck/

-Christopher [MSFT]
Anonymous
January 01, 2003
This is offtopic, but the autoscroll feature in IE looks really ugly, firefox's is nice and clear and no broken edges, try using autoscroll, please fix that! Try to give us a ballpark on when IE7 Beta 2 will be released too :P
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
While we're on the subject of rendering bugs in IE, I thought I'd point out this very annoying bug with buttons.

Have a look here:
IE6 - http://img420.imageshack.us/img420/4253/badbuttonsie3zw.gif
Mozilla - http://img420.imageshack.us/img420/102/badbuttonsmoz7gw.gif

Are you doing anything about this? Because it's obviously a situation of lousy coding, and is frustrating for a perfectionist like myself.

p.s. Thanks for addressing my previous comment.
Anonymous
January 01, 2003
<<How do you possibly stop competitor X (or any general idiot out there for that matter) from simply sending mass feedback against competitor Y? >>

As we've mentioned in the discussion and whitepaper surrounding anti-phishing, votes from the community are alone are not sufficient to flag a site as phishing. All sites marked as phishing have been manually-examined by trained security folks.

Thanks.
Anonymous
January 01, 2003
sbc -- Vista has a number of cryptographic improvements, of which this is just one of them. It just happens that IE7 on Vista will be taking advantage of this particular feature.

IE7 on XP will be able to use the crypto features provided by XP. Could they backport them? Sure. But Vista's crypto changes run pretty deep and it probably isn't worth it to backport them all. (Of course, in the early days, crypt32.dll was updated and distributed with various IE versions (IE3/IE4) so it's not like there's no precedent.)

See this video for more about crypto in Vista:
http://channel9.msdn.com/Showpost.aspx?postid=116710
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
<<Most people wouldn't have a clue what this means. I would like to see warning messages that make sense for a change.>>

Ron, I completely agree that showing folks messages they won't understand is of no help to anyone.

It is certainly challenging to design an experience to accurately convey the subtleties of exactly why these SSL Errors are dangerous. Most users don't understand what the lock icon really means, and hence concepts like "certification authorities", revocation, etc, are all quite foreign.

We're working very hard to make sure that everyone recognizes SSL Errors for what they are, and can understand that there are risks inherent in ignoring the warnings.
Anonymous
January 01, 2003
<<a stopgap fix would be to just use a certificate signed by some outside certification authority. But probably the best solution in the long term would be to enroll the Microsoft CA in the Firefox recognized CAs database.>>

To be clear, the Microsoft server certificate is chained to a root issued by an external certification authority. I'm not sure why Firefox doesn't include the "GTE CyberTrust Global Root" in its trusted certificate store, but I'll ask some friends in the Firefox community.

Thanks!
Anonymous
January 01, 2003
Why is AES Vista only? As Firefox supports it and works on all its supported platforms there is no real technical reason why not. So when people say Firefox is more secure, in this circumstance it is (as no IE supports 256bit encryption).

I suppose the upside is that if you want more secure browing you either move to Vista (which would be more secure in other areas as well) or get Firefox (which will be free compared with the cost of upgrading your OS).
Anonymous
January 01, 2003
Frenk, there's nothing abnormal about that. It should be up to the users to to decide whom they want to trust if a site uses a non-standard server. You would get the same thing using opera and (I hope) IE. If you trust the certificate you get, than to can tell your browser you trust it, and possibly add something to your CA db.
Anonymous
January 01, 2003
Following the lines in this entry, there is something that could be done:

I'm reading this blog through Mozilla Firefox on Linux, and it complains that blogs.msdn.com is signed by the Microsoft Secure Server Authority, which is not recognized by Firefox.
Microsoft could actually benefit its customers in one of two ways: a stopgap fix would be to just use a certificate signed by some outside certification authority. But probably the best solution in the long term would be to enroll the Microsoft CA in the Firefox recognized CAs database.
Anonymous
January 01, 2003
This is some good news; I'm always happy to see IE moving toward more automatic security.

One thing that bugs me in the above is the mention of SPI.When any half-decent server supports TLS negotiation initiated on the client or server side, I fail to see the advantage. Just use http:// and upgrade to TLS when security is required. The certificate-before-Host:-header problem solved, and you don't need to special-case https anymore. Forcing clients up to TLS where required is just a web server security setting ("this directory only accessible over encrypted connections").

I've been doing just that with non-web-browser clients for a long time, and it continues to irritate me that many browsers lack support for it even now. The biggest advantage is that it solves the hostname-before-certificate problem by permitting an initial connection in the clear. It's also consistent with other protocols such as IMAP+TLS (replacing IMAPs), POP3+TLS (replacing POP3s), SMTP+TLS, and so on.

I'd be very curious to know why the approach of extending certificates was taken, when there's this existing mechanism that solves the problem nicely while also offering more flexibility to websites.
Anonymous
January 01, 2003
Tonight, when I log into passport.net, I get roundtripped back to the login screen.

Right before the login screen comes back up, I get a prompt that says that "This page contains both secure and nonsecure items. Do you want to see the nonsecure items?"

As a side note, I can't sign in to messenger either, I get a prompt that the service is down. Yet if I login with another account, it works fine. Two separate issues I know, and off topic on the last one :-D.
Anonymous
January 01, 2003
Will the new focus on TLS include TLS-client-certificate-authentication? I have a use-case that requires that the web-server talk only to trusted client machines. This is not user-authentication. This is mutual-authentication at the TLS layer.
Anonymous
January 01, 2003
Will Benson-- If you're using OWA and securing the traffic via HTTPS using a self-generated certificate, you'll need to install that certificate on your client computers to avoid the error page. Note that if your users don't see the certificate error dialog today in IE6, they won't see the error page in IE7.

BenP-- As noted in the post, we're enabling secure virtual HTTPS hosting for the first time via the TLS Server Name Indication header. The alternative for downlevel is the same that it has always been: get a wildcard certificate (e.g. *.example.com) and serve each virtual host from a subdomain of the root (e.g. vhost2.example.com).

John Moehrke-- I'm not sure I understand your scenario, but IE has long supported client certificates for authentication. Support in Vista is improved with support for the client-certificate related TLS extensions.
Anonymous
January 01, 2003
My use case is healthcare focused, but not unique to healthcare. When communicating highly sensitive data from the web server to the user, there is a need to ensure that all points where the data might be stored (even temporarily) are also secured. It is not enough to authenticate that the user is who they say they are. We also need to be sure that they are currently working on a 'secured' machine. A machine that has a known policy enforcement.

This is easily done by doing a client-node authentication using TLS in addition to the user-authentication using HTTP. The client-node would be identified by a certificate on which an authorization decision can be made. This certificate would only be assigned to trustable nodes. Thus the web-server knows that it is talking to a user who should have access to the data, but also that the machine (or service at the machine) is also authenticated.

Historically IE has only supported HTTP-authentication from the client (including basic, SPNEGO, and certificates) and TLS/SSL node-authentication from the server. But as far as I can tell IE does not support TLS-Client-authentication.

TLS Version 1.0
January 1999
RFC-2246 Section
7.4.6 Client Certificate
Anonymous
January 01, 2003
Good news to disable SSL2 by default!

Regarding the article, I have one question: which set of TLS extensions IE7 will use?
The article says "TLS extensions improve performance", but obviously SNI is not such an extension. Is there any extensions which are enabled along with SNI?
Anonymous
January 01, 2003
To be brutally honest - all these security fixes for IE are a hassle people don't have to put up with. All they need to do is download Firefox and bingo bango - problem solved!

Maybe IE needs to be rejigged from the ground up!
Anonymous
January 01, 2003
John-- I'm not sure I understand your claim. HTTP doesn't offer a certificate-based authentication mechanism. HTTPS does offer such a mechanism (RFC2246 Section 7.4.6), and thus Internet Explorer has supported SSL/TLS client certificates for years.

Or are you referring to using IPSEC below TLS to ensure that the network connection itself is only permitted between trusted machines?

Aidan-- That's a pretty bold claim to be making, considering that you have provided no data to back it up.

As it happens, Firefox and IE6 have essentially identical SSL/TLS configurations and hence it is a mistake to imply that using Firefox provides more security than IE6.

The only SSL/TLS feature that Firefox has today which isn't in IE6 is support for AES, an algorithm which isn't used by most webservers.
Anonymous
January 01, 2003
I understood the client-certificate settings to be utalizing HTTP-Auth. It is good to get a clarification on that subject. What version of IE was the support for TLS 1.0 client-certificate added? Is this also supported by IIS? How is this configured in a .NET environment?
Anonymous
January 01, 2003
>> IE has offered SSLv3 by default since at least IE5.0.

EricLaw--

I've got several packet captures that show Win98 and XP offering an SSLv2 connection before an SSLv3 connection. The only way I've been able to get SSLv3 offered first is to disable SSLv2 in the Internet Options applet. I'm currently having issues with Win98 and an SSLv3 server abandoning the connection as mentioned earlier by jburger. Disabling SSLv2 on Win98 doesn't fix the problem. Any idea how to fix this?
Anonymous
January 01, 2003
Firefox is now on 1.0.7... the joke is that the day that they came out with 1.0.6 huge vuln. came out and so they immediately went to work on 1.0.7. Then they came out with 1.0.7 and immediately, that day, multiple vulnerabilities came out that include take-overs and that includes on *NIX, so stop suggesting that Firefox is more secure! Firefox has tons of issues, like any program, because no matter how hard you work on something, there is always a vulnerability that is crippling... you just have to find it. And I should mention that those 1.0.7 issues still haven't been addressed. If you don't beleive me, go to securiteam.com or any security website and do a simple search.... Good job on working with security, MS, I've been happy with the direction ever since Win NT 5.x, and IE 6sp1 is great, while I love the tabs and added security of IE7.
Anonymous
January 01, 2003
Funnily enough, only a few months before various people at Mozilla have been doing the same thing with SSL2, i.e. disabling it by default.
http://www.mozillazine.org/talkback.html?article=7252

You might want to co-ordinate your testing with the Mozilla guys as they have a list of 2000 web sites left which only have support for SSL 2.0.

In reply to some comments:

EricLaw [MSFT] - I've found that AES encryption is being used on a wide number of servers on the internet (Google use it for example).

John (previous poster) - Having vulnerabilities is in the nature of any networked software. How severe the vulnerabilities are and how long they take to get patched are much better indicators of the overall security of such a piece of software. The record of Firefox is significantly superior in both respects.
Anonymous
January 01, 2003
Chad-- Don't confuse the handshake version with the protocol version. A 2.0 handshake can start a 3.0 protocol conversation if both the client and server support it. If 2.0 is enabled, you must use a 2.0 handshake, even if you are willing to upgrade to 3.0 or TLS1. Firefox, Opera, and IE all behave this way when 2.0 is enabled. You can use Microsoft Fiddler to simply decompose the CONNECT to see exactly what options are offered. As noted to Jberger, I'd love to see any repro URLs you have.

Ian-- We're coordinating loosely with both the Opera and Firefox folks on this, as they've both done some good work on researching 2.0-only sites in the wild.
Anonymous
January 01, 2003
<<Regarding the article, I have one question: which set of TLS extensions IE7 will use? >>

Yutaka OIWA: We will support the Server Name Indication extension, the Certificate Status extension, and perhaps a few more that I'm not allowed to talk about yet.

<<What version of IE was the support for TLS 1.0 client-certificate added?>>

John-- We've supported client-certificate authentication since at least IE5.0, but I suspect it was actually introduced in IE4. There are many references for requiring client-certificates in IIS; here is one of them: http://www.windowsecurity.com/articles/Client-Certificate-Authentication-IIS6.html.

By default, I believe ASPNET uses the IIS-based authentication schemes.
Anonymous
March 15, 2006
As we’ve described
previously, we’ve made some major architectural improvements to improve browsing...
Anonymous
April 17, 2006
Back in October, we blogged about some of the HTTPS improvements we’re making to IE7.&nbsp; At the time,...
Anonymous
May 16, 2006
In Opera 9 Beta there are a lot of changes, as one expects from a major product release. Some of the changes (e.g. UI updates) are more apparent than other changes. Some of the major, but less obvious, changes have been done ...
Anonymous
August 01, 2006
A number of the reports I see reported in our bug reporting system or in various forums concern secure sites that does not get a secure ranking by the security toolbar, produces warnings, or where Opera does not manage to neg ...
Anonymous
October 24, 2006
PingBack from http://visibleprocrastinations.wordpress.com/2006/10/25/what-we-have-here-is-failure-to-communicate/
Anonymous
November 27, 2006
The comment has been removed
Anonymous
April 08, 2007
PingBack from http://beta.andyblyler.com/blog/2006/08/18/rfc-3546-single-ip-virtual-host-https-sites/
Anonymous
May 04, 2007
PingBack from http://www.andyblyler.com/blog/2006/08/18/rfc-3546-single-ip-virtual-host-https-sites/
Anonymous
October 17, 2007
PingBack from http://www.konvulsator.de/blog/2007/10/17/https-name-based-virtual-hosting/
Anonymous
April 18, 2008
PingBack from http://rubi.dishtvnews.com/usinghttps.html
Anonymous
June 09, 2008
PingBack from http://blog.ebrahim.org/2006/02/21/server-name-indication-sni/
Anonymous
January 19, 2009
PingBack from http://luxsci.com/blog/256-bit-aes-encryption.html
Anonymous
January 21, 2009
PingBack from http://www.hilpers.it/1506062-protocolli-https-ssl3-e-tls
Anonymous
January 21, 2009
PingBack from http://www.keyongtech.com/1253180-ie7-rc1-will-not-load
Anonymous
February 22, 2009
PingBack from http://www.vicente-navarro.com/blog/2009/02/22/crear-los-certificados-ssl-para-nuestro-servidor-web-https-con-apache-openssl-y-debian-lenny/
Anonymous
February 25, 2009
PingBack from http://candrews.integralblue.com/2009/02/one-https-site-per-ip-address-or-may-be-not/
Anonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=ieblog-upcoming-https-improvements-in-internet-explorer-7-beta-2
Anonymous
June 02, 2009
PingBack from http://portablegreenhousesite.info/story.php?id=29516
Anonymous
June 08, 2009
PingBack from http://toenailfungusite.info/story.php?id=5871
Anonymous
June 09, 2009
PingBack from http://jointpainreliefs.info/story.php?id=2300
Anonymous
June 16, 2009
PingBack from http://topalternativedating.info/story.php?id=3704

Jaa

Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2

Comments

Lisäresursseja