I'm not sure I totally follow here because informed consent requires the ability to inform, and I don't think we have that yet.
The way any attacker operates is to find gaps in a system and make use of them. In my questions I'm trying the same approach: what are some gaps in the Komodia solution and how might we exploit them ourselves?
This thread seems fairly focused on a technical solution; whereas I see this problem being more of an informed consent situation.
I'm reminded of the discussion leading up to the "know your rights" toolbar and another discussion with respect to whether or not to display HTTP connections with explicit insecure visual feedback.
Those discussions leaned towards informing the user. In this case informing them that they have pre-loaded 3rd party extensions or certificates. With the right wording a power user could think "I do!? Let's investigate this." and a regular user could think "Interesting. I wonder why they'd bother to tell me - better get on with my day."
On Tue, Feb 24, 2015 at 3:54 PM Peter Kurrasch <
[email protected]> wrote:
I think focusing on the trusted root store as a way to resolve this problem is (or will be) less than ideal. I understand the desire to look there but I don't think it will necessarily end well.
That said I don't have a great alternative myself but I do have some questions:
1) I saw a quote attributed to Richard that Mozilla will blacklist or is considering blacklisting the cert(s) generated by Superfish, Komodia, and so forth. Can you comment here at all, Richard?
2) Has any analysis been performed on the "quality" of the end certs generated by the Komodia proxy? Are there obvious oversights that could be checked or enforced within Mozilla? How much work would that involve?
3) Am I right to presume that affected users did not notice that those sites with EV certs no longer were showing a green address bar? that EV itself provided no protection in this situation?
4) In this situation any sites using HSTS provided no additional benefit but did cert pinning make a difference?
Thanks.
Original Message
From: Brian Smith
Sent: Tuesday, February 24, 2015 12:05 PM
To: Daniel Veditz
Cc: Matt Palmer; mozilla-dev-security-policy@lists.mozilla.org
Subject: Re: Tightening up after the Lenovo and Comodo MITM certificates.
Daniel Veditz <[email protected]> wrote:
> I don't think we can restrict it to add-ons since external programs like
> Superfish (and the Lenovo removal tool, for that matter) write directly
> into the NSS profile database. It would be a bunch of work for precisely
> zero win.
mozilla::pkix makes it so that you can ignore the NSS profile
database, if you wish to do so.
> Could we make the "real" and only root accepted by Firefox be a Mozilla
> root, which cross-signs all the built-in NSS roots as well as any
> corporate roots submitted via this kind of program?
This is effectively what the built-in roots module already does,
except the Mozilla root CA certificate is implied instead of explicit.
> I thought pkix gave us those kinds of abilities.
mozilla::pkix offers a lot of flexibility in terms of how certificate
trust is determined.
> Or we could reject any added root that wasn't logged in CT, and then put
> a scanner on the logs looking for self-signed CA=true certs. Of course
> that puts the logs in the crosshairs for spam and DOS attacks.
Those spam and DoS attacks are why logs are specified (required?
recommended?) to not accept those certificates.
If Mozilla wanted to, it is totally possible to make an extension API
that allows an extension, when it is not disabled, to provide PSM with
a list of roots that should be accepted as trust anchors. And, it is
totally possible for PSM to aggregate those lists of
extension-provided trust anchors and use that list, in conjunction
with the read-only built-in roots module, to determine certificate
trust, while ignoring the read/write profile certificate database.
Whether or not that is a good idea is not for me to decide. But, it
would not be a huge amount of work to implement.
Cheers,
Brian
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
