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: <MDEHLPKNGKAHNMBLJOLKEEOFBLAB.davids@webmaster.com>
Date: Sat, 12 Feb 2005 16:32:26 -0800
From: "David Schwartz" <davids@...master.com>
To: <bugtraq@...urityfocus.com>
Cc: "Scott Gifford" <sgifford@...pectclass.com>
Subject: RE: International Domain Name [IDN] support in modern browsers allows attackers to spoof domain name URLs + SSL certs.



> As a user of a browser I am not a customer of the CA, and it isn't
> evident why the CA should be under any obligation to me.  They surely
> are under an obligation to their shareholders and their customers.


	Nonsense. The CA is asking for your trust and can only earn revenue based
upon the number of people who trust it.

	This is like asking why Burger King shouldn't just use sawdust instead of
beef if they can get away with it. The answer is that people will find out,
and they'll stop trusting Burger King.

> >            Isn't this the entire reason for browsers coming with a
> >small list of CAs which are deemed trustworthy?
>
> Perhaps I am too cynical.  But I always thought they were there to
> advance the business interests of the CAs.

	No. The browser companies don't care much about the CAs. They're to advance
the business interests of the browser authors/vendors. And if the browser
authors/vendors include CAs that aren't trustworthy, they'll either lose
business, or create a business oppurtunity for others to lock down their
browsers.

> >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.
>
> The protections have only very limited value.  They are perhaps
> adequate to make MITM attacks unlikely, but they are not capable of
> dealing with the kind of deception being discussed here.

	This I do agree with.

> >Perhaps some more care on the part of browser packagers in deciding
> >which CAs have their certificates included by default is the solution.
>
> This would not help much.  The existing PKI based system is based on
> an unnatural network of presumed trust.
>
> A better system would allow a certificate to have many co-signers,
> much as PGP keys can be co-signed by many others.  In such a system,
> my credit card company could act as CA.  I am a customer of my credit
> card company, so this would build on natural trust relations.
> Moreover, my credit card company could act as guarantor for any
> purchases I make at web sites where they have signed the site
> certificate (presuming that I use their credit card).  This would
> provide a substantial financial incentive for the credit card
> company, acting as CA, to be wary of possible deceptive practices.

	This is not so much a better system as a system with a different objective.
The object of the current PKI/SSL system is to prevent MITM attacks and
ensure that you get to the domain name you entered. It is not intended to
ensure that the end host is trustworthy in any way, just that you got the
end host you wanted.

	The reason this particular problem is interesting is because it reflects a
failure of the scheme to do precisely what it was intended to do.

	DS