firefox and bad ssl certificates
hggdh2 at gmail.com
Sat May 10 19:26:49 UTC 2008
On Sat, 2008-05-10 at 16:08 +0200, Milan Bouchet-Valat wrote:
> Notifications are never read, especially by users that are not
> passionate by computers - they're exactly like there was no message at
> all, only they annoy users: "click OK and then see if there's a problem"
> is what OS have used people to for many years. And after that the lock
> in the adress bar still seems to confirm you're on a secure website.
The lock in the address bar means you have reached a web site that
employs a certificate signed by one of your accepted (either by default,
or by your own voluntary actions) root certificates; it also means
exchanges between your computer and the web site are encrypted (and, as
such, more private).
It does not mean, at all, that this web site is more or less secure than
any other. Please do not confuse security with privacy.
> IMHO it's not mainly about educating the user, but to force servers to
> use correct certificates. When freedesktop.org will understand every
> person that goes to their bugtracker gets to the new Firefox warning,
> guess they will change their certificate. ;-) (just an example)
Why should (for example) freedesktop.org change their certificate?
Because we do not deploy their root in our known roots (huh, BTW,
*all* top-most roots are *always* self-signed)?
What is a correct certificate? Where is the standard, RFC or
otherwise, that says so?
Also, please keep in mind that what we are buying in is trust in the
signer of the certificate (the so-called root), not trust in the
principal. By definition, your system will trust all certificates
signed by an accepted root.
If you really want to lock in a specific principal, you have to
validate the root and check the DN or CN. Then, it really does not
matter if the certificate being checked has been signed by an already
known root, or it is a self-signed. In this case, we should have a way
of specifying that a web site will only be accepted if the certificate
is signed by a specific root (or root chain), and has a specific CN (or
And this brings to my mind the old key distribution problem...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the Ubuntu-devel-discuss