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
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
Moin *
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.
I set up a demonstration at
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.
...
Hi
On Tue, 2007-11-20 at 00:51 +0200, Kapetanakis Giannis wrote:
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
On Tue, 20 Nov 2007, Kapetanakis Giannis wrote:
I would consider this a feature of the X509 standard and not a bug.
The behavior is remarkably counterintuitive. It could be reasonably
expected for the browser to properly communicate the situation (show a
list of aliases) to the user, or better
