On Wed, Dec 13, 2017 at 4:46 PM, Tim Shirley via dev-security-policy < [email protected]> wrote:
> As I understand it, Adam’s argument there was that to get value out of a > revoked certificate, you need to be between the user and the web server so > you can direct the traffic to your web server, so you’re already in > position to also block revocation checks. I don’t think that maps here > because a lot of the scenarios EV assists with don’t involve an attacker > being in that position. > Well, no, that's misunderstanding the point. The revocation checks themselves are the placebo - because they are not hard fail, you don't get benefit from doing them, precisely because they can be blocked. However, they cannot be hard fail, because the failures are expected under non-adversarial models. So because hard fail is not viable (and Rob's recent sharing of OCSP status of CAs truly captures that better than a thousand words on the topic), nor even if CAs had sound infrastructure is it viable on the "internet at large" (that is, CAs are definitely the worst, but even if they were perfect, it'd still be unacceptably bad), then revocation doesn't provide value. The same argument being applied to EV here is that the presumptive value of EV is that it either provides technical mitigations OR the display to the user provides sufficient value to allow for an informed decision. However, the technical mitigations are non-existant, and the value of the display is not sufficient enough on an adversarial model. In both cases, much like hardfail, the structural deficiencies mean that the system is unreliable, and because the system is unreliable, it should not be relied upon during critical times. It is the weak link. I know for non-security folks, this seems like throwing the baby out with the bathwater, because it's "mostly good". But much like broken messaging encryption is still broken, even if it's encrypted, the flaws of EV are systemic, and mean you cannot and should not rely upon it (and of course the EVGs disclaim reliance for a number of cases), and so the whole notion of it is flawed. If you cannot rely on it, why rely on it? > > I know the question has been raised before as to why most phishing sites > use DV. Some argue it’s because OV/EV are harder for people with bad > intent to obtain. Some argue it’s because DV is more ubiquitous across the > web and thus more ubiquitous on phishing sites. But regardless of which > (or neither) is true, the very fact that EV certs are rarely (never?) used > on phishing sites is in and of itself providing protection today to those > of us who pay attention to it. I’d argue that alone means the seat belt > isn’t worthless, and we should focus on building better seat belts rather > than cutting them out and relying on the air bag alone. > "The very fact that EV certs are rarely (never?) used" is, of course, unsubstantiated with data. It's a logically flawed argument - you're presuming that non-existence is proof of non-existence. The irony is this is the same argument made 10 years ago with certificates in general (flashback proof - http://voices.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html ) - that certificates prevented phishing, because you never saw phishing on HTTPS. Such arguments are both logically unsound and do not reflect on what phishing/fraud are used for, or in general, how security works. It also underscores the continued user-hostile message - which is to say, the user is responsible for inspecting this UI, 100% of the time, if they want to be safe from phishing. It doesn't align with the HCI research on positive indicators, nor is it a fair or reasonable thing to ask of the average user. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
