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

Eitan Adler lists at eitanadler.com
Tue Oct 19 11:33:05 PDT 2010


On Mon, Oct 18, 2010 at 1:36 PM, Chris Palmer <chris at noncombatant.org> wrote:
> 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.

That is impossible. You can make the bar very high - but it never
possible to make something 100% secure.

> 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."

You seem to be misinterpreting my enthusiasm for opportunistic
encryption as a be all and end all. I do not view it that way. For the
same reason that locks on a car are better than no locks more
encryption is better than none.
>
>> 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.

Agreed. Yet cars still have automatic breaking for the worst case. It
won't help everything but it raises amount of things that have to go
wrong before bad things happen.

The biggest problem with security today are the users themselves and
we need to find better ways to inform users of what is going on.

To be clear: Getting a working, verifiable, encryption infrastructure
with an insanely low chance of failure is a good idea. I am supportive
of such efforts. However, we can take advantage of the infrastructure
currently in place to raise the bar that an attacker has to go through
before successfully completing an attack.

My proposal is for browsers to show "http" in the toolbar (or httpE if
not saying anything is a problem), don't display a lock, don't
indicate any security whatsoever - but when possible make a https
request even if the certificate is self signed.

> --
> http://noncombatant.org/
>



-- 
Eitan Adler



More information about the HTTPS-everywhere mailing list