bugtraq - Re: Certificate spoofing issue with Mozilla, Konqueror, Safari 2

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>] [day] [month] [year] [list]

Date: Wed, 21 Nov 2007 00:09:46 +0200 (EET)
From: Kapetanakis Giannis <bilias@....physics.uoc.gr>
To: bugtraq@...urityfocus.com
Subject: Re: Certificate spoofing issue with Mozilla, Konqueror, Safari 2

On Tue, 20 Nov 2007, Mark Senior wrote:

> If I subsequently visit my bank's website, and I get no SSL warning, it
> should ****ing well mean the certificate is valid.
>
>> However, vendors seem to head towards strong hostname binding. MSIE,
>> Opera and Safari 3 already do so. Mozilla-1.9/Firefox-3 will have the
>> probably best solution: the user can set a list of hostname/port tupels
>> a cert shall be trusted for.
>
> I'd say this is the right course.

As I've mentioned in my first comment,
I agree that hostname/port binding to cert saving could
reduce such attacks like the one proposed by Nils.

> Of course, we're ignoring what I'd say is the fundamental problem with X509
> - a CA is either authoritative for the entire DNS namespace, or for
> nothing.  I might want to trust the CA of the Israeli government for
> *.gov.il, but for a bank in Egypt?  Not so much...
>
> Cheers
> Mark

Well, we allready trust many CA's for such purposes. Random names:
AOL, VISA etc...

Creating a CA hierarchy attached to DNS seems nice from one point of view:
a DN-CA would verify certs belonging under it's domain name tree only.
That's good.

Every registar and every end-entity that bought a domain
would have to introduce policies and procedures for certification 
management/enrollment/revocation etc -> whole PKI.

Either they would manage it themselfs (my believes are that we're
immature as a group for such solution)
or
pass the chain of trust to a 
third party. That third party would have to be able to verify the whole 
DNS universe or at least a part of it. Who decides which CA 
verifies a domain? A root CA or a banch of them on top (it still tree 
based). Isn't the same we're doing now?

Almost the same. A CA would still be liable for a certain domain 
only (good) but a root CA would still had to be liable for that CA (bad).
However it would be possible to setup real working PKI without paying to 
AOL, VISA etc (really good). An attacker would still be able to setup a 'test' 
root CA and make you accept it's cert for that 'test' DNS universe-part (bad).

It seems to me more of a DNS problem than a x509 problem.
If that's the case we should tend in using protocols for securing the DNS system,
like DNSSEC or something better.
x509 and TLS is really nice and helps even in that.

cheers,

Giannis