[HTTPS-Everywhere] what does HTTPS-Everywhere consider a "valid" X.509 certificate? [was: Re: Custom rules]

[Chris Palmer]

Eitan Adler writes:

> > The easiest story to tell is "You are talking to the true server and nobody
> > can read or manipulate what you and the server say to each other, period,
> > the end."
> 
> But this isn't the true story.

It's the story that we need to make true.

> The correct story is "You are most likely talking to the server that
> ___ certify is the really the one you want to some degree of
> mathematical certainty"   And the story changes based on whether you
> use 2048 or 4096 bits and which algorithm is used to generate the key.

Mathematics has no place in the story because (a) people don't understand
it; and (b) it is the least important (because already strongest) element in
the security chain.

Also, I think you'll find that 2048-bit keys are rare in public web sites,
and 4096-bit keys certainly should be non-existent for now. In any case we
need to never tell a story that hinges on that (kind of) distinction.

> You are right that opportunistic encryption does not provide the same
> degree of certainty that checking certificates does. However no
> security is perfect and using opportunistic encryption raises the bar
> for an attacker.

As defenders we need not only to raise the bar, but to raise it higher than
our expected attackers can aim. Our job is hard because we are designing for
a broad audience facing a broad range of threats and threat actors --- we
can't simply say, "Well we've defeated the casual coffee-shop Wiresharker so
we're done."

http://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html

Worse, the active MITM bar turns out to both be not that high in the first
place and lower than we thought.

It is also of crucial importance to maintain engineering discipline, and not
give in to the temptation to throw cruft at the problem. (That's the kind of
thinking that got us where we are now.) "This mechanism might stop some
kinds of attacks sometimes, I think" is not good enough, because no
mechanism is free, and there is also an opportunity cost: Every
minute/dollar/brain cell we spend on cruft is one we did not spend on the
right solution.

> Given the number of false negs with bad certificates I tend to rely on
> TOFU/POP security anyways.

And false positives, yes. I am obviously a big booster of TOFU/POP, but we
still have to get our user story straight. That job is not yet done.

> Good security does not require explanation to the users. You do not
> need to explain to users that yes, the browser is trying to help you
> defeat the most common type of attack. Keep it transparent - don't
> display a lock, don't make the address bar blue/green/whatever. Just
> get the encryption.

So what will you say to users when the guarantee is broken? :)

There is no way to avoid needing to tell a security story. If we assume that
people are stupid and can't understand anything, we will get it wrong (as we
have been). People already understand and know how to deal with security
guarantees; it's just that they are used to guarantees that are stated
simply and understandably. Only the software industry sucks; other kinds of
engineers know much better how to do their job and provide meaningful and
understandable security guarantees. "If you press the brake pedal, the car
will slow down. Be aware that stopping distances are in the hundreds of
feet, and longer in rain and ice."

We need a guarantee like that.


--
http://noncombatant.org/