diff options
| -rw-r--r-- | https-cuts.txt | 196 | ||||
| -rw-r--r-- | https.txt | 250 |
2 files changed, 284 insertions, 162 deletions
diff --git a/https-cuts.txt b/https-cuts.txt new file mode 100644 index 0000000..f3ca627 --- /dev/null +++ b/https-cuts.txt @@ -0,0 +1,196 @@ + +This is why the question Winer and others would like answered is so simple: why? Why should we invest all this effort to encrypt websites that are just archived flat HTML pages? + + + +Before we get to that though, it's worth looking at some of the technical shortcomings of HTTPS the way it is currently implemented on the web. These too are costs. + +HTTPS affects a site's ability to cache data. This is a big problem in remote areas where ISP level caching can be the only realistic way for many people to connect over slow networks. HTTPS connections themselves used to be slower, but this is no longer the case with modern browsers. The [HTTP vs HTTPS test site](https://www.httpvshttps.com/) demonstrates how HTTPS can actually be faster over HTTP/2 (which is only available over secure connection). + +Another technical shortcoming is the use of Content Delivery Networks. CDNs reduce network latency by redirecting the user to a closer server, but CDNs are the man-in-the-middle, they're just not a "attack". However, the way CDNs work today website owners often need to [upload their certificates and private keys](http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6956557), negating many security benefits of having those in the first place (if your secret key is not entirely in your control it's no longer secure). + +There are also a host of problems surrounding certificate authorities, the "trusted" source of certificates. CAs have been compromised in the past and will be in the future. This is in fact the weakest part of HTTPS. It's also the part that will be most difficult to fix since it will require reworking the entire trust chain from the ground up. + + +But before I get into why, it's important to know that while everything you do over HTTPS is secure and authenticated there is one one bit of data leaks out in this scenario -- the name of the site you're visiting. As noted above Russia (or anyone else) can see that you're headed to wikipedia.org, but no one knows which page on Wikipedia you're requesting. + +That means anyone snooping on your browsing session right now can get one bit of metadata -- they know you visited arstechnica.com. They don't know you're reading this specific article, but they do know you visited the site. Before you dismiss this metadata leak as unimportant, consider that the former head the NSA has publicly announced that the U.S. will "kill people based on metadata", even though, it seems, [many of those people may have been innocent](http://arstechnica.co.uk/security/2016/02/the-nsas-skynet-program-may-be-killing-thousands-of-innocent-people/). +Encryption is good. It means that without the encryption key no one else can see what you're doing. If you're specifically targeted by the NSA HTTPS is not going to save you, but that's not the point. Or rather it is. The point is that HTTPS returns surveillance to being a more difficult and targeted exercise. As HTTPS proponent Eric Mill tells Ars, "HTTPS moves attacks from bulk to targeted". + +Targeted attacks are more difficult and require more resource than most interested parties have available. The NSA can still pull it off, Verizon, probably not. + + +Much of the confusion comes from our tendency to conflate security and privacy. While security is often necessary for privacy, the security you have does not guarantee anything. For example, you can have a secure HTTPS connection to Google, but that doesn't actually mean anything for your overall privacy. Google can still collect information about you, track you with cookies and then be compelled to give that information to the government. It can also just sell it to the highest bidder. Security is not a guarantee of privacy. + +All the users whose data has been compromised in any of the hundreds of major data leaks from Target, tk, tk, or tk was collected over HTTPS connection. Security is not privacy. + +In the case of HTTPS the primary things that the "S" offers is protection against what's known as a Man in the Middle (MitM) attack. Imagine you're at a coffee shop chatting with what you think is your friend tk. browsing tk for a tk. You decide to buy the tk. You're connected to tk, but someone else at the coffee shop (most likely wearing a dark hoodie and hunched furtively over a laptop if the press is to be believed) is watching you connect to tk. Hoodie can impersonate tk + +A MitM attack + + + + + +###Broad questions: + +How does HTTPS help users? +great cannon attack 2015 + +Does it stop nation state attacks by the NSA et al? +tls dns hijacking anti-virus super phish vulnerability -- fake root to inject ads. attacks go lower level cert flaws. + +Does it protect user privacy, if so how? All the tracking cookies are still there. If the NSA wants them they just subpoena Google right? + +It stops man in the middle attacks. How common are those? Does anyone have any data on that? Bogeyman, accessible metaphor, but practical use it's unlikely to happen. + + + +--- + +###Cert flaws: + +Verizon injecting code to reconstruct cookies. If they're willing to do that, what's to stop them from including compromised certs that allow them to still inject the code? They control the platfor, that's unbeatable from the security standpoint. + +"Even if the browser, OS were under your control you have no control over what the web application is doing with your data. Not only could it be being shared with servers through third-party sub-requests, it can also be passed server-server to thousands of other entities and often is. + +Link security != privacy. Privacy needs the rule of law not total secrecy." + +https://lists.w3.org/Archives/Public/www-tag/2015Jan/0091.html + +--- +> +> Also wondering whether, apropos the recent debates about moving to +> HTTPS, companies like Verizon would be able to MITM HTTPs traffic to +> play games like this. Seems to depend on the cert control provided by +> mobile browsers, and I'm concerned that in practice many of the +> browsers come from the ISPs, which supply the phones, which check the +> certs.... +> + +This has been going on for ages. What's new is categorizing it as MitM +with all the "attack" connotation baggage that brings along with it, in +the use case where it's opted into. Or considering it in terms of mobile +Internet. Others have long called it a "business model". Sometimes it's +opted into by agreeing to a TOS, where I'd prefer opt-in based on users +having to configure browser settings for it, but I see where if that +was the business I was in, I'd think otherwise. Either way, I hesitate +to call it fraudulent outright. + +https://lists.w3.org/Archives/Public/www-tag/2015Jan/0173.html + +--- + +###technical details: + +LetEncrypt is great, but it's still way beyond the capabilites of your average blogger installing wordpress (or more likely clicking a button to install wordpress). Even if it were a one-click process to create, install and configure a cert, how does the blogger even find out that this is something they need to do? + +designed for helping servera admins, the no tech are using hosting services. it's getting easier. peole are becoming more dependent on hosting services. + +Let's say I managed to figure all that out (which I have just for the record) who is going to renew my certs when I die? Or if I just stop caring/maintaining my site? + +you already need to have server patches, etc + +Tim Berners Lee has called the move from http to https, "arguably a greater threat to the integrity for the web than anything else in its history." Given that URLs breaking, changing and disappearing is already a massive problem, and that this move WILL ABSOLUTELY MEAN MORE BROKEN SITES, how is that a win for the web? + +On browser indicators, there have already been studies that show no one pays any attention to them: "We also found that the security certificate cue was not used by the participants to determine the legitimacy of the presented Websites." http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6454330 + +--- + +https://lists.w3.org/Archives/Public/www-tag/2015Jan/0080.html: + +> Also wondering whether, apropos the recent debates about moving to HTTPS, +> companies like Verizon would be able to MITM HTTPs traffic to play games +> like this. Seems to depend on the cert control provided by mobile browsers, +> and I'm concerned that in practice many of the browsers come from the ISPs, +> which supply the phones, which check the certs.... + +A code-signed browser from a trustworthy source, consulting only its +own trust anchor store and/or enforcing key pinning and/or enforcing +Certificate Transparency, can generally enforce the guarantees of +HTTPS (which include stopping these cookie insertion attacks). + +Of course, if the platform is under the control of someone other than +the owner, such as the carrier, the platform can subvert any +application at run-time. + +That underscores the importance of getting one's platform from a +trustworthy vendor. But that problem is entirely outside of TAG's +scope. + +HTTPS is what we can do. Buttressing the web PKI is what we can do. So +we do. Some companies with representatives on this list are also +trying to provide trustworthy platforms to run apps on, too. So we do. + +Surely, you weren't hoping to use evidence of application-layer +attacks as a reason to not adopt effective application-layer security +techniques. + +--- + +https://lists.w3.org/Archives/Public/www-tag/2015Jan/0083.html + +On 1/16/2015 2:54 AM, Chris Palmer wrote: +> Surely, you weren't hoping to use evidence of application-layer +> attacks as a reason to not adopt effective application-layer security +> techniques. + +No, but I think the TAG can play a useful role in documenting which of the +problems we see "in the wild" the move to HTTPS will "solve", which it +won't etc. Not everything we do as a community or that the TAG does can be +100% effective, but IMO a key role of the TAG is to document tradeoffs, and +to explain both the strengths and weaknesses of any proposed architectural +change. In this case, many readers of TAG Findings will be less informed +than the TAG. I think it will be helpful to clearly say: "This is what we +can reasonably expect the move to do for HTTPS to do for you; these are +some of the problems you might naively expect it to solve that it might not." + +--- + +### Interesting arguments + +https://lists.w3.org/Archives/Public/www-tag/2015Jan/0029.html + +As I understand the statement, it means some people would prefer privacy and security, and others prefer convenience and entertainment. + +This might just be projection. In some things, I am intensely protective of my privacy and security. In other matters, I couldn't care less about it. And while I'm far from infallible, I am regularly able to make reasonably informed decisions which demonstrate that I don't hold carefully to one or the other side of this apparent dichotomy. + +... + +FWIW I am not a fan of surveillance. But I note Russia is where Edward Snowden lives, for his own security. + +--- + + +If people want me to believe this is going to be handled competently, they need to stop pointing to vaporware as a solution, stop pointing to unusable crap as a solution, stop saying "Oh, it will work itself out." Because that's what I'm afraid of. Mozilla needs to acknowledge that at the moment, the TLS ecosystem is in absolute shambles, and switching to HTTPS-only is a terrible idea right now. Then I'll believe they're being realistic in their plans. + + +https://www.reddit.com/r/programming/comments/35vm9r/were_deprecating_http_and_its_going_to_be_okay/cr8lg3u + +--- + +Thoughts on security: + +Yves Lafon wrote: +> +> And saying that the only solution for people with poor bandwidth is +> to get rid of their security is not really satisfying. +> + +Privacy. Again, sorry. But security, when required, makes me not care +about bandwidth or latency. If I'm after the balance in my checking +account, I don't care if logging in takes 30 seconds. What I don't need +is for every page I access to be that slow. + + +Potential future problems with tiered content : + +In a post-net-neut world, everyone would have poor bandwidth and +latency, except when accessing the "fast lane", unless shared caching. +Sacrificing shared caching in the name of privacy which can't be +guaranteed at the application-protocol layer anyway, is not really +satisfying. + +https://lists.w3.org/Archives/Public/www-tag/2015Jan/0031.html + +--- @@ -1,249 +1,175 @@ -Google, Mozilla, the EFF and others are and have been for some time pushing for websites to adopt HTTPS. Moving the bulk of the web from regular HTTP, which is an unencrypted connection that anyone can intercept, record and even manipulate, to HTTPS, which is encrypted and (reasonably) secure is overall a huge win for the web, which is to say us, the users of the web. +Google, Mozilla, the EFF and others are and have been for some time pushing for websites to adopt HTTPS. That push is about to get a boost from Mozilla and Google when both company's web browser begin to actively call out insecure websites. -Changing the web to HTTPS is not, however, entirely without costs and challenges for web users and for website owners. The question is, do the benefits justify the costs? To answer that we have to first look at what HTTPS gets us and what it costs. +HTTPS has been around nearly as long as the Web, but it's primarily used by sites that handle money -- your bank's website, shopping carts, social networks and webmail services like Gmail. The extra "S" in an HTTPS URL means your connection is secure and it's much harder for anyone else to see what you're doing. -The major benefit of HTTPS is encryption. When your browser connects to a website over HTTPS the connection from your browser to the page you want to view is encrypted. Any data exchanged is not visible to anyone else snooping the network. And by anyone else I mean just that, anyone, could be Google, Verizon, the suspicious looking pale kid in the black hoodie sitting in the corner at the coffeeshop. +On today's web everyone wants to see what you're doing. And as long as you're using HTTP, they can. -Having an encrypted connection gets you one other thing -- authentication. +Changing the web over to HTTPS will not get rid of tracking cookies, nor will it stop nation states with the resources to launch hardware-based attacks. -Knowing that no one else on the network can read your traffic is good, but totally meaningless if you can't verify that the site you're visiting is actually the site you want to visit. To authenticate your connection to the site you're trying to visit your browser maintains a list of known, trusted certificate authorities. When your browser requests a secure page it gets the page's security certificate, which contains a chain that leads back to a certificate authority. If that authority matches an authority known to your browser then your browser will trust that the site you're connecting to is who it claims to be. +HTTPS will, however, stop some of the mass surveillance that currently happens on the web. It will stop your ISP from injecting code to track you, it will stop unknown parties from using your browser to launch DDoS attacks as you browse and it stop ISP and nation states from censoring specific pages they don't like. -This is the single biggest problem with HTTPS. More on this in a minute. +Moving the bulk of the web from HTTP, which is an unencrypted connection that anyone can intercept, record and even manipulate, to HTTPS, which is encrypted and (reasonably) secure, is a big win for the web, which is to say it's a win for the users of the web. -Behind the scenes what handles all the encryption and authetication is a bit of technology know as TLS, which is short for Transport Layer Security. In fact the full name of HTTPS is really HTTP over TLS. TLS is the successor to the now vulnerable Secure Sockets Layer (SSL), though just to further complicate things you will often hear both referred to as "SSL". TLS is made up of two layers, the TLS Record Protocol and the TLS Handshake Protocol. Together these two tools allow your web browser to securely connect to a validated site and encrypt all your communications thereafter. +This is important to bear in mind because it's also a win for some big companies which like to tout that it's a win for the web without mentioning that it also protects their bottom line. More on that in a minute. -Only one bit of data leaks out in this scenario -- the name of the site you're visiting. When your browser loads arstechnica.com it must first ask a DNS server to translate arstechnica.com into a numeric IP address. The process of querying a DNS server is (currently) not encrypted. +Changing the web to HTTPS is not, however, entirely without costs and challenges for both web users and website owners. -That means anyone snooping on your browsing session can get one bit of metadata -- they know you visited arstechnica.com. They don't know you're reading this specific article, but they do know you visited the site. Before you dismiss this metadata leak as unimportant, consider that the former head the NSA has publicly announced that the U.S. will "kill people based on metadata", even though, it seems, [many of those people may have been innocent](http://arstechnica.co.uk/security/2016/02/the-nsas-skynet-program-may-be-killing-thousands-of-innocent-people/). +The question is, do the benefits justify the costs? To answer that we have to first look at what HTTPS gets us and what it costs. -Now that you know what HTTPS offers -- encryption and authentication -- it should hopefully be obvious why your bank uses it, why Gmail, Facebook, Twitter and any other site you log in to uses it, or should (if you login into to site without it, stop visiting that site). +## What HTTPS Does For You -What's less immediately obvious is why *every* site needs to be HTTPS. In fact there has been considerable push-back against the effort to push the web to all HTTPS, all the time. Developer Dave Winer [calls HTTPS](http://scripting.com/liveblog/users/davewiner/2015/12/18/0667.html) "expensive security theater". He writes, "I have a couple dozen sites that are just archives of projects that were completed a long time ago. I'm one person. I don't need make-work projects, I like to create new stuff, I don't need to make Google or Mozilla or the EFF or Nieman Lab happy." +Any secure protocol offers three things to the user: secrecy, integrity and authenticity. In the case of HTTPS the first two come from encryption. The major benefit of HTTPS is encryption. It provides authenticity as well, but currently authenticity is its weak point. -Winer is not alone. Anyone who has put in the effort to get HTTPS working on even one site knows that it can be a tremendous hassle. Indeed this is probably the biggest obstacle to widespread HTTPS adoption. It's hard. Ars has a tutorial that clocks in at tk words. The tutorial I used to get HTTPS working on my site was written by developer Eric Mill and is tk words. +As the EFF's Jacob Hoffman-Andrews, lead developer on Let's Encrypt, tells Ars, encryption is a "necessary minimum bar" for today's web. "if we were designing the internet from scratch today," he says, "we would say encryption is cheap and easy, there's no export [restrictions anymore](https://en.wikipedia.org/wiki/Clipper_chip), so it will be default and you won't have to worry about it." -First you need to get a certificate, which is not free. There are certificate authorities who do not charge to issue certificates, the best known of these is probably StartSSL, but if you ever need to revoke your certificate for some reason there is a fee. In other words the certificates are only free if nothing ever goes wrong. If something does go wrong and you need to revoke a dozen or more sites it quickly gets expensive. +When your browser connects to a website over HTTPS the connection from your browser to the page you want to view is encrypted. That means any data exchanged is not visible to anyone else snooping the network. Without the encryption it's easy to perform what's known as a man in the middle attack. -Once you have a certificate you have to install it and get your web server to serve it up properly. Provided you have a basic sys-admin's knowledge this isn't too hard, though tweaking it until you get a A+ grade on SSLLab's test can take many, many hours. I've been running my own site, building my own CMS and running servers on the web for over a decade an I can say without hesitation that getting HTTPS working on my site was the hardest thing I've done on the web. +A simplified way to think about this is to think about the connection you made to get this page. When your browser requests http://arstechnica.com it sends that request out to the Ars server which then sends the requested page back as a stream of packets that your browser assembles into the page you requested. -There is hope on the horizon though. The EFF and Mozilla have partnered with some other big names to create Let's Encrypt, which offers free certificates -- yes, really free, no catches -- and a tool that makes installing and configuring them pretty simple. It's still (currently) a command line tool that requires basic sysadmin knowledge (and SSH access to your server) to use, but it makes getting HTTPS leaps and bounds easier than it was just a year ago. +Both the request and the response are just plain text bit of data. All a Man in the Middle attack does is step into that stream of data and start reading and manipulating it. If your ISP wanted to add an advertisement to this page that requires you to click on it before reading the story, it could do that by just injecting a few packets of its own. You would have no way of knowing whether that ad came from Ars or some other source. Anyone could in fact do just about anything to the data traveling between the Ars server and your browser, including serving up an entirely different page or not showing the page at all. -Over the long run Let's Encrypt is hoping to partner with popular web hosts in such away that users looking to set up their own blog using popular CMS like WordPress get an HTTPS site up and running as easily as clicking a button. +This is not a theoretical problem, the man in the middle code injection is an active, widely used attack. In some cases it's even a business model. -That day isn't quite here yet though and so the question Winer and others would like answered is simple: why? Why should we invest all this effort to encrypt websites that are just archived flat HTML pages? +The list of examples here is too long to cover in such a short space, but there are a few that deserve mention. The first is Verizon Wireless's so called Perma-Cookie. Verizon Wireless modifies traffic on its network to inject a tracker (it added an HTTP header called X-UIDH) is then sent to all unencrypted sites that Verizon customers visit. This allows Verizon to, in the [words of the EFF](https://www.eff.org/deeplinks/2014/11/verizon-x-uidh), "assemble a deep, permanent profile of visitors' web browsing habits without their consent". -Several years ago I wrote a piece on the then nascent effort to get HTTPS more widely adopted. At the time I wrote "For sites that don't have any reason to encrypt anything... HTTPS just doesn't make sense." +Verizon is not alone. It's a safe bet that your ISP is doing something similar. Comcast's wifi service [already does](http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/), as does [AT&T's](http://arstechnica.com/information-technology/2015/03/atts-plan-to-watch-your-web-browsing-and-what-you-can-do-about-it/3/) (you can opt out, for a fee). What your ISP does with this data is less well known, but it's a big part of why Google wants the web to move to HTTPS. -I was wrong. +When you communicate in plain text over the network you have to assume that someone is, at the very least watching and very probably injecting some tracking code to record your requests. -In 2010 when I wrote that the network of the web looked fairly benign (as Snowden's leaks of revelled, it was not, but most of us had no real way to know back then). Since that time the network has become hostile, incredibly hostile. +An encrypted connection on the other hand is not plain text anyone can read, it's encrypted text. There is no way to read or manipulate cypher text without the encryption keys. Score one for HTTPS which can guarantee that you are getting the content your browser requested. -The web has become a broad survellance tool for everyone from the NSA to Google to Verizon. +HTTPS also prevent the kind of censorship that happens at state or ISP level. Examples of this abound as well, for example, Russia wanted to ban a Wikipedia article (about [charas hashish](https://en.wikipedia.org/wiki/Charas)), but because Wikipedia is served over HTTPS there's no way to see which page visitors are requesting. Russia was faced with the choice: ban all of Wikipedia or none. It [opted for none](https://www.eff.org/deeplinks/2015/08/russias-wikipedia-ban-buckles-under-https-encryption). -tk bit here on how HTTPS isn't going to help you if you're targetted by the NSA. What an crypted web does is force survelliance to be expensive and targeted rather than ceap and broad. +Score another one for HTTPS, because as it turns out unencrypted networks do not, as early web enthusiasts liked to say, "see censorship as damage and route around it". In fact unencrypted networks make censorship very easy, just reach in and block what you want, change what you want. But with HTTPS the network doesn't actually see anything and that's a good thing. -Winer calls out Google specifically and he's not the only one to do so. Google's motives for pushing an HTTPS web are because an HTTPS web is in Google's best interest. Google is very protective of its search algorithms and results. However, according to some sources Verizon and other ISP have been injecting code into HTTP connections to gather data about search results and what people are clicking. This data is then resold in backroom deals. +Having an HTTPS connection offers one other thing that benefits users -- authentication. -Yes, Google's acting in its own best interests and Winer is right to question the motives of a company so massive it has the power to potentially control elections. However, in this case Google's interests are aligned with the web at large. Google doesn't want that data captured and sold, but remember that data is actually about you. It's your data first and foremost and even if you don't want to exist at all, you certainly don't want it bought and sold. +Knowing that no one else on the network can read or tamper with your traffic is good, that gets you secrecy and integrity. But you also want to verify that the site you're visiting is actually the site you want to visit. +To authenticate your connection to the site you're trying to visit your browser maintains a list of known, trusted certificate authorities. When your browser requests a secure page it gets the page's security certificate, which contains a chain that leads back to a certificate authority. If that authority matches an authority known to your browser then your browser will trust that the site you're connecting to is who it claims to be. If that sounds a bit weak to you, you're not alone. This is currently, the biggest problem with HTTPS. +Behind the scenes what handles all the encryption and authentication is a bit of technology know as TLS, which is short for Transport Layer Security. In fact the full name of HTTPS is really HTTP over TLS. TLS is the successor to the now vulnerable Secure Sockets Layer (SSL), though to further complicate things you will often hear both referred to as "SSL". In the context of this article, HTTPS will refer to TLS connections. -Which brings us to today. HTTPS is becoming more and more common, easier and easier for anyone to get up and running. what's the next step? +TLS is made up of two layers, the TLS Record Protocol and the TLS Handshake Protocol. Together these two tools allow your web browser to securely connect to a validated site and encrypt all your communications thereafter. -The next step is depricate the non-secure web. That is, turn HTTP into a second class citizen that, eventually, might be ignored all together. +Now that you know what HTTPS offers -- encryption and authentication -- it should hopefully be easy to see why your bank uses it, why Gmail, Facebook, Twitter and any other site you log in to uses it, or should (if you log in into to site without HTTPS, stop visiting that site). +What's less immediately obvious is why *every* site on the web can benefit from HTTPS. How does HTTPS help some long archived, no longer maintained bit of ephemera from the early web? +The answer is in many cases is it doesn't help. It does not benefit the site or its creator directly in many tangible ways. +It does, however, benefit the user connecting to the site, since they now know that what they see is actually data they requested from the site they wanted to visit (integrity and authenticity). +There's another beneficiary as well -- the network as a whole, and by extension, all of us using it. +Still, while there are clear benefits to HTTPS, it is not entirely without costs. +## What HTTPS Costs +There has been some push-back against the effort to push the web to all HTTPS, all the time. Most of the critics are worried about all the content out there that will never be ported to HTTPS -- what happens to it? Will HTTPS cost us the entirety of the early internet? -For the individual user the network has become hostile, for companies like Google the network has also become hostile. +Read through Mozilla's bug report on the subject and you'll find quite a few people talking about this content as if it were somehow tainted. Mozilla is a big company, with many different voices, but even Mozilla's Richard Barnes, who is one of the main proponents of HTTPS (and editor of several specs at the W3C related to it) told me "To be completely frank, I don't care about URLs I care about secure connections". +Barnes wants to make sure that the web is secure and he's not alone in his willingness to throw some of it under the bus to make that happen. The Chromium project has similar bug threads and outspoken HTTPS proponents. +Fortunately for us the web is not Mozilla's, not Google's, not even the W3C's. The web belongs to everyone who uses it and creates things for it. +Software developer and blogger Dave Winer [calls HTTPS](http://scripting.com/liveblog/users/davewiner/2015/12/18/0667.html) "expensive security theater". Winer writes, "I have a couple dozen sites that are just archives of projects that were completed a long time ago. I'm one person. I don't need make-work projects, I like to create new stuff, I don't need to make Google or Mozilla or the EFF or Nieman Lab happy." +Winer is not alone. In fact he's in very good company, no less than Tim Berners-Lee has [questioned the move to HTTPS](https://www.w3.org/DesignIssues/Security-NotTheS.html), going so far as to call it "arguably a greater threat to the integrity for the web than anything else in its history". Berners-Lee does think the web should be encrypted, he just doesn't like the way it's currently being done. Berners-Lee would like to see HTTP upgraded rather than shifting to the HTTPS protocol. -You don't have to dive too deep into H +There are two massive costs to HTTPS that have to be borne by users. -main motivation for HTTPS is authentication of the visited website and protection of the privacy and integrity of the exchanged data. +The first is the one Winer is concerned about -- HTTPS adds significant complications to the process of setting up a website. The second is the one Berners-Lee is concerned about, we risk breaking links, billions of links. +It's easy for savvy developers to dismiss the first problem, that HTTPS adds considerable complexity. But what makes the web great is that you don't have to be a savvy developer to be a part of it. Anyone with a few dollars a month to spare can rent their own server space somewhere, throw some HTML files in a folder and publish their thoughts on the web. A few dollars more gets you an nice URL, but that's not strictly necessary. +Requiring sites to include a security certificate adds a significant barrier to entry to the web. +Anyone who has put in the effort to get HTTPS working on even one site knows that it can be a tremendous hassle. Indeed this is probably the biggest obstacle to widespread HTTPS adoption among small site operators (that is, the bulk of the web). +Perhaps the most difficult part is actually obtaining a certificate, which, until very recently, was neither easy nor free. -Much of the confusion comes from our tendency to conflate security and privacy. While security is often necessary for privacy, the security you have does not guarantee anything. For example, you can have a secure HTTPS connection to Google, but that doesn't actually mean anything for your overall privacy. Google can still collect information about you, track you with cookies and then be compelled to give that information to the government. It can also just sell it to the highest bidder. Security is not a guarantee of privacy. +Until the last six months there were only a handful of certificate authorities which did not charge to issue certificates -- the best known being StartSSL -- but if you ever needed to revoke your certificate for some reason there was a fee. In other words, the certificates are only free if nothing ever goes wrong. If something does go wrong and you need to revoke a dozen or more sites, these "free" certificates quickly get expensive. -All the users whose data has been compromised in any of the hundreds of major data leaks from Target, tk, tk, or tk was collected over HTTPS connection. Security is not privacy. +This is one of the first problems that HTTPS proponents set out to solve. The EFF and Mozilla have partnered with some other big names to create Let's Encrypt, which offers free certificates -- yes, really free, no catches and you don't have to provide any identifying information to get one. There's also a set of command line tools that make installing and configuring them pretty simple provided you have some basic sysadmin knowledge (and SSH access to your server). -In the case of HTTPS the primary things that the "S" offers is protection against what's known as a Man in the Middle (MitM) attack. Imagine you're at a coffee shop chatting with what you think is your friend tk. browsing tk for a tk. You decide to buy the tk. You're connected to tk, but someone else at the coffee shop (most likely wearing a dark hoodie and hunched furtively over a laptop if the press is to be believed) is watching you connect to tk. Hoodie can impersonate tk +That's not the end of the headache though. Once you have a certificate you have to install it and get your web server to serve it up properly. Again, assuming you have a basic sysadmin's knowledge this isn't too hard, though tweaking it until you get a A+ grade on [SSLLab's test](https://www.ssllabs.com/ssltest/) can take many hours (and even top sites like [Facebook only score a B](https://www.ssllabs.com/ssltest/analyze.html?d=facebook.com)). I've been running my own website, building my own CMSes and running servers on the web for fifteen years and I can say without hesitation that getting HTTPS working on my site was the hardest thing I've done on the web. It was hard enough that, like Winer, I haven't bothered with old archived sites. -A MitM attack +Over the long run Let's Encrypt is hoping to partner with popular web hosts in such away that users looking to set up their own blog using popular CMS like WordPress get an HTTPS site up and running as easily as clicking a button. Things will, however, likely never be that simple for anyone who wants to take a more DIY approach, writing their own software. +Simplifying the process of setting up HTTPS makes the individual more dependent on tools build by others. Developer Ben Klemens has an [essay](https://medium.com/@b_k/https-the-end-of-an-era-c106acded474#.orxikg4xp) about exactly this dependency, writing that if "solving the problem consists of just starting a tool up, my sense of wonder has gone from 'Look what I did' to 'Look what these other people did', which is time-efficient but not especially fun." +It may seem trivial to developers employed by large companies solving complicated problems that taking the fun out of the web is a problem, but it is. If the web stops being fun for individuals it becomes solely the province of those companies. We are no longer creators of the web, but simple users. +Berners-Lee's caution is more immediately practical -- what happens to all those links to HTTP sites when all those sites become HTTPS? The answer is they break. There are quite a few proposals that would mitigate some of this at the browser level. When I asked Barnes about Berners-lee's concerns he told me, "Tim has been a really useful contrarian voice. His views have driven the browser and web community to address concerns he has raised". +To prove that Barnes actually does care about URLs, he's the co-editor of a W3C specification that aims to preserve all those old links and upgrade them to HTTPS. The spec is known as [HTST priming](https://mikewest.github.io/hsts-priming/) and it works with another proposed standard known as [Upgrade Insecure Requests](https://www.w3.org/TR/upgrade-insecure-requests/) to offer the web a kind of upgrade path around the link rot that Berners-Lee fears. -###Broad questions: +With Upgrade Insecure Requests site authors could tell a browser that they intend all resources to be loaded over HTTPS, even if the link is HTTP. This solves the legacy content problem, particularly in cases where the content can't be updated, for example, The New York Times [archived sites](http://open.blogs.nytimes.com/2014/11/13/embracing-https/). -How does HTTPS help users? -great cannon attack 2015 +Both of these proposals are still very early drafts, but they would, if implemented, provide a way around one of the biggest problems with HTTPS -- breaking links. -Does it stop nation state attacks by the NSA et al? -tls dns hijacking anti-virus super phish vulnerability -- fake root to inject ads. attacks go lower level cert flaws. +At least some of the time. Totally abandoned content will never be upgraded to HTTPS, neither will content where the authors, like Winer, elect not to. This isn't a huge problem though because browsers will still happily load the insecure content. -Does it protect user privacy, if so how? All the tracking cookies are still there. If the NSA wants them they just subpoena Google right? +What Winer and others fear is that at some point browser may stop loading HTTP content entirely. For now that's still a ways off, but Mozilla's plans make it clear that it is part of the future of Firefox. Mozilla's [FAQ](https://blog.mozilla.org/security/files/2015/05/HTTPS-FAQ.pdf) on the subject reads: "Q: Does this mean my unencrypted site will stop working? Not for a long time." -It stops man in the middle attacks. How common are those? Does anyone have any data on that? Bogeyman, accessible metaphor, but practical use it's unlikely to happen. +While browsers ceasing to load HTTP sites at all is wrong, as Winer puts it "the browser is broken. It has totally the wrong idea of its role." +At the same time, as developer and HTTPS proponent Eric Mill [writes](https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay), "we're deprecating HTTP and it's going to be okay." +## Why We Should Encrypt All The Things ---- +The web needs encryption because the web's visitors need it. The web needs encryption because the network needs it to remain neutral. The web needs encryption because without it just browsing can turn you into an unwitting helper in a DDoS attack. -###Cert flaws: +Several years ago I wrote a piece on the then nascent effort to get HTTPS more widely adopted. At the time I [wrote](http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/) "For sites that don't have any reason to encrypt anything... HTTPS just doesn't make sense." -Verizon injecting code to reconstruct cookies. If they're willing to do that, what's to stop them from including compromised certs that allow them to still inject the code? They control the platfor, that's unbeatable from the security standpoint. +That was then. Now I think it does make sense to encrypt everything. -"Even if the browser, OS were under your control you have no control over what the web application is doing with your data. Not only could it be being shared with servers through third-party sub-requests, it can also be passed server-server to thousands of other entities and often is. +In 2011 when I wrote that the network of the web looked fairly benign (as Snowden's leaks of revelled, it was not, but most of us had no way to know back then). Since that time the network has become hostile, incredibly hostile. -Link security != privacy. Privacy needs the rule of law not total secrecy." +As Mill recently wrote, "I see companies and government asserting themselves over their network. I see a network that is not just overseen, but actively hostile. I see an internet being steadily drained of its promise to "interpret censorship as damage'...In short, I see power moving away from the leafs and devolving back into the center, where power has been used to living for thousands of years." -https://lists.w3.org/Archives/Public/www-tag/2015Jan/0091.html +Lack of encryption has created a web that's no longer in the user's control. The web has become a broad surveillance tool for everyone from the NSA to Google to Verizon. ---- -> -> Also wondering whether, apropos the recent debates about moving to -> HTTPS, companies like Verizon would be able to MITM HTTPs traffic to -> play games like this. Seems to depend on the cert control provided by -> mobile browsers, and I'm concerned that in practice many of the -> browsers come from the ISPs, which supply the phones, which check the -> certs.... -> +As Mill writes, without encryption the network becomes a tool for whoever owns the largest nodes. We the people, the small creators of this thing we call web are not just at the mercy of the network owners, we've the victims of their whims. -This has been going on for ages. What's new is categorizing it as MitM -with all the "attack" connotation baggage that brings along with it, in -the use case where it's opted into. Or considering it in terms of mobile -Internet. Others have long called it a "business model". Sometimes it's -opted into by agreeing to a TOS, where I'd prefer opt-in based on users -having to configure browser settings for it, but I see where if that -was the business I was in, I'd think otherwise. Either way, I hesitate -to call it fraudulent outright. +My personal website does not ask you to login, it loads no third-party scripts, ad networks or any other code. Yet without encryption I have no way to ensure that some other party isn't inserting code of their own. As the Hoffman-Andrews says, "insert their own ads, their own tracking cookies, they can insert malware and do their own tracking". In other words, I would like to make sure no one is tracking you when you visit my site, and that you see no ads, but I can't. Unless I use HTTPS. -https://lists.w3.org/Archives/Public/www-tag/2015Jan/0173.html +Think no one is doing that to your site? Think again. ISPs are and will likely be doing more of this in the future, particularly mobile service providers. Their primary responsibility is to their shareholders and it would negligent of them to not increase profits by increasing tracking. ---- +It's worth noting here that this kind of manipulation is very likely at the heart of Google's love of HTTPS. Google did not respond to my inquires var this article, but it's a kind of open secret that ISPs harvest search queries. Without HTTPS it's pretty easy for ISPs to track not just search queries but which results users clicked on, which is vital information for building a better search engine. In other words, info Google would prefer its potential competitors don't get. -###technical details: +Winer calls out Google specifically and he's not the only one to do so. Yes, Google's acting in its own best interests and Winer is right to question the motives of a company so massive it has the power to [potentially control elections](https://aeon.co/essays/how-the-internet-flips-elections-and-alters-our-thoughts). However, in this case, Google's interests are aligned with the web at large (for now). Google doesn't want that data captured and sold, but remember that data is actually about you. It's your data first and foremost and regardless of what you think about Google gathering it, you certainly don't want it bought and sold by others. -LetEncrypt is great, but it's still way beyond the capabilites of your average blogger installing wordpress (or more likely clicking a button to install wordpress). Even if it were a one-click process to create, install and configure a cert, how does the blogger even find out that this is something they need to do? +The flip side to this is that if your site does serve up ads and you want to make sure that no one is stripping out those ads -- which, with companies like [Shine](https://www.getshine.com/) is starting to happen at the network level -- HTTPS is also your friend. -designed for helping servera admins, the no tech are using hosting services. it's getting easier. peole are becoming more dependent on hosting services. +The second and considerably more alarming network attack that's possible without HTTPS is what's become known as [Great Cannon](http://arstechnica.com/security/2015/04/meet-great-cannon-the-man-in-the-middle-weapon-china-used-on-github/). Great Cannon is a very sophisticated attack for full details see Citizen Lab's [write-up](https://citizenlab.org/2015/04/chinas-great-cannon/), but the short story is that someone hijacked a bit of JavaScript served up by Baidu and added a payload to it that made frequent requests to a target website. Great Cannon essentially turned unsuspecting browsers into part of DDoS attack. -Let's say I managed to figure all that out (which I have just for the record) who is going to renew my certs when I die? Or if I just stop caring/maintaining my site? +This is what Mill means when he says the network is actively hostile. With Great Cannon it becomes so hostile it turns you, unknowingly, into a DDoS attacker. -you already need to have server patches, etc +The only way to stop attacks like Great Cannon, network tampering like what Verizon and others are doing, is to encrypt your traffic. This is why Google, Mozilla, the EFF and others are pushing so hard for HTTPS. -Tim Berners Lee has called the move from http to https, "arguably a greater threat to the integrity for the web than anything else in its history." Given that URLs breaking, changing and disappearing is already a massive problem, and that this move WILL ABSOLUTELY MEAN MORE BROKEN SITES, how is that a win for the web? +Which brings us back to today. HTTPS is becoming more and more common, easier and easier for anyone to get up and running. Where does it go from here? -On browser indicators, there have already been studies that show no one pays any attention to them: "We also found that the security certificate cue was not used by the participants to determine the legitimacy of the presented Websites." http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6454330 +## What Happens Next ---- +What happens next is that browser vendors are going to start pushing the web to HTTPS by limiting what HTTP sites can do and changing the URL icons from positive feedback to negative feedback. The carrot is being replaced by the stick. -https://lists.w3.org/Archives/Public/www-tag/2015Jan/0080.html: +The Chromium project has already announced plans to [mark HTTP connections as insecure](https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure). Mozilla will do [roughly the same](https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/) with Firefox. Both also plan to limit many HTML APIs to HTTPS only, starting with the geo-location APIs, hardware access APIs and anything else that would be a security risk over unsecured connections. -> Also wondering whether, apropos the recent debates about moving to HTTPS, -> companies like Verizon would be able to MITM HTTPs traffic to play games -> like this. Seems to depend on the cert control provided by mobile browsers, -> and I'm concerned that in practice many of the browsers come from the ISPs, -> which supply the phones, which check the certs.... +The icon change will eventually mean that browser show nothing at all for secure sites and display a large red X in the URL bar when you visit an HTTP site. -A code-signed browser from a trustworthy source, consulting only its -own trust anchor store and/or enforcing key pinning and/or enforcing -Certificate Transparency, can generally enforce the guarantees of -HTTPS (which include stopping these cookie insertion attacks). +It's not difficult to imagine a day and age when browser treat HTTP sites they way the treat suspected malware sites now and simply not load them. To be clear, that's no happening right now. But it would be foolish to assume that it never will. -Of course, if the platform is under the control of someone other than -the owner, such as the carrier, the platform can subvert any -application at run-time. +It's tempting to see this as hostile to publishers -- the message has become fall in line with HTTPS or, as Winer writes, the browsers will "make sure everyone knows you're not to be trusted." -That underscores the importance of getting one's platform from a -trustworthy vendor. But that problem is entirely outside of TAG's -scope. +However, what the broken lock is really saying is that your browser can't guarantee that the content you're reading hasn't been tampered with. It also can't guarantee that you aren't currently part of a DDoS attack against a site you've never even heard of. It also can't guarantee that you're connected to the site you think you're connected to. -HTTPS is what we can do. Buttressing the web PKI is what we can do. So -we do. Some companies with representatives on this list are also -trying to provide trustworthy platforms to run apps on, too. So we do. +All of these things have always been true when you connect to an HTTP site, the only thing that's changing is that your browser is telling you about it. So long as browsers stop there the current plan seems well suited to bringing more security to the web. -Surely, you weren't hoping to use evidence of application-layer -attacks as a reason to not adopt effective application-layer security -techniques. +Giving users greater secrecy, ensuring data integrity in transit, and providing a means (flawed though it may be) of establishing authenticity empower the user and help make the network decidedly less hostile than it is right now. Abuse will still happen. Surveillance will still be possible but, as Mill notes, attacks will "change from bulk to targeted" and the network can return to being just a dumb pipe. ---- +It would an egregious abuse of their place in the web ecosystem for browsers to stop loading HTTP content entirely, but so far that's not happening. If it does, the web should resist it. Warnings help users make informed decisions, prohibitions help no one. -https://lists.w3.org/Archives/Public/www-tag/2015Jan/0083.html - -On 1/16/2015 2:54 AM, Chris Palmer wrote: -> Surely, you weren't hoping to use evidence of application-layer -> attacks as a reason to not adopt effective application-layer security -> techniques. - -No, but I think the TAG can play a useful role in documenting which of the -problems we see "in the wild" the move to HTTPS will "solve", which it -won't etc. Not everything we do as a community or that the TAG does can be -100% effective, but IMO a key role of the TAG is to document tradeoffs, and -to explain both the strengths and weaknesses of any proposed architectural -change. In this case, many readers of TAG Findings will be less informed -than the TAG. I think it will be helpful to clearly say: "This is what we -can reasonably expect the move to do for HTTPS to do for you; these are -some of the problems you might naively expect it to solve that it might not." - ---- - -### Interesting arguments - -https://lists.w3.org/Archives/Public/www-tag/2015Jan/0029.html - -As I understand the statement, it means some people would prefer privacy and security, and others prefer convenience and entertainment. - -This might just be projection. In some things, I am intensely protective of my privacy and security. In other matters, I couldn't care less about it. And while I'm far from infallible, I am regularly able to make reasonably informed decisions which demonstrate that I don't hold carefully to one or the other side of this apparent dichotomy. - -... - -FWIW I am not a fan of surveillance. But I note Russia is where Edward Snowden lives, for his own security. - ---- - - -If people want me to believe this is going to be handled competently, they need to stop pointing to vaporware as a solution, stop pointing to unusable crap as a solution, stop saying "Oh, it will work itself out." Because that's what I'm afraid of. Mozilla needs to acknowledge that at the moment, the TLS ecosystem is in absolute shambles, and switching to HTTPS-only is a terrible idea right now. Then I'll believe they're being realistic in their plans. - - -https://www.reddit.com/r/programming/comments/35vm9r/were_deprecating_http_and_its_going_to_be_okay/cr8lg3u - ---- - -Thoughts on security: - -Yves Lafon wrote: -> -> And saying that the only solution for people with poor bandwidth is -> to get rid of their security is not really satisfying. -> - -Privacy. Again, sorry. But security, when required, makes me not care -about bandwidth or latency. If I'm after the balance in my checking -account, I don't care if logging in takes 30 seconds. What I don't need -is for every page I access to be that slow. - - -Potential future problems with tiered content : - -In a post-net-neut world, everyone would have poor bandwidth and -latency, except when accessing the "fast lane", unless shared caching. -Sacrificing shared caching in the name of privacy which can't be -guaranteed at the application-protocol layer anyway, is not really -satisfying. - -https://lists.w3.org/Archives/Public/www-tag/2015Jan/0031.html - ---- +The web has always been a messy, complicated thing the last thing it needs now is an artificial binary construct of "good" and "bad" as determined by browser vendors. |