Frank Hecker wrote:
http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/#risks
Which risks and threats are you concerned about in connection with certificates and CAs?
As noted previously, we are concerned with the risks borne by typical users arising from the various certificate-enabled operations for which they might use Mozilla, namely
* browsing to SSL-enabled web sites or connecting to other SSL-enabled servers (e.g., for IMAP, SMTP, etc.) * sending and/or receiving signed and/or encrypted S/MIME email * downloading and installing and/or executing digitally signed code
For SSL-enabled browsing the most commonly-discussed risks are associated with scenarios in which a typical user believes they are communicating with an SSL-enabled web site (or other server) associated with a certain entity (e.g., their bank, a shopping site. their ISP's SSL-enabled mail server, etc.), but in reality they are communicating with another web site or server, operated by an attacker. The major risk here is that an attacker operating the second site will obtain sensitive information relating to the user, whether entered by the user (e.g., where an attacker is "phishing" for passwords) or transmitted by the original site (e.g., where a "man in the middle" attacker is eavesdropping on the user's connection).
Having read this, I can only say it is summarily brief, but not inaccurate. To concentrate on the phishing exposure is valid as it is the only actual case where empirically the security model is being breached with frequency. To ignore other threats like straight eavesdropping or deceptions at the CA point seems valid given the shortage of evidence *and* the lack of space. But, see the next two points.
Also, it might be worth clarifying that phishing is a cert problem and is outside the CA's hands (because it in general bypasses the SSL security system completely).
The onus is on Mozilla to deal with phishing, in the first instance, I don't think there is anything that a given CA could do to deal with it, unless it is bang on browser people to start thinking about it. Until browsers can show the difference between cert usage and non-cert usage "in the user's face" then phishing will roll on past the cert. And until it becomes routine to use users to perceive certs in a branded fashion for all transactions, CAs are cut out of the loop.
Mind you, if we *could* blame the CAs for phishing, we'd feel a lot better, and maybe it would help in the long run ;-)
There are also at least two other risks associated with SSL-enabled web browsing and other SSL-enabled operations:
First, it may be that the user is actually connected to the "correct" site or server, but the user is led to believe that he or she is not properly connected to that site; the risk here is that the user may not take a desired action based on this false conclusion.
I don't understand where this comes from, is this an actual attack model with real live results going on? I.e., empirically valid? If so, where? (as I've not heard of it, and feel ignorant.)
Alternatively, if it is only a theoretical attack, then it sits more properly in a full list of such attacks, and we need to consider all of them fairly, without discrimination amongst our pets and favourites.
Or, thirdly, does this imply that some CAs are sending out less-that-perfect certs that are fooling Mozilla into acting incorrectly? If so, I'd say that: a bug in a cert layout is considerd a risk, including where one CA and one browser share the bug and thus attempt to create a defact standard.
> Finally,
the user may encounter some software malfunction (e.g., a browser crash) due to some aspect of SSL and certificates; again, this would possibly prevent the user from taking some desired action.
Ditto.
For S/MIME-enabled email the most commonly-discussed risks are associated with scenarios in which the user believes that they are communicating with the owner of a given email account (whether that owner be a person or entity), but in fact the email messages in question are being received from or by another (possibly malicious) person or entity.
I suggest you adjust this to include mention that there are two modes here. Something like:
...but in fact the email messages in question are being read by another (possibly malicious) person, whether done by inserting in the middle and playing both ends (MITM) or by simply pretending to be the other person (spoofing).
(I'm not sure of this, myself, it just feels better to mention the two modes. Also, the definitions of MITM and spoofing, etc, are not actually seriously agreed amongst security people, so you might be more comfortable leaving this out. E.g., whether phishing is MITM is a matter for the semanticians.)
> As a result the user runs the risk of exposing
sensitive information (e.g., sent in an encrypted email read by an attacker) and/or taking inappropriate actions based on information the user believes to be trustworthy
This equally applies to all of them, rather than just email. At least, to browsing, less so to code signing.
(e.g., a "phishing" site's URL contained in a signed email sent by an attacker).
If this has actually happened - there has been signed phishing attacks - then fine. If it has never happened, I'd leave it out. There's enough confusion in attack models as it is.
For downloadable signed code the most commonly-discussed risks are associated with scenarios in the user believes
in WHICH the user ?
that the code in question originates from a particular person or entity known to the user (e.g., a commercial software vendor, or an open source developer), but in fact the code originates from some other source, e.g., an attacker developing "trojan" programs, or a company distributing "spyware" or "adware". As a result the user might execute code that harms the user's system or exposes sensitive information.
It might be helpful to mention that code signing is a relatively new feature (and thus the attacks mentioned are more envisaged as fears than validated as risks).
As with SSL-enabled web browsing and S/MIME email, there are also risks associated with scenarios in which the user falsely concludes that the downloaded code is associated with the wrong person or entity, as well as risks associated with browser malfunctions due to problems related to code signing and certificates.
Note that many of the risks and threat scenarios discussed above could result from factors unrelated to CAs and certificates. To take but one example, it is possible that an attacker might exploit a non-SSL vulnerability in Mozilla to cause the browser's status bar and/or URL input field to display an incorrect site name when connecting to the attacker's web site.
OK.
iang _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
