Re: Proposal: Marking HTTP As Non-Secure

On 2/8/2016 5:35 PM, ianG wrote:
> On 8/02/2016 09:58 am, Craig Francis wrote:
>> Hi Kevin,
>>
>> I'm more of a web developer, but my opinion is that all web traffic
>> should have always been encrypted.
>
> I'm curious ... Is that your opinion because you've been taught that?
> Or because you've done a risk analysis over a group of people and
> opined that the cost of encryption is worth it to them to encrypt
> against the cost of eavesdropping?
>
> Just to declare my colours here - I don't know of too many efforts
> that have taken that second step... so .. why do we believe it should
> all be encrypted?
>
> I'm not disagreeing.  I also believe it should be encrypted.  But, why?

Because the imposition of an insecure security policy unilaterally by
one side of the communication necessarily ties the hands of anyone who
has reason to fear guilt by association with the information that
they're known to have accessed.  In other words, it takes the choice
away from someone who might have very good reason to need the
information, but not be seen to access the information.

(Imagine a teenager in a sex-negative home trying to obtain information
about sexuality from a site like scarleteen, across a network that their
parents monitor.  This is a harm that their parents are doing not only
to their child, but also the the rest of society, by enforcing that
someone who is going to be sexually active doesn't learn anything about
how to limit the spread of disease or premature pregnancy.  In this
case, the teen is trying to be socially responsible and their parents
are trying to prevent that.)

(Imagine a suicidally depressed gay teenager in Russia trying to get
information on being gay and the fact that they're not actually insane
for getting those feelings for their same gender and not for the other
gender.)

(Imagine someone doing harm reduction work in a vulnerable population of
[e.g.] heroin or methamphetamine addicts, who might otherwise be
incarcerated or used as a means of identifying/incarcerating the
vulnerable population if they were found out.)

>> It's only because of the initial difficulties (hard server setup,
>> processing time, etc) that this wasn't the case.
>
> Yeah.  History really screwed us over on this one...

The thing that stopped me was "mandatory payments to CAs".  This was
another decision by "people who knew better" attempting to enforce a
security policy on those for whom the one-size-fits-all security policy
didn't fit the needs of.  I -spent- the effort learning how to set it
up, way back when.  I -spent- the processing power in my
non-CA-certified connections.  Back then, I had to deal with people
trying to use the non-time-limited beta of Netscape 0.94, and I couldn't
meet their needs because Verisign was too damned expensive, had
apparently-insane documentation requirements, and its issuance interface
was impossible to navigate.

>> Would you write everything on a postcard? or would you at least put
>> the letter in an envelope?
> People choose either/both all the time.

Yes, but do you ever see a bank sending a statement on a postcard?

>> Most people use envelopes as a very basic/simple way to ensure the
>> letter is not read or altered by anyone else on route... for example,
>> you can typically tell when an envelope has been opened (ish).
>>
>> Unfortunately an envelope isn't as good as modern encryption (e.g.
>> giving you any confidence that the message you received actually came
>> from the right person).
>>
>> Whereas plain text HTTP is even worse than using a postcard (it's
>> very easy to change its content, as you don't see words being crossed
>> out, or being written in a different hand writing style).
> So, the topic of metadata.  People go on holiday and send postcards.
> They're being tracked by copies.  People are trained to write their
> address on the back of envelopes.  Incoming into every country, front
> and back of every envelope is photographed.  Meta data is collected.
>
> Which is to say, it's fine to use analogues and metaphors.  But
> actually, nobody much is doing any serious threat analysis to users in
> current day.
>
> If they were to do that, I think they'd be shocked.

Isn't this why everyone was actively trying to create non-paper
communications mechanisms for quite a while?

But the topic of metadata ignores the "too easy to forge with no means
of detection" argument.

>> I certainty take your point that HTTPS is currently more difficult
>> than it needs to be, but with systems like LetsEncrypt, we will have
>> this built into the web servers soon, and it will do all the setup by
>> itself, you won't even need to "switch it on"... and it's at that
>> point, we can say HTTPS is just "normal" (to the point we don't even
>> need to show a padlock) and that anything still using plain text is
>> simply insecure.
>
> We need likely 10 or 100 systems like LetsEncrypt, or self-encryption,
> or both.  Then it might work.  I'm not saying today is bad, I'm saying
> we need to do much more.  And not listen to any "ivory tower" thinking.

X.500 style identity attestation is good, but only for those things that
need it.  It's not good for those things that don't need it.  When
boiled down, there's several needs that each have a different "best way
to meet the need".  But we can't even get OpenPGP certification of TLS
into the browsers, much less any other mechanism for certification that
we know (based on our own operational protocols) who we're talking to.

-Kyle H