bugtraq - Re: International Domain Name [IDN] support in modern browsers allows attackers to spoof domain name URLs + SSL certs.

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: <20050212100101.GK26303@syjon.fantastyka.net>
Date: Sat, 12 Feb 2005 11:01:01 +0100
From: "Janusz A. Urbanowicz" <alex@...h.net.pl>
To: Scott Gifford <sgifford@...pectclass.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: International Domain Name [IDN] support in modern browsers allows    attackers to spoof domain name URLs + SSL certs.

On Fri, Feb 11, 2005 at 02:07:26PM -0500, Scott Gifford wrote:
> "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.

Judging rightness of domain names is not a job of X.509 CA, and never was.

The job of the organization is to check whether the one applying for the
certificate is the rightful owner of the domain, and that's all that is
included in the protocol trust and threat model.

Not to mention that it would damage the revenue stream and make the CA prone
to litigation.

X.509/TLS is not for assuring if the server you are connected to is lawful.

Alex
-- 
mors ab alto 
0x46399138