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.
