Kapetanakis Giannis
20/11/07, 12:18
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 :)
> 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 :)