There are two basic ways to get to a web site:
- You key in the URL or use one of your bookmarks.
- You click on some web page.
The first way doesn't create much of a problem. Assuming you actually know the URL and didn't get it from Google or something, then the URL/cert comparison works.
The problem is when you get the URL from someone else. You type in "Microsoft" and click on one of the links. Unfortunately, it goes to www.micros0ft.com. Now, there's no reason why the operator of www.micros0ft.com can't get a certificate with www.micros0ft.com in it. You dereference the URL, the HTTPS connection works, the certificate matches, and unless you're paying really close attention, you don't notice that you have the wrong URL.
The standard advice to people is to pay really close attention, but that never worked real well and there's something that makes it worse: internationalized domain names. Originally, DNS names were ASCII-only, but recently they've been expanded to include non-ASCII characters. The problem is that there are some glyphs in other language sets that look like characters in English. This lets you mount an even more convincing attack, called a homograph attack, in which you use a foreign language glyph that looks like an ASCII letter, such as in www.paypаl.com. This has been known about for about 3 years but only works if browsers actually know how to process these domain names, which they didn't generally do back then. However, it has been recently shown that many browsers are now smart enough to be fooled by this. Outstanding!
How bad you think this attack is kind of depends on your model of how gullible people are. In particular, if you think people will be fooled by the micros0ft-style attacks, then homograph attacks don't bring much to the party. On the other hand, if you think people are a bit smarter, then maybe this makes the situation worse. That said, it's worth noting that there are lots of legitimate situations in which the URL you do a secure transaction with doesn't have much to do with where you started. Try buying a ticket from United Airlines and you get redirected to https://www.itn.net/...
Interestingly enough, firefox gets it just wrong enough at the moment that it won't fool anyone; on the other hand, if my first language didn't use a Latin alphabet, I wouldn't stand for what it does.
Firefox (and presumably Mozilla and Netscape) correctly takes the "а" and renders it in the browser window and even in the status bar as a perfect homograph for a lowercase a. (I haven't looked it up, but I assume this is a homograph from the Cyrillic alphabet).
However, if I click on it, the URL bar at the top of the browser shows the punycode version of it: "http://www.xn--paypl-7ve.com/". That's not exactly subtle, but I see how a particularly un-alert user might not notice it. Everything up to that point sure made it look like you were going to end up on paypal's site, but once you're there, it's pretty obvious that someting is amiss. So, I disagree with Secunia's unqualified evaluation of Firefox 1.0 as "vulnerable."
I suspect there's a mitigating factor built in at the moment: any cert authority that started issuing certs for domain names with characters taken from multiple codepages -- especially obvious homographs -- would probably be pilloried by the security community at large, and may even start having their root cert ripped out of common browsers.
However, there are definitely some user-interface improvements that can be made here: it would make a lot of sense for the browser to pop up a window trying to explain the situation, something like "most of this domain name is written in , but this character is taken from . It is likely that someone is trying to fool you." Alternately (or additionally), it could give the names for the characters: "This word would be spelled 'pee ay wye pee ah ell'"
Hmm... none of this seems very clear, actually. My point was that programs can generally detect suspicious activity by checking for letters pulled from different codepages. Explaining to the user what's going on may pose an interesting challenge.
My firefox 1.0 (WinXP, with lots of international fonts installed) does not display a punicode entry in the address bar. I go to that address, and it still appears to be paypal.com
Aha! You are correct, Brian. The first time I tried this, it involved launching Firefox from the RSS reader inside Thunderbird. If you do so, you get the address bar relic I spoke of; however, if I click on it from the EG site in firefox, then I get the same result as you: a visual experience that is indistinguishable from going to www.paypal.com (except, of course, for the actual page content).
The results are the same under XP and Linux.
Curiously, it's not an exact homograph as rendered in Safari -- it's only a pseudohomograph -- looks like it's either being rendered in a different font, or else for some reason the letter's just plain drawn differently in this font. See here to see what I mean.
This type of attack has been known about since at least 1999 or early 2000. In Windows XP, there are at least 3 different technologies that can help protect a user against the attack, IF (and this is a big IF) the user is willing to restrict the web sites they visit to an inclusion list.
At the time of design, it was envisioned that companies like Disney or non-profit groups would ship inclusion lists to create "child safe" browsing zones. Of course, this never really panned out.