On 2017-03-30 07:39, Ryan Sleevi via dev-security-policy wrote:
> No, we actually only have three levels.
>
> 1. HTTP
> 2. "I explicitly asked for security and didn't get it" (HTTPS with no
> validation)
> 3. HTTPS
(2) assumes users ask for security. 99% of users do not ask for
security, they follow links that choose whether to ask for security for
them or not. In fact, the whole point of HSTS is to enforce some kind of
persistent request for security, because users aren't expected to know
to prefix their URLs with https://
(2) is also strictly more secure than (1), even though it may not meet
some arbitrary definition of "security". If it weren't, the security
community would be up in arms over SSH's TOFU model, and it isn't. That
model has its problems, but I would argue that TOFU with no validation
is closer to (3) than it is to (1), and even with no TOFU/persistence,
protection against passive snooping is still a significant plus.
Of course, now that Let's Encrypt is a thing, that's mostly moot since
everyone can get a cert, but IMO we've wasted many years by waiting
until now for a solution that sites could use to deploy encryption *at
all* with a low barrier to entry. NSA-style dragnet fiber tap
surveillance would not have worked in a world where everyone could just
use a self-signed cert for a modicum of security. Plaintext HTTP
could've been obsoleted a decade ago.
>> Obvious answer? Make (1)-(2) big scary red, (3) neutral, (4) green, (5)
>> full EV banner. (a) still correlates reasonably well with (4) and (5).
>> HTTPS is no longer optional. All those phishing sites get a neutral URL
>> bar. We've already educated users that their bank needs a green lock in the
>> URL.
>
>
> And that was a mistake - one which has been known since the very
> introduction of EV in the academic community, but sadly, like Cassandra,
> was not heeded.
Indeed, but good luck correcting it *now*. Practically speaking, we need
to work with what we have. And "green = good" ultimately extends way
beyond technology.
>
http://www.adambarth.com/papers/2008/jackson-barth-b.pdf should be required
> reading for anyone who believes OV or EV objectively improves security,
> because it explains how since the very beginning of browsers support for
> SSL/TLS (~1995), there's been a security policy at place that determines
> equivalence - the Same Origin Policy.
>
> While the proponents of SSL/TLS then - and now - want certificates to be
> Something More, the reality has been that, from the get-go, the only
> boundary has been the Origin.
I agree with the premise of that paper, but it doesn't really counter my
view. I'm arguing that EV certificates do more than endorse the public
key with further validation: they endorse the *origin* with further
validation. It's still the same origin.
The phishing threat model is not that an attacker gets ahold of a cert
for
paypal.com. That's a higher bar. EV doesn't help you there (today).
The threat model is that an attacker gets ahold of a cert for
paypa1.com
and claims to be PayPal.
EV (today) doesn't say "this server is trustworthy", it says "this
origin is a given organization" and then the regular DV properties of
the cert transitively apply. Yes, if a CA issued a non-EV cert for
paypal.com to a party other than PayPal, then a website MitMing PayPal
could steal all of its credentials without an EV cert (and httpsev://
could help prevent that). But that's a *very* different attack scenario
from what we're focusing on here, which is an attacker with an origin
that *looks* like PayPal (or not, many users don't even care).
> But if folks want OV/EV, then they also have to accept there needs to be an
> origin boundary, like Barth/Jackson originally called for in 2008
> (httpsev://), and that any downtrust in that boundary needs to be blocked
> (similar to mixed content blocking of https -> http, as those degrade the
> effective assurance). Further, it seems as if it would be necessary to
> obtain the goals of 4, 5, or (a) that the boundary be 'not just'
> httpsev://, but somehow bound to the organization itself - an
> origin-per-organization, if you will.
SOP aside, that's the point of displaying the organization name in the
URL, is it not? IMO the point of EV is to allow a user to determine that
the origin they are currently accessing is controlled by the legal
entity displayed in the URL bar.
This does not afford protection against "Bob G. Parker hijacks PayPal's
IP and gets a DV cert for PayPal and steals everyone's password", but it
does afford protection against typical phishing sites. Creating a
separate origin for EV, or per-organization, strengthens this, but the
lack thereof does not make it useless.
The value of OV is less clear, but still nonzero over DV. It at least
implies that the certificate was issued with some amount of legal
validation, which presumably affords higher chances of catching abuse
attempts than automated DV issuance.
> And that, at its core, is fundamentally opposed to how the Web was supposed
> to and does work. Which is why (4), (5), and (a) are unreasonable and
> unrealistic goals, despite having been around for over 20 years, and no new
> solutions have been put forward since Barth/Jackson called out the obvious
> one nearly a decade ago, which no one was interested in.
Is it? This is a philosophical discussion, not a technical one. I think
there is value in having some assurance (against some threat models at
least) that you are talking to a given legal organization. Trust is
hard, and trust based on anonymous identifiers should always be
supported (enabling decentralized determination of trust), but some
organizations operate strictly within the framework of a legal identity,
and I don't see why we shouldn't have *some* way and process of
exporting that legal identity to a user.
Ultimately, if EV is not the answer, we need *some* way of having users
be aware of who they are interacting with. Any suggestions?
--
Hector Martin (
mar...@marcan.st)
Public Key:
https://mrcn.st/pub