Hello all,
I have proposed a few changes to SSL handling in response to the debian
openssl disaster. I also mentioned earlier that a way to limit CAs
would be nice, giving quite hypothetical cases where it would be
useful. With the recent Commodo verification failure and the MD5
weakness just disclosed, I see more very practical arguments for these
sugesstions, as it is painfully obvious that we have to expect failures
of CAs. I have rethought some of the ideas and would like to hear your
opinion on the following:
I suggest an universal mechanism (integrated or as an extension) than
can be fed rules about certificates, CAs and sites and showing warnings
or interrupting connections where necessary. These rules could be
updated independently. Mozilla could publish "official" rules and/or
anyone could publish their own suggestions (like with adblock lists).
In the default config, the mechanism might be completely invisible and
just checking for updated rules (similar to updating the phishing
blacklists etc.)
The rules would contain conditions (like "Any cert with this
fingerprint anywhere in the chain", "Any cert has MD5 mechanism",
"Certain CA involved AND NOT Domain matches *.example.com", "SHA1 of
modulus matches ...") and actions (like "consider cert invalid",
"display warning and let user confim to continue connection", "display
small notice" etc.)
This should be relatively easy to do and not cause any problems. It
would however allow to do following things:
The Commodo issue: All certificates issued by the affected RA (if it
can be decided by ANY automatic means like a certain serial number
range) could be caused to display either the normal SSL warning or a
custom warning like "The security certificate of this connection is
valid, however, the company that certifies the security of this
connection has been found to have issued wrong certifications. Do not
do anything important via this connection. For more info, click here".
Such a mechanism could be used even if it would affect ALL of Commodo
and would allow a very fine-grained response. This would work for
everybody, if the rule was included in the mozilla official
auto-updated ruleset.
With the MD5 problems that have occured, it could show a warning
balloon like "this connection is secured using an old method. Although
difficult, an attacker with enough ressources may be able to break the
security. Do not proceed if this warning appears on the web page of a
bank or other high-security application." This would work for
inexperienced users, too, if the rule was included in the mozilla
official auto-updated ruleset.
Anybody could make a list (and share it if he likes) of CAs he does
trust fully and CAs he would like to know if they issued a cert
securing his current connections. If someone does not fully trust a CA,
but still doesn't want to disable it completely, this would be an
option. (If I disable the trust bits, it would be hard to find out if I
have a cert issued by that CA of a fake one using the name. Scenario: I
might want to continue to accept Commodo certs but be warned about it
because disabling them would be a too big issue but I do not fully
trust them anymore.) If a user using this config would visit
http://mozilla.com and the Cert was issued by one of the CAs he does
not fully trust, he would get a warning and might get suspicious. This
is for advanced users only.
Users and/or mozilla could restrict the validity of certificates by
date, domain etc. For example there was a suggestion "Just change
expiry time" (of the certs from the commodo case) - this would be
possible easily. (for everybody via the auto-updated list.) My scenario
that I would like to include the cert of my university but make it
valid only for university sites would also be possible. (Individual,
for experienced users)
Had this plugin existed during the debian disaster, the blacklist would
be a simple thing to do. All it would take would be a simple ruleset to
import, one person could compile it and everyone could use it
afterwards with no real coding involved. (The code would be done ONCE
and cleanly and well-integrated. Currently the debian weak key
blacklist extension shows a warning but cannot interrupt the
connection).
Even the often requested "ssh-style certificate lock-in" (showing a
warning when a cert changes) would be possible: A rule could be added
"if domain = example.com AND NOT cert fingerprint = ... display
warning". I would, however, suggest a special interface for this to
allow 1. easily setting up the lock-ins (right-click on lock symbol or
something like that) and 2. display locked-in and new cert side-by-side
highlighting changes. (If another, quite unknown CA issues a cert while
the old one, from a well-known CA, is still valid, it would look
suspicious to me, if the new cert is identical except for serial,
validity date etc. and the old one was nearly expired, it is probably
fine). This could keep online-banking etc. secure even if single CAs
fail and issue bad certs (or have debian keys or MD5 signatures etc.).
This function would help both inexperienced ("what is ssl?") users and
experienced users (from "I can install an extension" to "I can do SSL
with nothing but pen and paper").
Sincerely
Jan
--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
