lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Feb 2005 12:24:39 +0100
From: "Peter J. Holzer" <hjp@....ac.at>
To: bugtraq@...urityfocus.com
Subject: Re: International Domain Name [IDN] support in modern browsers allows    attackers to spoof domain name URLs + SSL certs.

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@....ac.at        |
__/   | http://www.hjp.at/   |     -- Tim Bunce on dbi-users, 2004-11-05

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ