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
"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
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)?
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.
"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.
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.
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
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>
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.
@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.
<<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? >>
SSL certificate errors result in a connection failure, so navigating to any "explanatory and specific aid screen" doesn’t make a lot of sense. The user would have to have already accepted the invalid certificate in order to get to the "aid screen" explaining why they should ignore the certificate error.
Using SSL insecurely simply isn’t safe, no matter how some sites may try to convince you that it is.
A properly configured secure site should never run into any SSL errors.
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.
<<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.
<<The user would have to have already accepted the invalid certificate in order to get to the "aid screen" explaining why they should ignore the certificate error.>>
Perhaps it is my ignorance, Eric Law, but you are being sarcastic or deliberately obtuse. I never mentioned a screen telling people to ignore a certificate problem.
To repeat: In those situations where an operating site has configured a page to precisely explain to the client what the situation is and who to call within the enterprise — will IE7’s default action create another layer or step to complicate the situation?
It is not helpful to put inane words in my mouth. I can do that on my own.
Brett Merkey
MS asking us to use *standards-compliant* implementation of TLS.
LOL. You’ve put a smile on my face 🙂
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.
Brett, I think you’re being a bit unfair on Eric – he just hypothesised what the aid screen might say.
I’m interested as to what this aid screen contains – if the certificate is invalid, and the server is *still* using it, and your user doesn’t care, what would the server then want to tell them? ("Be more careful in the future", perhaps?)
Or is this perhaps so an admin can have post-mortem HTTPS access to create a new certificate request? If so, it seems to me to be the wrong time to do it.
And even at the moment, if you don’t accept an invalid certificate, SSL fails, so there is no page to display.
Do you have an example of such a page?
Mark
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.
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 http://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 = http://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
<<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.
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.
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:[email protected]
<<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.
> 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?
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!
"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)."
Windows Vista likely includes extensions to CryptoAPI to support AES. While Microsoft could include AES with IE, this presents some issues. You’re correct, it would not be a technical reason, it would be a legal reason. The United States, unfortunately, has insane laws regarding "strong" (I believe the current definition of "strong" is more than 56bits) encryption. Basically, if someone tries to export it from the US, they are guilty of exporting a "munition" that is generally considered a "weapon of mass destruction." While the US allows for exceptions to be granted (just like MS had to apply for to include crypto in Windows), there are other hurdles. For example, strong crypto is outright illegal in China. This would mean that each language version of IE would have to be made specifically for the laws of that country. Rather than deal with these complexities within IE, it is easier to let the Windows team handle it. My guess is the Firefox team mostly ignores this fact (though they do have BXA approval for US export) and leaves compliance in the hands of the users.
So in short, blame the governments of the world for making it difficult to export encryption.
By the way, this doesn’t mean IE is "less secure". AES is relatively new, only time will tell if it is truly more secure than 3DES (key size isn’t everything). For example, even though the AES authors were very much aware of "timing attacks," AES has been found to be vulnerable to them. While DES suffers similarly, there is no evidence that the DES team was aware of timing attacks whereas it is well known that the AES team was, hence if they intentionally overlooked this security issue, what else did they overlook? So I would not be so quick to say this makes Firefox "more secure" just yet!
Will IE7 (and Vista for that matter) conform with the National Security Agency’s "Suite B" requirements? I see that AES is used but what about elliptic curve algorithms for digital signatures and key exchange?
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.
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.
>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.
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!
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
[email protected]
One comment here pissed me off.
‘(and involve the software saying "You’re too gullible to make your own decisions")’
You certainly don’t work in IT!!!
The vast majority of computer users ARE too gullible.
Following in that thought, I would really appreciate it if IE had an option where Administrators could disable automatic plugin or addon installation. FireFox does not install plugins from random sites. It has a closed network where it searches for plugins. This is far more idiot-proof, and that is why I put FireFox on computers, is that these addons and plugins are not only the primary source of spyware, but the users really aren’t techie enough to recognize when a site is installing something.
If IE would let me disable that feature, I would be happy as a clam.
I read an interview with one of the OpenBSD developers who mentioned that the OpenBSD style of security was to relentlessly audit everything and, more importantly, have it set up in a secure fasion ~out of the box~ rather than have it so you can optionally enable security.
Considering the vast majority of people who will be using IE don’t understand security enough to even know to "opt-in" to it, these things really ought to be designed to be as tight as possible by default, so that users who know what they’re doing can opt-out.
From my experience, idiot-proofing the software is simply the best thing you can possibly do for security.
I have to say that Joe is spot on the money here – the vast majority of people (and yes there is the odd exception – I’m talking about the general public at large) are totally gullible. I believe the expression goes "don’t underestimate the power of stupid things in large numbers".
This is why when a virus contained within an attachment of an email reading "I love you", it spreads like wildfire. This is because regardless of how many times people have been told that opening attachents from emails of unkown origins is potentially dangerous, their natural curiousity will kick in and they’ll open it anyway.
It’s also why, when someone gets an email asking them to hand over all their banking and/or personal details to company X, they are all to happy to oblidge. This – once again – is dispite the fact that the message being put out by the major banks and online retailer, is that they will very rarely, if ever, ask for peoples details in this fasion, but people still on keep falling for it.
The one I still can’t believe people keep falling for though, are those lottery style scams going around. Somebody gets an email from someone, stating that they have won vast sums of money from the Canadian sweepstakes/from some wealthy dead bloke/from whatever other story the con artist cares to make up, but the person recieving the email must hand over a check to deal with ‘administration’. Hello, clealy never heard of the expression "If it’s too good to be true it usually is".
Anyways, the list of stupid decisions made by the ‘average user’ could go on and on, through both a wonderful combination of ignorance and stupidity. My overeall point here is that there has to come a stage when the public at large must be protected from themselves.
So, to the IE team, continue to do everything in your power to make IE 7 as secure as possible – leave absolutely nothing to chance, or indeed the end-users "good" judgement, as it has been proved time and again that both lead to disaster.
Thanks.
<<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.
>> 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.
Awesomes!
Now I feel stupid for complaining and not having known that for so long. I didn’t think all the plugins and things were ActiveX, I thought that was a specific special feature…
Embarassingly enough, that kinda proves my point about making it idiot-proof �?
As for power users and people who don’t like "having their hands held" and such, making sure these things can be opt-out should suffice.
One thing I realized, is that installing controls in particular is kinda required, but it might be possible to better secure them by tagging their source and refusing to install ones from unknown sources.
I like FireFoxMozilla’s system of having a plugin installer that gets them from a controlled repository, though I’d expect Microsoft to run into anti-trust related trouble if they tried that.
Is this what certificates and digital signing is about? Cause it might work to simply by default refuse to install programs from unknown sources, but to enable this one must go into the menu manually and do it.
This would let power users and pluginaddon developers to do there thing, while standard users wouldn’t be presented with a question like
"This site requires an ActiveX control. Would you like to allow it to install it?"
where the user has absolutely no idea why they would say "no". The expert knows that it might be spyware. The typical user knows that he wants to see a site, and to do so he has to click yes, and there’s no obvious reason to say no.
Something more like:
"This addon is from an unknown and possibly malicious source and cannot be installed."
would be more clear.
Again, the ability to opt-out would be prudent for developers and power users, but being prompted to opt-out of something the user doesn’t understand is more than a tad insecure.
Obviously someone could "hack" it to make the browser think something is signed… And since spyware (I’m differentiating it from virii, it’s an important distinction) are typically run by legal companies in for profit, that of course opens them up to class action lawsuits for illegally hacking 🙂
Seems like this would be relatively easy to setup, and I bet would stop a lot of accidental spyware installs, which do happen a lot through the web browser… This combined with the advice "don’t install programs on the internet" would pretty much close most of the major holes.
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.
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.
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
I agree, the autoscroll feature is kind of fugly. Anyway after testing beta 1 for a week I’ve a few issues with the GUI:
1) Merging the refresh/go/stop button and then making it really small and hard to read is a bad idea. Keep it seperate.
2) Its also annoying to have to use the keyboard to press enter after typing/pasting a url, instead of clicking the go button. In fact each time you open a new tab instead of having a go button, it is stuck at refresh.
3) The address bar, back and forward buttons and the search field aren’t customizable.
4) Tabs are a good thing but they take up more space than necessary, especially the few pixels above the tabs.
5) I noticed that the information bar is displayed even if you disable notifications for pop-ups and such.
6) Managing RSS feeds in IE7 is as clucky as navigating through regular links. A method of retrieving all feeds in a centralized location, something like the way iTunes handles subscribed podcasts.
Thats all I have for now..
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
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?
Arh…I’m sorry to have posted so off topic, please forgive me.
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.
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 [email protected]
"Ensure that the hostnames used for your secure pages exactly match the hostname in your digital certificate. For example, using the certificate for http://www.example.com on secure.example.com will result in an error page.".
That’s crazy !
How can we do virtual hosting now ?
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?
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.
> Turn off particular addon base on domains.
I second that
frec– While it’s not exactly what you’ve asked for, you can use the IEToys plugin (http://www.bayden.com/ietoys) to remove all Images & Flash from the current page in one click. I find this useful for cleaning up pages I’m trying to read.
###offtopic###
this is a post form ie6 gerneral newsgroups
Product suggestion(about addon management)
Flash(shockwave) Ads is used by lot of websites and made my IE sloooow as hell.
I always turn them off by bunch of clicks and turn on occasionally.
This is a pain in ass.
I suggest microsoft provide a more convenient way to manage
this activex addon.
Ex.
1.Turn off particular addon base on domains.
2.One click turn off(on) flash,when turn off notify them on the page.
TIA
Frec
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
Happy Birthday, Mr. Bill Gates!!!!
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]
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 😛
Very good idea to disable SSL2.
But:
Please show the user in the status bar icon, that the connection is really high encrypted.
Not long ago, I found a bank where the IE6 shows "128 bit" in the key-bubble in the status bar with a https-connection, but the rsa-key was only 512 bits (rc4 was 128 bit). After a complait from me the bank changed the certificate.
The end-user must know, that there are two keys:
The unsymmetric key (e.g. rsa) and a symmetric key (e.g. rc4) and both must have minimum length to have a secure connection. Only "128 bit" is not enough! And: you do not need a AES 256 Bit symmetric key if the unsymmetric key is weak (e.g a 512 bit rsa key).
Let the user know this and give more detailed information about the https-connection! I would prefer a "normal user" information view and a "detailed" information view – and a bubble text that includes infomation about the unsymmectric key, e.g. "1024Bits RSA + 128Bits RC4" or "2048Bits DES + 256Bits AES"
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.
<<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.
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
Hello Eric,
When is it coming out? I mean the Beta2. I’m not even asking about a specific date.
November?
December?
January?
If November, just type one pipe "|".
If December, just type two pipes "||".
If January, just type three pipes "|||".
Thanks
I have to admit, Jeans question is a valid one (even if it is a little out of place in this blog) and was one of the great unanswered comments from the last phising blog: http://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx#comments.
How do you possibly stop competitor X (or any general idiot out there for that matter) from simply sending mass feedback against competitor Y? You’ve gotta admit, that without the proper thought this system of user feedback could be very prone to abuse.
In addition, I would like to point out how my request for information regarding the InfoCard thing from: http://blogs.msdn.com/ie/archive/2005/09/27/474713.aspx#comments, went somewhat ignored, so any information you can provide on that issue as well would be much appriciated. Thanks
P.S In acknowledgment to this blog, what you are saying sounds excellent and I hope you keep up the good work, it really is much appriciated.
I know this is OT in this thread but you didn’t answer this VERY important question yet in the other thread:
Dear Microsoft-Developers:
How do you bar competitors from blaming each other using phishing websites?
There really comes a high risk of abuse with this phishing website suggestion tool.
Greets Jean
<<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.
<<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!
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).
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.
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.
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.
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.
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.
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.
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
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?
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!
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.
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?
>> 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?
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.
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.
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.
<<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.
As we’ve described
previously, we’ve made some major architectural improvements to improve browsing…
Back in October, we blogged about some of the HTTPS improvements we’re making to IE7.&nbsp; At the time,…
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 …
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 …
PingBack from http://visibleprocrastinations.wordpress.com/2006/10/25/what-we-have-here-is-failure-to-communicate/
PingBack from http://www.nevillehobson.com/2006/11/28/unofficial-vista-blog-tour-day-2-does-ie7-suck/
PingBack from http://beta.andyblyler.com/blog/2006/08/18/rfc-3546-single-ip-virtual-host-https-sites/
PingBack from http://www.andyblyler.com/blog/2006/08/18/rfc-3546-single-ip-virtual-host-https-sites/
PingBack from http://www.konvulsator.de/blog/2007/10/17/https-name-based-virtual-hosting/
PingBack from http://rubi.dishtvnews.com/usinghttps.html
PingBack from http://blog.ebrahim.org/2006/02/21/server-name-indication-sni/
PingBack from http://luxsci.com/blog/256-bit-aes-encryption.html
PingBack from http://www.hilpers.it/1506062-protocolli-https-ssl3-e-tls
PingBack from http://www.keyongtech.com/1253180-ie7-rc1-will-not-load
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/
PingBack from http://candrews.integralblue.com/2009/02/one-https-site-per-ip-address-or-may-be-not/
PingBack from http://paidsurveyshub.info/story.php?title=ieblog-upcoming-https-improvements-in-internet-explorer-7-beta-2
PingBack from http://portablegreenhousesite.info/story.php?id=29516
PingBack from http://toenailfungusite.info/story.php?id=5871
PingBack from http://jointpainreliefs.info/story.php?id=2300
PingBack from http://topalternativedating.info/story.php?id=3704