Re: Proposal: Marking HTTP As Non-Secure

> On Dec 19, 2014, at 8:06 PM, Michael Martinez <michael.martinez@xenite.org> wrote:
> 
> 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 activity.
> 
> 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.

To be accurate, the browsers tell you that you are browsing via a secure connection, they do not say that the website itself is secure. See http://d.stufft.io/image/3p1x0r3Q3407 and http://d.stufft.io/image/0F1M1A2t0C35 and http://d.stufft.io/image/2G1F2g2j072G. In none of these do they make the claim that the website is secure, it’s just making the claim that the connection to the website is secure.

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

There is a vast difference from being able to see that someone visited CNN, and that someone visited CNN and read a specific article and possibly even modifying the content of that article.

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

I think you’re fundamentally confused, I do not believe that anyone who is making this proposal is trying to force site operators to use HTTPS. They only want to be honest about whether the connection to the website is secure or not. Some people may be embarrassed by the truth and they may change that, some other people may not care and they’ll say that people can continue to view their site as HTTP only and that’s fine.

Are you aware that this isn’t going to require people to click through any warnings? This is simply about changing the indicator on a HTTP site so that it reflects the insecure nature of the HTTP transport.

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

I think the answer to Why is because a browser should not lie to the user about whether or not the connection is secure. The user is free to decide if they want to continue browsing a site where the connection is not secure.

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

I really think you should learn what TLS is, what it provides, and how it works before continuing on in this discussion, because what TLS *IS* is a method for validating if a connection is secure. It has absolutely nothing to do with the website being served through it.

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

Again, this is what TLS does.

> 
> 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
> http://www.michael-martinez.com/
> 
> YOU CAN HELP OUR WOUNDED WARRIORS
> http://www.woundedwarriorproject.org/
> 
> To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Received on Saturday, 20 December 2014 01:33:46 UTC