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

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

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*)

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.

regards,

Giannis
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 :)