W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: Proposal: Marking HTTP As Non-Secure

From: Michael Martinez <michael.martinez@xenite.org>
Date: Fri, 19 Dec 2014 20:06:51 -0500
Message-ID: <5494CBAB.3080109@xenite.org>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>, blink-dev <blink-dev@chromium.org>, security-dev@chromium.org, dev-security@lists.mozilla.org, mozilla-dev-security@lists.mozilla.org
In 1975 I landed my first programming job writing little programs on a 
mainframe computer.  We had excellent security then.  You had to submit 
your punch cards at the window and the computer operators took them and 
fed them to the machine.  30-60 minutes later you got your printout.  If 
you were lucky they matched your printout with your punch cards.  But 
other than that no one in the building knew who I was.

Whole generations of computer technology have come and gone since then 
and now I use laptops and smart phones.  Now I submit my requests via a 
browser or an app to some software on the other side (the computer 
operator fellow no longer has a job) and if I am lucky no one has 
modified the software on the other end, installed spyware on my 
computer, or is capturing my packets.  But now the Internet Service 
Provider for the access point tracks my activity; whoever owns the 
router I'm connected to may track my activity; the Web server or app 
server tracks my actvity; the advertising networks track my activity; 
and if anyone has compromised any of those potential data collection 
points, they can track my activity; and if any of those parties wish to 
sell my activity data (and many do) then third parties can also track my 

Enter into this picture the mistaken notion of "secure Websites". 
Websites are not secure.  There is no such thing.  We have encrypted 
transmission protocols.  We can encrypt the contents that Websites or 
app servers send to users, but nothing is *secure*.

Today the browsers tell us we are connected to a "secure" Website with a 
little marker.  "That's a lie," some of you say.  Quite true.  It's 
dishonest.  So now we have a proposal to change the browsers to suggest 
to the user that a Website is NOT *secure*, even though that judgment is 
made on the basis of one factor: the lack of an encrypted connection.

The implication is that any site not so designated must be *secure*, 
which is telling the same lie all over again.

Meanwhile, some of you have expressed concern that your activity in a 
coffee shop may be monitored or altered without your knowledge if you 
connect to Websites via an unecrypted connection.  Fortunately, we can 
point to funny little tools like Bacolicious that alter (and monitor) 
people's surfing activity even over HTTPS.  There are many "reader" 
sites that also do this, perhaps loading Web content into a frame, or 
maybe launching a window, or both.  So that's two ways that anyone can 
get around the supposed privacy that surfing via HTTPS confers.

Of course, the packet envelopes aren't encrypted, are they?  So if you 
really want to prevent anyone from seeing that you're visiting CNN 
you're stuck.  Somebody somewhere can see the packets. So the whole idea 
of defending browser privacy is a washout.  In most cases (maybe) no one 
is listening for those packets but we know that in some cases criminals 
are trying to steal user data (logins, credit cards, whatever they can 
grab).  The worst-case scenario does happen.  That's a given.

So how is marking some Websites as "non-secure" (they all are) improving 
the situation?  Shaming Website owners for not using encrypted 
connections, especially when your only concern is that you don't want 
some random stranger to see that you are reading a blog, is not acceptable.

First of all, no one has the moral right to shame other people for not 
using encrypted protocols when they are writing about their personal 

Secondly, demanding that the world conform to your expectations of 
privacy and then insisting that everyone else bear that burden for your 
convenience is also unacceptable.

If you have the power to change the Web, and if you take it upon 
yourselves to change the Web, then you owe it to everyone else to explain:

1) WHY it's necessary to do this (protecting your personal browsing 
habits does not count)
2) Why THEY are responsible for making the changes YOU want (your 
inability to do it for them doesn't count)
3) What is at stake if they resist your mandate

It's only fair (and ethical) to educate the broader community about what 
is being proposed and to make a fair and honest business case for it.  
They don't owe you a dream experience in secure protocol. Furthermore, 
they are going to be very upset with you when their Websites continue to 
be hacked, their personal data that was supposedly "protected" by HTTPS 
is stolen, and they have to bear THAT burden without any help from you 
as well.

The Internet is far from a perfect thing.  No one foresaw all the 
innovations that would grow from connecting two machines together at 
Berkeley.  No one foresaw these great debates about what is morally 
acceptable, what is necessary to prevent theft and fraud, and privacy.  
The technology was not designed for privacy.  It was designed to make it 
easier to share information.  That is what the Internet does.

We added security protocols here and there to protect what can be 
protected, but the protections are ephemeral.  HTTPS guards the bridges 
and intersections on a long highway, and maybe they do need to be 
guarded because those are high risk points, but the rest of the highway 
is still vulnerable.

Before you push the world to adopt HTTPS for everything, spend some time 
looking at the big picture.  In 20-30 years some of you will be in my 
position, speaking for the people who don't know enough to speak for 
themselves.  You have an opportunity here NOT to repeat the pattern of 
glib mistakes that has brought us down the road to a conglomeration of 
technological solutions that don't all work together.

There will be pushback from the Web community.  They will be constrained 
by a lack of resources, if nothing else.  That lack can be remedied with 
some changes in the way security certificates are handled, but there 
will also be expenses, and many small Website owners don't make any 
money from their sites.  They want their own domain names, their own 
cheap hosting solutions, and they don't care about whether you feel safe 
reading CNN in a coffee shop over public WiFi.

It might be better for the browser developers (the UA owners) to think 
in terms of validating the connection to the Website, and not simply in 
terms of validating the protocol being used to connect to the Website.  
Man-in-the-Middle attacks still afflict people trying to reach HTTPS 
Websites, even if you believe it's only because they are clicking past 
invalid security certificate warnings, unintentionally installing 
malware, or whatever.

The point is, HTTPS only slows the pace of MITM attacks against the user 
community.  It doesn't stop it.

How do you validate a connection?  That will take some thought. Maybe 
every URL can return a checksum that is compared to a remotely hosted 
checksum (much like DNS and security certificates).  If the browser 
cannot retrieve a checksum from the requested URL or if the checksums 
don't match, you give the user some options.

Better detection of proxy attacks from the browser would also help. The 
average user won't know what is going on but if the browser can detect a 
compromised connection then why not simply break it?  I would not expect 
100% certainty but the user can always try again.

If marking HTTPS Websites as "secure" doesn't work (largely because of 
the widespread ignorance in the general population) then why would you 
expect the alternative of marking HTTP sites as "UNsecure" to work?  The 
message will be lost on the masses.

There is no easy solution to the problem.  Please don't try to force 
something like this on everyone else.  You need to take their needs and 
concerns into consideration, too.  They already have to live with the 
consequences of not knowing which Web services are best for them.  
Having to deal with user mistrust because the browser raised an issue 
about "security" is just one more hassle that will not make the Web a 
safer place.

Keep HTTPS where it is until you can solve all the other problems, 
because promising to make the Web safer for everyone is much easier than 
actually doing it.

Michael Martinez

Received on Saturday, 20 December 2014 01:07:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC