On 2005-02-09 10:31:30 -0500, Will Kamishlian wrote:
> I tested the following browsers against the proof of concept page
> (www.shmoo.com/idn):
>
> - dillo (0.8.3)
> - lynx (2.8.5)
> - konqueror (3.3)
>
> Testing was done on Linux 2.6.9 (generic)
>
> Dillo and lynx handle the links well (dillo returns a DNS error and lynx
> reports an invalid URL).
No, they don't handle the links "well", they just don't support IDN.
These URLs are valid, and they should work.
The problem is that the unicode character set has a much larger set of
characters than ASCII and hence a lot more characters which look very
similar or even the same in many character sets (In the character set
used by Mozilla on Fedora Core 2 (Lucida Sans), the cyrillic "a" looks a
bit different from the latin "a", but you have to look very closely).
So, while before you only had to worry about "1" being mistaken for "l"
or "I" and "0" for "O", you now have to worry about many more similar
characters.
I don't know the real solution to this problem, but I'm sure it's not
turning off IDN (apart from my opinion that IDN is technically a
horrible kludge which should never have been implemented).
The best way I can think of is to make it easy for the user to check
information about the Domain. For example, the certificate for
www.pаypal.com is for
CN = www.xn--pypal-4ve.com
OU = Domain Control Validated - StarterSSL(TM)
OU = See www.freessl.com/cps (c)04
OU = https://services.choicepoint.net/get.jsp?GT57083512
O = www.xn--pypal-4ve.com
C = US
While the certificate for www.paypal.com is for:
CN = www.paypal.com
OU = Terms of use at www.verisign.com/rpa (c)00
OU = Information Systems
O = Paypal, Inc.
L = Palo Alto
ST = California
C = US
Which certainly looks a bit different. The same is true for the whois
entries:
Registrant:
testing only
3659 22nd Ave W
Suite 4
Seattle, WA 98199
US
vs.
Registrant:
PayPal Inc. (PAYPAL2-DOM)
2211 North First Street
San Jose, CA 95131
US
This of course requires the User to know what the entry should look like
(I am assuming that a real attacker wouldn't have registered his domain
as "testing only").
Another possible source to check would be Google (warn if the page is not
among the first results for a search on the content of the page).
A possible improvement in the UI of browsers would be not to accept new
SSL certificates silently if the CA is known, but to display the data
anyway. Something like:
You are visiting the site https://www.paypal.com for the first time.
This website belongs to:
Common Name: www.paypal.com
Organisation: Paypal, Inc.
Location: Palo Alto
State: California
Country: US
This information has been checked by Verisign, a Certification
Authority you trust for this purpose.
The domain paypal.com has been registered by
PayPal Inc. (PAYPAL2-DOM)
2211 North First Street
San Jose, CA 95131
US
on 15-Jul-1999.
Make that visually different from unknown certificates from an unknown
CA, so that the user can clearly (and without thinking!) distinguish
between these three situations:
* User has visited this site before.
* User has never visited this site, but there is some verified
information about the owner - user should check if this information
matches his expectations.
* User has never visited this site, and the information about this site
is suspect. User should additionally check if this information is
plausible.
hp
--
_ | Peter J. Holzer | If the code is old but the problem is new
|_|_) | Sysadmin WSR / LUGA | then the code probably isn't the problem.
| | | hjp@xxxxxxxxx |
__/ | http://www.hjp.at/ | -- Tim Bunce on dbi-users, 2004-11-05
Attachment:
pgpU6z1xteHiI.pgp
Description: PGP signature