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

Message-Id: <1195516708.26608.6.camel@tpol.lan>
Date: Tue, 20 Nov 2007 00:58:28 +0100
From: Nils Toedtmann <securityfocus@...s.toedtmann.net>
To: Kapetanakis Giannis <bilias@....physics.uoc.gr>
Cc: bugtraq@...urityfocus.com
Subject: Re: Certificate spoofing issue with Mozilla, Konqueror, Safari 2

Am Dienstag, den 20.11.2007, 00:51 +0200 schrieb Kapetanakis Giannis: 
> On Sun, 18 Nov 2007, Nils Toedtmann wrote:
> 
> > Mozilla based browsers (Firefox, Netscape, ...), Konqueror and Safari 2
> > do not bind a user-approved webserver certificate to the originating
> > domain name. This makes the user vulnerable to certificate spoofing by
> > "subjectAltName:dNSName" extensions.
> > 
> > ...
> > In the end, the cert warning and the spoofing attempt get separated into
> > two events which appear to the user as being unrelated. I consider this
> > a severe cert-spoofing issue, aggravated by the fact that affected
> > browsers also match any hostname with "subjectAltName:dNSName=*".
> >
> > Regards, /nils.
> 
> I would consider this a feature of the X509 standard and not a bug.
> subjectAltName and wildcard matching exists primarily for name based
> virtual hosting in SSL/TLS. There is no other way you could do this
> without this extention. (*correction -> check bottom*)

Agreed. I don't claim this being a bug of X.509.

> If a user is fool enough to accept lame certs (even temporary)
> and then later on send his private data in secure sites without
> checking the certificate (at least the CN which yells the difference)
> then he probably asked for it.
> 
> If there was a warning that the CN is different
> than the hostname requested then subjectAltName flexibility would 
> be useless. In temporary saves the CN could be binded to a unique hostname
> but in permanent saves this would be a problem.
> 
> I agree with you that subjectAltName should be 
> presented together with the CN in the front page of the cert info
> as both attributes share the same importance.
> It shouldn't be too hidden as it is now. However it is visible.
> 
> Having said that I still believe that since the user accepted the cert
> he decides to trust it. The user trusts the (whole) certificate not the 
> browser.
> The user tells the browser I want www.example.com *.example.com and
> *.foo.bar to be trusted under this certifacate. The browser obays as it 
> should.

Agreed again: if all subjectAltNames would be shown to the user on first
contact like the CN it would be a user issue. Instead, browsers bury
them in details, Konqueror does not even show them *anywhere*. So an
avarage user has not enough information to make a proper decision.

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.


> ps. I've just discovered this:
> http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/
> 
> rfc3546 defines Server Name Indication (SNI) extention
> which is used by mod_gnutls for tls name based virtual hosting.
> Looks interesting :)

Yes, SNI is the 'real' solution to vitual https hosting. But it will
still take some time till all servers, clients and admins know that.

Regards, /nils.