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:38:46 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ne.cc>
To: Kapetanakis Giannis <bilias@....physics.uoc.gr>
Cc: bugtraq@...urityfocus.com
Subject: Re: Certificate spoofing issue with Mozilla, Konqueror, Safari 2

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 yet, to initially bind non-trusted
certs to their originating domain only, at least until an explicit desire
to extend their authority is expressed by the user.

What the standard says is immaterial - it is not expected to anticipate
that we might live in an world where scores of low-budget, non-sensitive
sites use self-signed certs - but it's unreasonable to expect any user to
refrain from visiting some page *at all* just because of a certificate
warning (he should be wary of the content therein, of course, but so
what).

If any attempt to visit such a page bears an inherent, undisclosed risk -
other than the page itself possibly being bogus, of course - there's a bug
to be fixed.

> 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.

The Web is used by close to a billion people who do not necessarily check
the details of SSL certs, or inspect all HTTP headers, on *every single*
login to their webmail or online banking site.

We may perhaps blame them if they click through clear and concise security
warnings, or subvert other measures, and willingly consent to an
unnecessary risk - but when they rely on the expertise of browser vendors
to know that something is wrong, and get burned - well, it's not their
fault.

/mz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ