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]
Message-ID: <lysm42gbkh.fsf@gfn.org>
Date: Fri, 11 Feb 2005 14:07:26 -0500
From: Scott Gifford <sgifford@...pectclass.com>
To: bugtraq@...urityfocus.com
Subject: Re: International Domain Name [IDN] support in modern browsers
 allows    attackers to spoof domain name URLs + SSL certs.


"Peter J. Holzer" <hjp@....ac.at> writes:

[...]

> 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

Maybe I'm naive, but shouldn't a trustworthy root CA not sign
certificates for domain names which are obviously meant to be
deceptive?  Isn't this the entire reason for browsers coming with a
small list of CAs which are deemed trustworthy?

If the holders of widely-trusted root certificates can't be trusted to
avoid even the most rudimentary deceptions, many of the protections of
SSL have only very limited value.

Perhaps some more care on the part of browser packagers in deciding
which CAs have their certificates included by default is the solution.

----ScottG.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ