diff options
Diffstat (limited to 'published')
-rw-r--r-- | published/https-cuts.txt | 297 | ||||
-rw-r--r-- | published/https-take2-final.txt | 117 | ||||
-rw-r--r-- | published/https-v2.html | 59 | ||||
-rw-r--r-- | published/https.html | 88 | ||||
-rw-r--r-- | published/https.txt | 175 | ||||
-rw-r--r-- | published/interview-eric-mill-notes.txt | 38 | ||||
-rw-r--r-- | published/linuxmint173review.html | 61 | ||||
-rw-r--r-- | published/linuxmint173review.txt | 83 | ||||
-rw-r--r-- | published/notes-moz-richard-barnes.txt | 90 |
9 files changed, 1008 insertions, 0 deletions
diff --git a/published/https-cuts.txt b/published/https-cuts.txt new file mode 100644 index 0000000..5b2f3a5 --- /dev/null +++ b/published/https-cuts.txt @@ -0,0 +1,297 @@ + + + + + + +So long as browsers stop there the current plan seems well-suited to bringing more security to the web. + + + + + +This might + +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. + + +It's not difficult to imagine a day and age when browsers treat HTTP sites they way the treat suspected malware sites now and simply not load them. To be clear, that's not happening right now. But it would be foolish to assume that it never will. + + + +My personal website does not ask you to log in, 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 Hoffman-Andrews says, anyone could "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. + +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 for 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. + +Winer calls out Google specifically and he's not the only one to do so. Yes, Google is 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. + + + + +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. "It's time we start treating insecure connections as a Bug," writes one Mozilla developer on a bug report entitled "Switch generic icon to negative feedback for non-https sites." Mozilla is a big company, with many different voices, but even Barnes wants to make sure that the web is secure and he's not alone, the Chromium project has similar bug threads and outspoken HTTPS proponents, but 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. + + + + + + + + + +What Winer and others fear is that at some point browsers 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." + +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." + + + + + + +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. + + +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? + + + + + +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 stops ISP and nation states from censoring specific pages they don't like. + + + + +In general, the pieces seems a little scattershot and could use a tighter focus. From our perspective, that HTTPS does not solve every problem is not an issue; that HTTPS is oftentimes *presented* as being synonymous with "security", however, *is* the issue. This seems like it should be the central thesis of the piece—that the meaning and importance of HTTPS has been poorly communicated by most advocates. + +Dan Goodin and Peter Bright had some further specifics about individual arguments within the piece or other larger questions if you’d like, but the following outline was suggested and I think it might be a good roadmap to recast your draft towards: + +* but it's not all good news +* the (HTTP) legacy of the Web is important, so what are we doing to ensure that doesn't break, or disappear from search engines, or cause (technically spurious) warnings in our browsers. This strikes me as probably the most interesting issue to explore, especially as it has Tim Berners-Lee on its side. +* calling HTTPS sites "secure" and non-HTTPS sites "insecure" is deeply dishonest (just because a site uses HTTPS doesn't mean it's not storing your password and credit card number in unauthenticated plaintext somewhere, and doesn't mean that it hasn't been hacked to serve malicious javascript, etc.). Browsers do not make clear that it is a statement about the connection *to* the site, and not the site itself. People are given advice like "don't send passwords to insecure sites"--how the hell would you even know? +* HTTPS's protection is actually quite narrow (tbh it's not great against nation state adversaries due to the number of certificate authorities they control), though there are schemes in place to make it more powerful (HSTS, for example) +* HTTPS is *still* burdensome and/or inconvenient (though Let's Encrypt is a good step in the right direction) +* is this the kind of thing that google, in particular, should simply decree? + +With this in mind, would you be willing to take a second crack at the topic? I’d be happy to discuss the original draft with you further over the phone (or connect you with Dan or Peter if you’d like), but hopefully the outline above is clear and makes sense to you as a strong direction. + +In terms of a second draft, I understand this will take more than an afternoon. What if we said you could take ’til the end of March if necessary? +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 known 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. + +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. + + +Unused links: + +https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ +https://lists.w3.org/Archives/Public/www-tag/2015Jan/0086.html +https://w3c.github.io/webappsec-subresource-integrity/#use-casesexamples +https://tools.ietf.org/html/draft-reschke-objsec-00 +http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6454330 +https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 +https://caddyserver.com/ +http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/ +http://andreasgal.com/2015/03/30/data-is-at-the-heart-of-search-but-who-has-access-to-it/ +https://codereview.chromium.org/1530403002/ + + + + +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 + +--- diff --git a/published/https-take2-final.txt b/published/https-take2-final.txt new file mode 100644 index 0000000..5495d36 --- /dev/null +++ b/published/https-take2-final.txt @@ -0,0 +1,117 @@ +There's a major change sweeping the web. The familiar HTTP prefix is rapidly being replaced by HTTPS. 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. And on today's web everyone wants to see what you're doing. + +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. + +Now Google, Mozilla, the EFF and others want every website to adopt HTTPS. The push for HTTPS everywhere is about to get a big boost from Mozilla and Google when both companies' web browsers begin to actively call out sites that still use HTTP. + +The plan is for browsers to start labeling HTTP connections as insecure. In other words, instead of the green lock icon that indicates a connection is secure today, there will be a red icon to indicate when a connection is insecure. Eventually secure connections would not be labeled at all, they would be the assumed default. + +Google has also been pushing HTTPS connections by "[using HTTPS as a ranking signal](https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html)". Google takes the security of a connection (or lack thereof) into consideration when ranking sites in search results. For the time being Google says that HTTPS is "a very lightweight signal... carrying less weight than other signals such as high-quality content". However, the company says that that it "may decide to strengthen it" as a means to encourage more sites to adopt it. + +Through efforts like these HTTPS has already moved beyond the obvious realms like banking and webmail. Popular sites like Facebook, Twitter, YouTube, as well as major online retailers like Target, Home Depot and Adobe, are all served over HTTPS. + +Target, Home Depot and Adobe were not examples chosen at random though; all three have had major data breaches that exposed identifying information about users. + +HTTPS does not mean your *data* is secure, it just means your *connection* is secure. This is not semantics. It's critical for users to understand and unfortunately HTTPS advocates sometimes present HTTPS as synonymous with "security". The phrase "secure web" gets used a lot in discussions, but as those three retailers illustrate, using HTTPS does not mean a website is secure. In fact, HTTPS says nothing about the website, the server it resides on or what happens to whatever data you might give it. + +This may ultimately be the biggest challenge HTTPS faces -- helping people to understand what it means. + +## What's So Great About Encryption, TLS and Authenticity? + +If HTTPS is no guarantee of security, what does it do for you? HTTPS offers three things: secrecy, integrity and authenticity. + +The simplest of these is secrecy. HTTPS uses encryption to make sure that no one can see the data that's transmitted over the wire. 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. + +The EFF's Jacob Hoffman-Andrews, lead developer on Let's Encrypt, a new tool that offers free HTTPS certificates, 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." + +Without the encryption it's easy for anyone to see everything you ask for and everything the site sends back. That allows anyone who wants to to perform what's known as a Man in the Middle attack. + +With an unencrypted connection both your browser's request and the server's response are just plain text bits 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. + +This is not a theoretical problem, Man in the Middle code injection is an active, widely used attack. In the case of Verizon Wireless's so called "Perma-Cookie", it's even a business model. + +Using a Man in the Middle attack, Verizon Wireless modifies traffic on its network to inject a tracker (it added an HTTP header called X-UIDH) that 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". + +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. + +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. + +With the encrypted connection you get when a site uses HTTPS the transmitted data is very difficult to read. 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. + +HTTPS also prevents the kind of censorship that happens at the 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). + +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. + +Put all this together and you discover that the web, the network on which your data travels is not just insecure, but actively hostile. As developer and HTTPS proponent Eric Mill writes, "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." + +It's getting worse too. A considerably more alarming network attack has come to light in the last year that exploits the lack of HTTPS on the web to create distributed DDoS attacks using unsuspecting users who never know they're part of an attack. [Great Cannon](http://arstechnica.com/security/2015/04/meet-great-cannon-the-man-in-the-middle-weapon-china-used-on-github/), as this attack has been dubbed, 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 Chinese search giant Baidu and added a payload to it that made frequent requests to a target website. Everyone visiting Baidu who loaded that script became part of the attack. + +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. The only way to stop attacks like Great Cannon, or network tampering like what Verizon and others are doing, is to encrypt your traffic. + +The last thing HTTPS provides is authentication. The site you're visiting is verified by the browser as actually being that site and not some imposter. To authenticate your connection web browsers maintain a list of known, trusted certificate authorities. When your browser requests a 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. + +Now that you know what HTTPS offers -- encryption, integrity and authentication -- it should hopefully be easy to see why your bank uses it, why Gmail, Facebook, Twitter and any other sites you log in to use it, or should. What's less immediately obvious is why *every* site on the web can benefit from HTTPS. Does HTTPS help some long archived, no longer maintained bit of ephemera from the early web? + +Software developer and blogger Dave Winer argues in a post entitled [HTTPS is expensive security theater](http://scripting.com/liveblog/users/davewiner/2015/12/18/0667.html), that not only does it not help old, archived sites, it's a waste of the site owner's time. "I have a couple dozen sites that are just archives of projects that were completed a long time ago," writes Winer. "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. + +Winer and Berners-Lee highlight the two big potential problems of moving the web to HTTPS. It significantly complications to the process of setting up a website and creating something on the web, and it might break 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). + +Until very recently there was no way to obtain a free SSL certificate (a few certificate authorities did not charge to issue you a certificate, the if you needed to revoke it there way a fee). This was the first challenge that HTTPS proponents set out to solve. The EFF and Mozilla partnered to create Let's Encrypt, which now offers free certificates -- 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). + +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 security test](https://www.ssllabs.com/ssltest/) can take many hours of debugging (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. + +Over the long run Let's Encrypt is hoping to partner with popular web hosts in such a way 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 means more tools in your toolchain. It 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. + +## Think of the Links + +Berners-Lee's concerns about HTTPS are easier to fix -- 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 Mozilla's 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. + +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/). + +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. + +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. For now anyway. + +## More Honest Web Browsers + +The web needs encryption because the web's users 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. + +There are a lot of companies pushing HTTPS, most have their own interests first but for now at least those interests align with web users' interests. None of these companies have the kind of power and influence that Google and, to a lesser degree, Mozilla have as browser makers. + +And it's up to browser makers to fix the confusion that currently surrounds HTTPS. + +The current way browsers highlight HTTPS connections is misleading and needs to change. + +The green lock icon that browsers use to denote a secure connection is too easily construed as a signal that the site is "secure". Labeling HTTPS sites "secure" and non-HTTPS sites "insecure" is deeply dishonest (just because a site uses HTTPS doesn't mean it's not storing your password and credit card number in plain text somewhere, and doesn't mean that it hasn't been hacked to serve malicious JavaScript and so on). As it stands browsers do not make clear that the lock icon is a statement about the connection *to* the site, and not the site itself. + +As Hoffman-Andrews puts it, "calling HTTPS sites secure is generally not accurate, but it's definitely accurate to call HTTP sites insecure." In fact, browsers have no way of knowing if the site is truly "secure" in the broader sense. Neither do you and I. No one is every going to fix that. But browsers can fix what they show users. + +The Chromium project has already announced plans to change the way it displays the lock and start [marking 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. + +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." + +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. All it can guarantee is that there is nothing secure about your connection and anyone could be doing anything to it. + +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. + +The far more important change comes after that, when there will be no icon at all for HTTPS connections. All you'll ever see to indicate "security" is a large red X in the URL bar when you visit a site over HTTPS. + +Winer's fear is that Google especially, because it has a financial interest in HTTPS (HTTPS prevents Google's competitors from scraping search results), will stop loading and ranking HTTP sites altogether. It would an egregious abuse of their place in the web ecosystem for any browser to stop loading HTTP content entirely, but so far that's not happening. If it does, if Google's self-interests are no longer aligned with the web's, then the web should resist it. Warnings help users make informed decisions, prohibitions help no one. + +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. At the same time, the current lack of encrypted connections 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. 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're the victims of their whims. + +Giving users greater secrecy, ensuring data integrity in transit, and providing a means 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. diff --git a/published/https-v2.html b/published/https-v2.html new file mode 100644 index 0000000..4d6f334 --- /dev/null +++ b/published/https-v2.html @@ -0,0 +1,59 @@ +<p>There's a major change sweeping the web. The familiar HTTP prefix is rapidly being replaced by HTTPS. 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. And on today's web everyone wants to see what you're doing.</p> +<p>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.</p> +<p>Now Google, Mozilla, the EFF and others want every website to adopt HTTPS. The push for HTTPS everywhere is about to get a big boost from Mozilla and Google when both companies' web browsers begin to actively call out sites that still use HTTP.</p> +<p>The plan is for browsers to start labeling HTTP connections as insecure. In other words, instead of the green lock icon that indicates a connection is secure today, there will be a red icon to indicate when a connection is insecure. Eventually secure connections would not be labeled at all, they would be the assumed default.</p> +<p>Google has also been pushing HTTPS connections by "<a href="https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html">using HTTPS as a ranking signal</a>". Google takes the security of a connection (or lack thereof) into consideration when ranking sites in search results. For the time being Google says that HTTPS is "a very lightweight signal... carrying less weight than other signals such as high-quality content". However, the company says that that it "may decide to strengthen it" as a means to encourage more sites to adopt it.</p> +<p>Through efforts like these HTTPS has already moved beyond the obvious realms like banking and webmail. Popular sites like Facebook, Twitter, YouTube, as well as major online retailers like Target, Home Depot and Adobe, are all served over HTTPS.</p> +<p>Target, Home Depot and Adobe were not examples chosen at random though; all three have had major data breaches that exposed identifying information about users.</p> +<p>HTTPS does not mean your <em>data</em> is secure, it just means your <em>connection</em> is secure. This is not semantics. It's critical for users to understand and unfortunately HTTPS advocates sometimes present HTTPS as synonymous with "security". The phrase "secure web" gets used a lot in discussions, but as those three retailers illustrate, using HTTPS does not mean a website is secure. In fact, HTTPS says nothing about the website, the server it resides on or what happens to whatever data you might give it.</p> +<p>This may ultimately be the biggest challenge HTTPS faces -- helping people to understand what it means.</p> +<h2 id="whats-so-great-about-encryption-tls-and-authenticity">What's So Great About Encryption, TLS and Authenticity?</h2> +<p>If HTTPS is no guarantee of security, what does it do for you? HTTPS offers three things: secrecy, integrity and authenticity.</p> +<p>The simplest of these is secrecy. HTTPS uses encryption to make sure that no one can see the data that's transmitted over the wire. 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.</p> +<p>The EFF's Jacob Hoffman-Andrews, lead developer on Let's Encrypt, a new tool that offers free HTTPS certificates, 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 <a href="https://en.wikipedia.org/wiki/Clipper_chip">restrictions anymore</a>, so it will be default and you won't have to worry about it."</p> +<p>Without the encryption it's easy for anyone to see everything you ask for and everything the site sends back. That allows anyone who wants to to perform what's known as a Man in the Middle attack.</p> +<p>With an unencrypted connection both your browser's request and the server's response are just plain text bits 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.</p> +<p>This is not a theoretical problem, Man in the Middle code injection is an active, widely used attack. In the case of Verizon Wireless's so called "Perma-Cookie", it's even a business model.</p> +<p>Using a Man in the Middle attack, Verizon Wireless modifies traffic on its network to inject a tracker (it added an HTTP header called X-UIDH) that is then sent to all unencrypted sites that Verizon customers visit. This allows Verizon to, in the <a href="https://www.eff.org/deeplinks/2014/11/verizon-x-uidh">words of the EFF</a>, "assemble a deep, permanent profile of visitors' web browsing habits without their consent".</p> +<p>Verizon is not alone. It's a safe bet that your ISP is doing something similar. Comcast's wifi service <a href="http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/">already does</a>, as does <a href="http://arstechnica.com/information-technology/2015/03/atts-plan-to-watch-your-web-browsing-and-what-you-can-do-about-it/3/">AT&T's</a> (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.</p> +<p>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.</p> +<p>With the encrypted connection you get when a site uses HTTPS the transmitted data is very difficult to read. 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.</p> +<p>HTTPS also prevents the kind of censorship that happens at the state or ISP level. Examples of this abound as well, for example, Russia wanted to ban a Wikipedia article (about <a href="https://en.wikipedia.org/wiki/Charas">charas hashish</a>), 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 <a href="https://www.eff.org/deeplinks/2015/08/russias-wikipedia-ban-buckles-under-https-encryption">opted for none</a>.</p> +<p>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.</p> +<p>Put all this together and you discover that the web, the network on which your data travels is not just insecure, but actively hostile. As developer and HTTPS proponent Eric Mill writes, "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."</p> +<p>It's getting worse too. A considerably more alarming network attack has come to light in the last year that exploits the lack of HTTPS on the web to create distributed DDoS attacks using unsuspecting users who never know they're part of an attack. <a href="http://arstechnica.com/security/2015/04/meet-great-cannon-the-man-in-the-middle-weapon-china-used-on-github/">Great Cannon</a>, as this attack has been dubbed, is a very sophisticated attack. For full details see Citizen Lab's <a href="https://citizenlab.org/2015/04/chinas-great-cannon/">write-up</a>, but the short story is that someone hijacked a bit of JavaScript served up by Chinese search giant Baidu and added a payload to it that made frequent requests to a target website. Everyone visiting Baidu who loaded that script became part of the attack.</p> +<p>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. The only way to stop attacks like Great Cannon, or network tampering like what Verizon and others are doing, is to encrypt your traffic.</p> +<p>The last thing HTTPS provides is authentication. The site you're visiting is verified by the browser as actually being that site and not some imposter. To authenticate your connection web browsers maintain a list of known, trusted certificate authorities. When your browser requests a 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.</p> +<p>Now that you know what HTTPS offers -- encryption, integrity and authentication -- it should hopefully be easy to see why your bank uses it, why Gmail, Facebook, Twitter and any other sites you log in to use it, or should. What's less immediately obvious is why <em>every</em> site on the web can benefit from HTTPS. Does HTTPS help some long archived, no longer maintained bit of ephemera from the early web?</p> +<p>Software developer and blogger Dave Winer argues in a post entitled <a href="http://scripting.com/liveblog/users/davewiner/2015/12/18/0667.html">HTTPS is expensive security theater</a>, that not only does it not help old, archived sites, it's a waste of the site owner's time. "I have a couple dozen sites that are just archives of projects that were completed a long time ago," writes Winer. "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."</p> +<p>Winer is not alone. In fact he's in very good company, no less than Tim Berners-Lee has <a href="https://www.w3.org/DesignIssues/Security-NotTheS.html">questioned the move to HTTPS</a>, 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.</p> +<p>Winer and Berners-Lee highlight the two big potential problems of moving the web to HTTPS. It significantly complications to the process of setting up a website and creating something on the web, and it might break links -- billions of links.</p> +<p>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.</p> +<p>Requiring sites to include a security certificate adds a significant barrier to entry to the web.</p> +<p>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).</p> +<p>Until very recently there was no way to obtain a free SSL certificate (a few certificate authorities did not charge to issue you a certificate, the if you needed to revoke it there way a fee). This was the first challenge that HTTPS proponents set out to solve. The EFF and Mozilla partnered to create Let's Encrypt, which now offers free certificates -- 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).</p> +<p>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 <a href="https://www.ssllabs.com/ssltest/">SSLLab's security test</a> can take many hours of debugging (and even top sites like <a href="https://www.ssllabs.com/ssltest/analyze.html?d=facebook.com">Facebook only score a B</a>). 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.</p> +<p>Over the long run Let's Encrypt is hoping to partner with popular web hosts in such a way 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.</p> +<p>Simplifying the process of setting up HTTPS means more tools in your toolchain. It makes the individual more dependent on tools build by others. Developer Ben Klemens has an <a href="https://medium.com/@b_k/https-the-end-of-an-era-c106acded474#.orxikg4xp">essay</a> 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."</p> +<p>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.</p> +<h2 id="think-of-the-links">Think of the Links</h2> +<p>Berners-Lee's concerns about HTTPS are easier to fix -- 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 Mozilla's 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".</p> +<p>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 <a href="https://mikewest.github.io/hsts-priming/">HTST priming</a> and it works with another proposed standard known as <a href="https://www.w3.org/TR/upgrade-insecure-requests/">Upgrade Insecure Requests</a> to offer the web a kind of upgrade path around the link rot that Berners-Lee fears.</p> +<p>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 <a href="http://open.blogs.nytimes.com/2014/11/13/embracing-https/">archived sites</a>.</p> +<p>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.</p> +<p>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. For now anyway.</p> +<h2 id="more-honest-web-browsers">More Honest Web Browsers</h2> +<p>The web needs encryption because the web's users 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.</p> +<p>There are a lot of companies pushing HTTPS, most have their own interests first but for now at least those interests align with web users' interests. None of these companies have the kind of power and influence that Google and, to a lesser degree, Mozilla have as browser makers.</p> +<p>And it's up to browser makers to fix the confusion that currently surrounds HTTPS.</p> +<p>The current way browsers highlight HTTPS connections is misleading and needs to change.</p> +<p>The green lock icon that browsers use to denote a secure connection is too easily construed as a signal that the site is "secure". Labeling HTTPS sites "secure" and non-HTTPS sites "insecure" is deeply dishonest (just because a site uses HTTPS doesn't mean it's not storing your password and credit card number in plain text somewhere, and doesn't mean that it hasn't been hacked to serve malicious JavaScript and so on). As it stands browsers do not make clear that the lock icon is a statement about the connection <em>to</em> the site, and not the site itself.</p> +<p>As Hoffman-Andrews puts it, "calling HTTPS sites secure is generally not accurate, but it's definitely accurate to call HTTP sites insecure." In fact, browsers have no way of knowing if the site is truly "secure" in the broader sense. Neither do you and I. No one is every going to fix that. But browsers can fix what they show users.</p> +<p>The Chromium project has already announced plans to change the way it displays the lock and start <a href="https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure">marking HTTP connections as insecure</a>. Mozilla will do <a href="https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/">roughly the same</a> with Firefox.</p> +<p>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."</p> +<p>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. All it can guarantee is that there is nothing secure about your connection and anyone could be doing anything to it.</p> +<p>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.</p> +<p>The far more important change comes after that, when there will be no icon at all for HTTPS connections. All you'll ever see to indicate "security" is a large red X in the URL bar when you visit a site over HTTPS.</p> +<p>Winer's fear is that Google especially, because it has a financial interest in HTTPS (HTTPS prevents Google's competitors from scraping search results), will stop loading and ranking HTTP sites altogether. It would an egregious abuse of their place in the web ecosystem for any browser to stop loading HTTP content entirely, but so far that's not happening. If it does, if Google's self-interests are no longer aligned with the web's, then the web should resist it. Warnings help users make informed decisions, prohibitions help no one.</p> +<p>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. At the same time, the current lack of encrypted connections 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. 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're the victims of their whims.</p> +<p>Giving users greater secrecy, ensuring data integrity in transit, and providing a means 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.</p> diff --git a/published/https.html b/published/https.html new file mode 100644 index 0000000..60b0ca2 --- /dev/null +++ b/published/https.html @@ -0,0 +1,88 @@ +<p>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 companies' web browsers begin to actively call out insecure websites.</p> +<p>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.</p> +<p>On today's web everyone wants to see what you're doing. And as long as you're using HTTP, they can.</p> +<p>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.</p> +<p>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 stops ISP and nation states from censoring specific pages they don't like.</p> +<p>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.</p> +<p>This is important to bear in mind because it's also a win for some big companies that 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.</p> +<p>Changing the web to HTTPS is not, however, entirely without costs and challenges for both web users and website owners.</p> +<p>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.</p> +<h2 id="what-https-does-for-you">What HTTPS Does For You</h2> +<p>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.</p> +<p>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 <a href="https://en.wikipedia.org/wiki/Clipper_chip">restrictions anymore</a>, so it will be default and you won't have to worry about it."</p> +<p>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.</p> +<p>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.</p> +<p>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.</p> +<p>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.</p> +<p>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) that is then sent to all unencrypted sites that Verizon customers visit. This allows Verizon to, in the <a href="https://www.eff.org/deeplinks/2014/11/verizon-x-uidh">words of the EFF</a>, "assemble a deep, permanent profile of visitors' web browsing habits without their consent".</p> +<p>Verizon is not alone. It's a safe bet that your ISP is doing something similar. Comcast's wifi service <a href="http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/">already does</a>, as does <a href="http://arstechnica.com/information-technology/2015/03/atts-plan-to-watch-your-web-browsing-and-what-you-can-do-about-it/3/">AT&T's</a> (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.</p> +<p>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.</p> +<p>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.</p> +<p>HTTPS also prevents the kind of censorship that happens at the state or ISP level. Examples of this abound as well, for example, Russia wanted to ban a Wikipedia article (about <a href="https://en.wikipedia.org/wiki/Charas">charas hashish</a>), 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 <a href="https://www.eff.org/deeplinks/2015/08/russias-wikipedia-ban-buckles-under-https-encryption">opted for none</a>.</p> +<p>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.</p> +<p>Having an HTTPS connection offers one other thing that benefits users -- authentication.</p> +<p>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.</p> +<p>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.</p> +<p>Behind the scenes what handles all the encryption and authentication is a bit of technology known 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.</p> +<p>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.</p> +<p>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).</p> +<p>What's less immediately obvious is why <em>every</em> 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?</p> +<p>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.</p> +<p>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).</p> +<p>There's another beneficiary as well -- the network as a whole, and by extension, all of us using it.</p> +<p>Still, while there are clear benefits to HTTPS, it is not entirely without costs.</p> +<h2 id="what-https-costs">What HTTPS Costs</h2> +<p>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?</p> +<p>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. "It's time we start treating insecure connections as a Bug," writes one Mozilla developer on a bug report entitled "Switch generic icon to negative feedback for non-https sites." 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."</p> +<p>The URLs Barnes is referring to is part of the debate surrounding HTTP vs HTTPS -- is HTTPS the answer or is there a way to upgrade HTTP? In the end though Barnes just wants to make sure that the web is secure and he's not alone. The Chromium project has similar bug threads and outspoken HTTPS proponents.</p> +<p>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.</p> +<p>Software developer and blogger Dave Winer <a href="http://scripting.com/liveblog/users/davewiner/2015/12/18/0667.html">calls HTTPS</a> "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."</p> +<p>Winer is not alone. In fact he's in very good company, no less than Tim Berners-Lee has <a href="https://www.w3.org/DesignIssues/Security-NotTheS.html">questioned the move to HTTPS</a>, 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.</p> +<p>There are two massive costs to HTTPS that have to be borne by users.</p> +<p>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.</p> +<p>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.</p> +<p>Requiring sites to include a security certificate adds a significant barrier to entry to the web.</p> +<p>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).</p> +<p>Perhaps the most difficult part is actually obtaining a certificate, which, until very recently, was neither easy nor free.</p> +<p>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.</p> +<p>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).</p> +<p>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 <a href="https://www.ssllabs.com/ssltest/">SSLLab's test</a> can take many hours (and even top sites like <a href="https://www.ssllabs.com/ssltest/analyze.html?d=facebook.com">Facebook only score a B</a>). 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.</p> +<p>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.</p> +<p>Simplifying the process of setting up HTTPS makes the individual more dependent on tools build by others. Developer Ben Klemens has an <a href="https://medium.com/@b_k/https-the-end-of-an-era-c106acded474#.orxikg4xp">essay</a> 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."</p> +<p>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.</p> +<p>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 Mozilla's 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".</p> +<p>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 <a href="https://mikewest.github.io/hsts-priming/">HTST priming</a> and it works with another proposed standard known as <a href="https://www.w3.org/TR/upgrade-insecure-requests/">Upgrade Insecure Requests</a> to offer the web a kind of upgrade path around the link rot that Berners-Lee fears.</p> +<p>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 <a href="http://open.blogs.nytimes.com/2014/11/13/embracing-https/">archived sites</a>.</p> +<p>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.</p> +<p>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.</p> +<p>What Winer and others fear is that at some point browsers 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 <a href="https://blog.mozilla.org/security/files/2015/05/HTTPS-FAQ.pdf">FAQ</a> on the subject reads: "Q: Does this mean my unencrypted site will stop working? Not for a long time."</p> +<p>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."</p> +<p>At the same time, as developer and HTTPS proponent Eric Mill <a href="https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay">writes</a>, "we're deprecating HTTP and it's going to be okay."</p> +<h2 id="why-we-should-encrypt-all-the-things">Why We Should Encrypt All The Things</h2> +<p>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.</p> +<p>Several years ago I wrote a piece on the then nascent effort to get HTTPS more widely adopted. At the time I <a href="http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/">wrote</a> "For sites that don't have any reason to encrypt anything... HTTPS just doesn't make sense."</p> +<p>That was then. Now I think it does make sense to encrypt everything.</p> +<p>In 2011 when I wrote that the network of the web looked fairly benign (as Snowden's leaks revealed, it was not, but most of us had no way to know back then). Since that time the network has become hostile, incredibly hostile.</p> +<p>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."</p> +<p>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.</p> +<p>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.</p> +<p>My personal website does not ask you to log in, 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 Hoffman-Andrews says, anyone could "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.</p> +<p>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.</p> +<p>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 for 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.</p> +<p>Winer calls out Google specifically and he's not the only one to do so. Yes, Google is acting in its own best interests and Winer is right to question the motives of a company so massive it has the power to <a href="https://aeon.co/essays/how-the-internet-flips-elections-and-alters-our-thoughts">potentially control elections</a>. 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.</p> +<p>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 <a href="https://www.getshine.com/">Shine</a>, is starting to happen at the network level -- HTTPS is also your friend.</p> +<p>The second and considerably more alarming network attack that's possible without HTTPS is what's become known as <a href="http://arstechnica.com/security/2015/04/meet-great-cannon-the-man-in-the-middle-weapon-china-used-on-github/">Great Cannon</a>. Great Cannon is a very sophisticated attack, for full details see Citizen Lab's <a href="https://citizenlab.org/2015/04/chinas-great-cannon/">write-up</a>, but the short story is that someone hijacked a bit of JavaScript served up by Chinese search giant 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.</p> +<p>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.</p> +<p>The only way to stop attacks like Great Cannon, or network tampering like what Verizon and others are doing, is to encrypt your traffic. This is why the web needs HTTPS.</p> +<p>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?</p> +<h2 id="what-happens-next">What Happens Next</h2> +<p>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.</p> +<p>The Chromium project has already announced plans to <a href="https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure">mark HTTP connections as insecure</a>. Mozilla will do <a href="https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/">roughly the same</a> 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.</p> +<p>The icon change will eventually mean that browsers show nothing at all for secure sites and display a large red X in the URL bar when you visit an HTTP site.</p> +<p>It's not difficult to imagine a day and age when browsers treat HTTP sites they way the treat suspected malware sites now and simply not load them. To be clear, that's not happening right now. But it would be foolish to assume that it never will.</p> +<p>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."</p> +<p>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.</p> +<p>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.</p> +<p>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.</p> +<p>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.</p> +<p>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.</p> diff --git a/published/https.txt b/published/https.txt new file mode 100644 index 0000000..679f5bd --- /dev/null +++ b/published/https.txt @@ -0,0 +1,175 @@ +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 companies' web browsers begin to actively call out insecure websites. + +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. + +On today's web everyone wants to see what you're doing. And as long as you're using HTTP, they can. + +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. + +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 stops ISP and nation states from censoring specific pages they don't like. + +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. + +This is important to bear in mind because it's also a win for some big companies that 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. + +Changing the web to HTTPS is not, however, entirely without costs and challenges for both web users and 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. + +## What HTTPS Does For You + +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. + +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." + +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. + +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. + +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. + +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. + +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) that 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". + +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. + +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. + +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. + +HTTPS also prevents the kind of censorship that happens at the 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). + +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. + +Having an HTTPS connection offers one other thing that benefits users -- authentication. + +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 known 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. + +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. + +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? + +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. "It's time we start treating insecure connections as a Bug," writes one Mozilla developer on a bug report entitled "Switch generic icon to negative feedback for non-https sites." 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." + +The URLs Barnes is referring to is part of the debate surrounding HTTP vs HTTPS -- is HTTPS the answer or is there a way to upgrade HTTP? In the end though Barnes just wants to make sure that the web is secure and he's not alone. 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. + +There are two massive costs to HTTPS that have to be borne by users. + +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. + +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. + +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). + +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. + +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 Mozilla's 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. + +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/). + +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. + +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. + +What Winer and others fear is that at some point browsers 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." + +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. + +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." + +That was then. Now I think it does make sense to encrypt everything. + +In 2011 when I wrote that the network of the web looked fairly benign (as Snowden's leaks revealed, it was not, but most of us had no way to know back then). Since that time the network has become hostile, incredibly hostile. + +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." + +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. + +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. + +My personal website does not ask you to log in, 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 Hoffman-Andrews says, anyone could "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. + +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 for 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. + +Winer calls out Google specifically and he's not the only one to do so. Yes, Google is 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. + +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. + +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 Chinese search giant 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. + +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. + +The only way to stop attacks like Great Cannon, or network tampering like what Verizon and others are doing, is to encrypt your traffic. This is why the web needs HTTPS. + +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? + +## 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. + +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. + +The icon change will eventually mean that browsers show nothing at all for secure sites and display a large red X in the URL bar when you visit an HTTP site. + +It's not difficult to imagine a day and age when browsers treat HTTP sites they way the treat suspected malware sites now and simply not load them. To be clear, that's not happening right now. But it would be foolish to assume that it never will. + +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." + +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. + +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. + +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. + +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. diff --git a/published/interview-eric-mill-notes.txt b/published/interview-eric-mill-notes.txt new file mode 100644 index 0000000..435d4e8 --- /dev/null +++ b/published/interview-eric-mill-notes.txt @@ -0,0 +1,38 @@ +The major players and what they want: + +Google - wants to stop ISPs from tracking search results and selling the results to competitors. HTTPS prevents verizon et al from recording the search results and then also recording which results gets clicked and then sells that to Yahoo Bing and whomever else wants it. + +EFF - Seems to want to help everyone, but has a heavy focus on dissidents whistle blowers and the like. + +Mozilla - wants to do good things, but also needs to follow Google's lead or risk slipping further into irrelevance. + +""" +When I look at all these things, 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. + +What animates me is knowing that we can actually change this dynamic by making strong encryption ubiquitous. We can force online surveillance to be as narrowly targeted and inconvenient as law enforcement was always meant to be. We can force ISPs to be the neutral commodity pipes they were always meant to be. On the web, that means HTTPS. + +""" - https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay + +That sucks for everybody. I also don't want my metadata sold. The network should be just a dumb pipe, what information is being shared should between. + +When things are invisible like that -- companies making deals to resell data -- it's not really reassuring it's not how the network was supposed to operate. + +The internet is this great thing, + +HTTPS is fundamentally an end-to-end protocol, makes attacks + +HTTPS moves attacks from bulk to targeted. + +You put the power back in the hands of the publishers, the site that's operating the content. + +You can't modify information on a per-page basis. + +the only reason that people would like to get to the point + +The reason the barrier is getting lower is because of pressure to make the web move [to HTTPS]. + +If we want to change the ecosystem and make it easier for individual bloggers + + diff --git a/published/linuxmint173review.html b/published/linuxmint173review.html new file mode 100644 index 0000000..83a4e51 --- /dev/null +++ b/published/linuxmint173review.html @@ -0,0 +1,61 @@ +<p>The Linux Mint project recently unveiled Linux Mint 17.3. The latest release from this Ubuntu-based Linux distro just might be the best Linux desktop around.</p> +<p>Linux Mint 17.3 arrived a few days late and had a somewhat bumpy launch thanks to some <a href="http://blog.linuxmint.com/?p=2944">server hardware issues</a> that temporarily knocked the Linux Mint blog and forums offline. The final version of Linux Mint was out there, but few knew about it until a few weeks later.</p> +<p>This is a big release of Linux Mint 17.3 marks the final release that will be built atop Ubuntu 14.04. Linux Mint 17.3 marks the fulfillment of the project's plan to stop chasing every Ubuntu release and focus on perfecting what makes Mint, well, Mint. When Ubuntu puts out its next Long Term Support release in April of 2016, Mint will have to upgrade its base system.</p> +<p>Mint's LTS strategy was a risky move. Mint bucked several trends in opting to pass on whatever butterflies Ubuntu was chasing. Sticking with a stable base and steadfastly refusing to inflate its version numbers may well have left some users at a loss. Jests aside, turning its back on the latest and greatest GTK and kernel updates that come from tracking Ubuntu's every move is not without some costs, but overall the strategy seems to have been a huge success.</p> +<p>Linux Mint has shown that it has the vision and is willing to put in the actual work to produce one the best desktop experiences around. The Cinnamon edition is not just the most polished Linux desktop around, it's possibly the most polished desktop period. Hyperbolic? Perhaps a little, but this really is the most thoroughly thought out desktop I've ever used, Linux or otherwise.</p> +<p>Mint's lead developer Clément Lefebvre and team have done a great job of keeping most of the userspace packages much more up-to-date than the Ubuntu 14.04 base would lead you to believe. There are exceptions -- GNOME/GTK is probably the most noticeable, being stuck at 3.10, and the kernel also lags behind at version 3.19 -- but for the most part though the latest version of all the apps you're likely to use are either available in the Mint repos or just a PPA away. And thanks to Mint's amazing package management system finding, installing and keeping track of apps and even PPA's is surprisingly simple.</p> +<h2 id="linux-mint-cinnamon-edition">Linux Mint: Cinnamon Edition</h2> +<p>If you don't want to think about the OS you're using -- that is, if you want to click a button that says "Menu" to launch an app or open a folder named "Documents" to find your files -- Cinnamon is going to make you happy.</p> +<p>Cinnamon is a desktop for people who want their desktop to get out of the way. It does not revolutionize any paradigms and it probably doesn't work very well on that mythical Linux tablet that GNOME is still waiting for, but it does offer one of the best, most polished experiences you can get on your laptop or desktop today.</p> + +[image="mint173-cinnamon-desktop.jpg" caption="The default Cinnamon desktop in Linux Mint 17.3"] + +<p>And by polish I don't mean the theme looks nice -- though it does, albeit not much different than the last few releases -- I mean the functionality and workflow. Cinnamon has smoothed down the rough edges of common tasks you do everyday, like listening to music, browsing your files and applications, updating and installing software, and getting notifications from background applications. The things you do the most are the things Linux Mint wants to improve on, not by changing the way you do them, but by making them easier to do.</p> +<p>In this release that translates into a number of improvements in commonly used task bar applets and tools like the sound applet, power applet, system tray more generally, and Mint's package management system.</p> +<p>Let's start with the improved sound applet which resides in the far right side of the system tray by default.</p> +<p>It's a small thing, but if you like listening to music while you work you'll probably interact with the sound applet all the time. In Linux Mint 17.3 the sound applet has been improved to add playback controls over the cover art, including a progress bar you can use to skip forward and back. There's also a new right-click menu that gives you access to all the settings and adjustments you're likely to ever need are right there in the pop up window above the applet icon. If you have multiple output options you can switch between them right in the applet. As of Mint 17.3 output devices now show both their name and their origin, which makes it easier to figure out which "HDMI Audio Controller" goes with which HDMI port, for example. The applet can also quickly switch between audio players -- for example, pause Spotify and switch to your local player when you lose connectivity -- or quit audio players without actually switching apps. You can also quickly mute both input and output.</p> + +[image="mint173-sound-applet.jpg" caption="The revamped sound applet in Mint 17.3 handles everything from MPD to Spotify."] + +<p>In my testing I never encountered any music-related task that I couldn't handle right from the applet -- no need to open your music player or dive into the system settings. In fact, if you use the venerable Music Player Daemon to play your music the applet is all you need to have running.</p> +<p>One final touch worth noting: by default the Cinnamon audio applet hides an audio application's native system tray applet (if it has one), if you prefer, for instance, Spotify's native applet, there's an option in the sound preference pane to tell the sound applet to stop hiding other sound applets. GNOME developers take note, it's possible to build something cool and still accept that some people won't like it and then to accommodate those people by giving them an option to turn it off. Strange that offering choices and options have become a Linux desktop feature that's worth mentioning.</p> +<p>Another frequently used applet that sees a makeover in this release is the power applet. The power applet now offers, like the audio applet, more detail and control. Now you can quickly see the battery state not just for your laptop, but any attached devices like a wireless mouse or keyboard.</p> +<p>The rest of Cinnamon's system tray has some improvements as well. The workspace switcher applet now shows a little visual representation of your workspaces, with little rectangles corresponding to each window inside of them. The icons are tiny, but it can be helpful if you have a lot of workspaces open.</p> + +[image="mint173-workspace-switcher.jpg" caption="The taskbar's workspace switcher showing a preview of the windows in each workspace."] + +<p>Similarly helpful for quickly finding the window you want are the new thumbnails in the window list. This works just like its Windows equivalent -- hover a tab in the task bar's window list and you'll get a little preview of that window. Again, it's easy to turn this off in the window list applet preferences if you prefer the simpler tool tip look. Similar previews also show up in the Alt-Tab switcher if you pause between presses of the tab key.</p> + +[image="mint173-win-list.jpg" caption="The taskbar's window list now features an option to show image previews."] + +<p>Cinnamon's Nemo file manager gets one noteworthy new feature that again, while small, simplifies an every day task, in this case renaming files. Nemo's new "quick rename" feature allows you to rename files with a "slow" double-click. You'll have to turn it on in the Nemo preferences (under the Behavior tab), but it makes it far easier to quickly rename things (it'd be nice to have a keyboard-based way to do this as well, perhaps using "enter" rather than return to trigger it).</p> +<p>Cinnamon's already excellent support for HiDPI screens has been further improved, particularly if you connect to a HiDPI TV over HDMI. There are also improvements for HiDPI support in the login screen, including a fix for a bug that would sometimes cause the login screen to be very small. Instead of simply doubling the scaling value it actually calculates the best value between 1x and 2x based on your screen.</p> +<p>Earlier I mentioned that Mint probably wouldn't work well on a tablet, but there is one place this release improves at least touchscreen support -- there's a new on-screen keyboard in the login screen which means it's easier to log in from touch screens and mobile devices.</p> +<p>Cinnamon 2.8 is a welcome update, but it's worth noting that, while Cinnamon is now available in quite a few distros, Linux Mint remains the stablest, best implementation around. In fact, in my testing Cinnamon 2.8 was considerably buggier than previous versions I have tested with the otherwise very nice Fedora 23. It's hard to say where the blame for that lies, or if anyone is to blame at all, but at the end of the day if you want the best Cinnamon experience, you'll find it in Linux Mint.</p> +<h2 id="linux-mint-mate-edition">Linux Mint MATE Edition</h2> +<p>The Cinnamon Edition of Linux Mint is very clearly the flagship release. However, while Cinnamon is Mint at it finest, there is also a MATE-based edition Linux Mint which ends up something like Cinnamon light and makes a good option for older or less powerful hardware.</p> + +[image="mint173-mate-desktop.jpg" caption="The default Linux Mint 17.3 MATE desktop."] + +<p>Linux Mint 17.3 features MATE 1.12 and includes some very nice new features, including support for more window managers out of the box. In previous releases MATE gained support for Compiz (complete with old-school wobbly windows, not enabled by default when you switch the Compiz). Now MATE supports two more windows managers, Compton and Openbox. The latter is particularly welcome since it's very lightweight and will go a long way to make MATE feel faster on less powerful hardware. The display manager switcher itself has also been updated and can now switch on the fly, eliminating the need to log out and log back in for changes to take effect.</p> +<p>A fair bit of what's new in MATE involves porting features over form Cinnamon. For instance the power applet features mentioned above are also available in MATE, albeit through a much-simplified interface.</p> +<p>There's some added hardware support in this release as well, particularly for touchpads, which now offers support for two and three finger taps/clicks for right and middle clicks respectively. There's also now an option to use Apple's so-called "natural scrolling" which reverses the direction of scrolling.</p> +<h2 id="linux-mint-17.3-under-the-hood">Linux Mint 17.3 Under the Hood</h2> +<p>The attention to detail in Linux Mint 17.3 is not limited to desktop features, but extends down into shared, lower level features like Mint's software and update managers.</p> +<p>Linux Mint has been steadily refining its package management tools for some time now and that process is still ongoing. Consider the following rather common workflow: you install Mint from a USB stick and now you want to pull down all your applications. On most distros you open up some kind of "software center" and start downloading. End of story.</p> +<p>The same process is true in Linux Mint, but before you actually start downloading Mint helpfully offers to scan all the available software repo mirrors and find the fastest one. It tests the speed of the mirrors and makes sure that the packages are up-to-date. The tests will start with the mirrors closest to you and then work down the list. In most cases the fastest mirror will likely be close, though not necessarily the closest. In my case the default mirror selected during installation tested at 872K while the top speed available ended up being 3MB. It takes an extra minute or two, but being able to download new software and get updates at (in my case) over triple the speed is well worth it.</p> + +[image="mint173software.jpg" caption="The Software Sources app scanning for the fastest, up-to-date mirror."] + +<p>Two other very nice features new in this release include a warning in the update manager if something is wrong with a current mirror and a compatibility test for any PPAs you add. I also noticed that if you copy a PPA to the clipboard, open the software manager and click the plus button to add a new PPA Mint will automatically fill the field with what's on the clipboard. It's a small thing (and possibly not new), but it shows the level of polish and attention to detail in Linux Mint.</p> +<p>This release sees a couple of updates for a piece of software I wish more distros would copy: Mint's Driver Manager. Driver Manager now automatically refreshes, notifies you of any available updates and now indicates if drivers are Open Source or not. When Ubuntu gets back to focusing on the desktop, this would a great piece of downstream work to incorporate into Unity.</p> +<h2 id="the-bad-news-the-kernel">The Bad News: The Kernel</h2> +<p>Let's talk about what you're not going to get with Mint 17.3. Namely, the latest kernel and sub-system packages.</p> +<p>The kernel has indeed been updated since 17.2, but, as noted above, the kernel in Mint 17.3 is still at 3.19. That's not exactly ancient, but it is a good year behind where nearly every of distro is today. With the exception of a few very conservative distros primarily aimed at server farms, pretty much everything is on the 4.x kernel by now. There's a good bit of hardware support Mint is missing out on.</p> +<p>The good news though is that Linux Mint 17.3 will be supported until 2019 and the project does plan to offer kernel updates. In fact an update to the 4.2 line is in the software repositories already, though the Mint blog cautions against updating just yet, especially if you're using any proprietary drivers. The 4.2 kernel in the repos is known to not work with fglrx (ATI/AMD drivers) and ndiswrapper (a fairly common set of wireless drivers). The plan is get these problems fixed "before February 2016" at which point upgrading should be safe.</p> +<p>In other words, a newer kernel is coming so if your hardware needs it just exercise some patience. Otherwise, if you're feeling like you need a potentially system destroying holiday project you can try the upgrade now on your own.</p> +<h2 id="conclusion">Conclusion</h2> +<p>Linux Mint 17.3 is the final Mint 17 release and should put to rest any worries about Mint's plan to stick with Ubuntu LTS releases for its base. Mint has done what it set up to do, namely improve the Cinnamon desktop to the point that it not only matches, but in many places far exceeds the user experience found in other options like GNOME, and especially, Unity.</p> +<p>Indeed it's hard to look at Mint 17.3 without comparing it to its upstream base. While Mint has been continually working hard on the desktop and cranking out release after release, Ubuntu has stagnated. If Ubuntu wants to leapfrog past some of its pain points its developer would do well to look downstream. Mint's package management tools are simpler, more comprehensive, and easier to use than anything Ubuntu offers. Mint also manages to do all this without anything even remotely close to the resources Ubuntu enjoys.</p> +<p>Perhaps the most worrying thing about Mint is that it's based on Ubuntu, the future of which looks a lot less bright than it used to. There is of course Linux Mint Debian Edition, but it tends to lag well behind its Ubuntu-based brethren when it comes to updates and polish.</p> +<p>Despite the possibly cloudy future of Ubuntu, there's no reason to panic on Mint's behalf just yet. The next major step for Mint will be the transition to Ubuntu 16.04 LTS when it's released in April of 2016. At that point development on Mint-specific features will probably take a back seat to making sure that everything works with the new base. Once that's done though, expect Mint to return to focusing on what makes Mint great.</p> diff --git a/published/linuxmint173review.txt b/published/linuxmint173review.txt new file mode 100644 index 0000000..63898ba --- /dev/null +++ b/published/linuxmint173review.txt @@ -0,0 +1,83 @@ +The Linux Mint project recently unveiled Linux Mint 17.3. The latest release from this Ubuntu-based Linux distro just might be the best Linux desktop around. + +Linux Mint 17.3 arrived a few days late and had a somewhat bumpy launch thanks to some [server hardware issues](http://blog.linuxmint.com/?p=2944) that temporarily knocked the Linux Mint blog and forums offline. The final version of Linux Mint was out there, but few knew about it until a few weeks later. + +This is a big release of Linux Mint 17.3 marks the final release that will be built atop Ubuntu 14.04. Linux Mint 17.3 marks the fulfillment of the project's plan to stop chasing every Ubuntu release and focus on perfecting what makes Mint, well, Mint. When Ubuntu puts out its next Long Term Support release in April of 2016, Mint will have to upgrade its base system. + +Mint's LTS strategy was a risky move. Mint bucked several trends in opting to pass on whatever butterflies Ubuntu was chasing. Sticking with a stable base and steadfastly refusing to inflate its version numbers may well have left some users at a loss. Jests aside, turning its back on the latest and greatest GTK and kernel updates that come from tracking Ubuntu's every move is not without some costs, but overall the strategy seems to have been a huge success. + +Linux Mint has shown that it has the vision and is willing to put in the actual work to produce one the best desktop experiences around. The Cinnamon edition is not just the most polished Linux desktop around, it's possibly the most polished desktop period. Hyperbolic? Perhaps a little, but this really is the most thoroughly thought out desktop I've ever used, Linux or otherwise. + +Mint's lead developer Clément Lefebvre and team have done a great job of keeping most of the userspace packages much more up-to-date than the Ubuntu 14.04 base would lead you to believe. There are exceptions -- GNOME/GTK is probably the most noticeable, being stuck at 3.10, and the kernel also lags behind at version 3.19 -- but for the most part though the latest version of all the apps you're likely to use are either available in the Mint repos or just a PPA away. And thanks to Mint's amazing package management system finding, installing and keeping track of apps and even PPA's is surprisingly simple. + +## Linux Mint: Cinnamon Edition + +If you don't want to think about the OS you're using -- that is, if you want to click a button that says "Menu" to launch an app or open a folder named "Documents" to find your files -- Cinnamon is going to make you happy. + +Cinnamon is a desktop for people who want their desktop to get out of the way. It does not revolutionize any paradigms and it probably doesn't work very well on that mythical Linux tablet that GNOME is still waiting for, but it does offer one of the best, most polished experiences you can get on your laptop or desktop today. + +And by polish I don't mean the theme looks nice -- though it does, albeit not much different than the last few releases -- I mean the functionality and workflow. Cinnamon has smoothed down the rough edges of common tasks you do everyday, like listening to music, browsing your files and applications, updating and installing software, and getting notifications from background applications. The things you do the most are the things Linux Mint wants to improve on, not by changing the way you do them, but by making them easier to do. + +In this release that translates into a number of improvements in commonly used task bar applets and tools like the sound applet, power applet, system tray more generally, and Mint's package management system. + +Let's start with the improved sound applet which resides in the far right side of the system tray by default. + +It's a small thing, but if you like listening to music while you work you'll probably interact with the sound applet all the time. In Linux Mint 17.3 the sound applet has been improved to add playback controls over the cover art, including a progress bar you can use to skip forward and back. There's also a new right-click menu that gives you access to all the settings and adjustments you're likely to ever need are right there in the pop up window above the applet icon. If you have multiple output options you can switch between them right in the applet. As of Mint 17.3 output devices now show both their name and their origin, which makes it easier to figure out which "HDMI Audio Controller" goes with which HDMI port, for example. The applet can also quickly switch between audio players -- for example, pause Spotify and switch to your local player when you lose connectivity -- or quit audio players without actually switching apps. You can also quickly mute both input and output. + +In my testing I never encountered any music-related task that I couldn't handle right from the applet -- no need to open your music player or dive into the system settings. In fact, if you use the venerable Music Player Daemon to play your music the applet is all you need to have running. + +One final touch worth noting: by default the Cinnamon audio applet hides an audio application's native system tray applet (if it has one), if you prefer, for instance, Spotify's native applet, there's an option in the sound preference pane to tell the sound applet to stop hiding other sound applets. GNOME developers take note, it's possible to build something cool and still accept that some people won't like it and then to accommodate those people by giving them an option to turn it off. Strange that offering choices and options have become a Linux desktop feature that's worth mentioning. + +Another frequently used applet that sees a makeover in this release is the power applet. The power applet now offers, like the audio applet, more detail and control. Now you can quickly see the battery state not just for your laptop, but any attached devices like a wireless mouse or keyboard. + +The rest of Cinnamon's system tray has some improvements as well. The workspace switcher applet now shows a little visual representation of your workspaces, with little rectangles corresponding to each window inside of them. The icons are tiny, but it can be helpful if you have a lot of workspaces open. Similarly helpful for quickly finding the window you want are the new thumbnails in the window list. This works just like its Windows equivalent -- hover a tab in the task bar's window list and you'll get a little preview of that window. Again, it's easy to turn this off in the window list applet preferences if you prefer the simpler tool tip look. Similar previews also show up in the Alt-Tab switcher if you pause between presses of the tab key. + +Cinnamon's Nemo file manager gets one noteworthy new feature that again, while small, simplifies an every day task, in this case renaming files. Nemo's new "quick rename" feature allows you to rename files with a "slow" double-click. You'll have to turn it on in the Nemo preferences (under the Behavior tab), but it makes it far easier to quickly rename things (it'd be nice to have a keyboard-based way to do this as well, perhaps using "enter" rather than return to trigger it). + +Cinnamon's already excellent support for HiDPI screens has been further improved, particularly if you connect to a HiDPI TV over HDMI. There are also improvements for HiDPI support in the login screen, including a fix for a bug that would sometimes cause the login screen to be very small. Instead of simply doubling the scaling value it actually calculates the best value between 1x and 2x based on your screen. + +Earlier I mentioned that Mint probably wouldn't work well on a tablet, but there is one place this release improves at least touchscreen support -- there's a new on-screen keyboard in the login screen which means it's easier to log in from touch screens and mobile devices. + +Cinnamon 2.8 is a welcome update, but it's worth noting that, while Cinnamon is now available in quite a few distros, Linux Mint remains the stablest, best implementation around. In fact, in my testing Cinnamon 2.8 was considerably buggier than previous versions I have tested with the otherwise very nice Fedora 23. It's hard to say where the blame for that lies, or if anyone is to blame at all, but at the end of the day if you want the best Cinnamon experience, you'll find it in Linux Mint. + +## Linux Mint MATE Edition + +The Cinnamon Edition of Linux Mint is very clearly the flagship release. However, while Cinnamon is Mint at it finest, there is also a MATE-based edition Linux Mint which ends up something like Cinnamon light and makes a good option for older or less powerful hardware. + +Linux Mint 17.3 features MATE 1.12 and includes some very nice new features, including support for more window managers out of the box. In previous releases MATE gained support for Compiz (complete with old-school wobbly windows, not enabled by default when you switch the Compiz). Now MATE supports two more windows managers, Compton and Openbox. The latter is particularly welcome since it's very lightweight and will go a long way to make MATE feel faster on less powerful hardware. The display manager switcher itself has also been updated and can now switch on the fly, eliminating the need to log out and log back in for changes to take effect. + +A fair bit of what's new in MATE involves porting features over form Cinnamon. For instance the power applet features mentioned above are also available in MATE, albeit through a much-simplified interface. + +There's some added hardware support in this release as well, particularly for touchpads, which now offers support for two and three finger taps/clicks for right and middle clicks respectively. There's also now an option to use Apple's so-called "natural scrolling" which reverses the direction of scrolling. + +## Linux Mint 17.3 Under the Hood + +The attention to detail in Linux Mint 17.3 is not limited to desktop features, but extends down into shared, lower level features like Mint's software and update managers. + +Linux Mint has been steadily refining its package management tools for some time now and that process is still ongoing. Consider the following rather common workflow: you install Mint from a USB stick and now you want to pull down all your applications. On most distros you open up some kind of "software center" and start downloading. End of story. + +The same process is true in Linux Mint, but before you actually start downloading Mint helpfully offers to scan all the available software repo mirrors and find the fastest one. It tests the speed of the mirrors and makes sure that the packages are up-to-date. The tests will start with the mirrors closest to you and then work down the list. In most cases the fastest mirror will likely be close, though not necessarily the closest. In my case the default mirror selected during installation tested at 872K while the top speed available ended up being 3MB. It takes an extra minute or two, but being able to download new software and get updates at (in my case) over triple the speed is well worth it. + +Two other very nice features new in this release include a warning in the update manager if something is wrong with a current mirror and a compatibility test for any PPAs you add. I also noticed that if you copy a PPA to the clipboard, open the software manager and click the plus button to add a new PPA Mint will automatically fill the field with what's on the clipboard. It's a small thing (and possibly not new), but it shows the level of polish and attention to detail in Linux Mint. + +This release sees a couple of updates for a piece of software I wish more distros would copy: Mint's Driver Manager. Driver Manager now automatically refreshes, notifies you of any available updates and now indicates if drivers are Open Source or not. When Ubuntu gets back to focusing on the desktop, this would a great piece of downstream work to incorporate into Unity. + +## The Bad News: The Kernel + +Let's talk about what you're not going to get with Mint 17.3. Namely, the latest kernel and sub-system packages. + +The kernel has indeed been updated since 17.2, but, as noted above, the kernel in Mint 17.3 is still at 3.19. That's not exactly ancient, but it is a good year behind where nearly every of distro is today. With the exception of a few very conservative distros primarily aimed at server farms, pretty much everything is on the 4.x kernel by now. There's a good bit of hardware support Mint is missing out on. + +The good news though is that Linux Mint 17.3 will be supported until 2019 and the project does plan to offer kernel updates. In fact an update to the 4.2 line is in the software repositories already, though the Mint blog cautions against updating just yet, especially if you're using any proprietary drivers. The 4.2 kernel in the repos is known to not work with fglrx (ATI/AMD drivers) and ndiswrapper (a fairly common set of wireless drivers). The plan is get these problems fixed "before February 2016" at which point upgrading should be safe. + +In other words, a newer kernel is coming so if your hardware needs it just exercise some patience. Otherwise, if you're feeling like you need a potentially system destroying holiday project you can try the upgrade now on your own. + +## Conclusion + +Linux Mint 17.3 is the final Mint 17 release and should put to rest any worries about Mint's plan to stick with Ubuntu LTS releases for its base. Mint has done what it set up to do, namely improve the Cinnamon desktop to the point that it not only matches, but in many places far exceeds the user experience found in other options like GNOME, and especially, Unity. + +Indeed it's hard to look at Mint 17.3 without comparing it to its upstream base. While Mint has been continually working hard on the desktop and cranking out release after release, Ubuntu has stagnated. If Ubuntu wants to leapfrog past some of its pain points its developer would do well to look downstream. Mint's package management tools are simpler, more comprehensive, and easier to use than anything Ubuntu offers. Mint also manages to do all this without anything even remotely close to the resources Ubuntu enjoys. + +Perhaps the most worrying thing about Mint is that it's based on Ubuntu, the future of which looks a lot less bright than it used to. There is of course Linux Mint Debian Edition, but it tends to lag well behind its Ubuntu-based brethren when it comes to updates and polish. + +Despite the possibly cloudy future of Ubuntu, there's no reason to panic on Mint's behalf just yet. The next major step for Mint will be the transition to Ubuntu 16.04 LTS when it's released in April of 2016. At that point development on Mint-specific features will probably take a back seat to making sure that everything works with the new base. Once that's done though, expect Mint to return to focusing on what makes Mint great. diff --git a/published/notes-moz-richard-barnes.txt b/published/notes-moz-richard-barnes.txt new file mode 100644 index 0000000..889e8ac --- /dev/null +++ b/published/notes-moz-richard-barnes.txt @@ -0,0 +1,90 @@ + +> Which is still open so I would qualify that if I mention it. +> +> Okay, here are a few specific questions I have about this effort, though +> again, I'd much prefer to have something more like a discussion because +> my take on all this is somewhat open ended right now. +> +> 1) First and foremost what is the big win for users visiting a flat HTML +> site (that is, no login, no data exchange)? Which is to say, how does +> HTTPS help users outside of situations where they already have it (e.g. +> their bank, Facebook, et al)? + + +HTTPS give you auth and *integrity*. They know they're connecting to you and they know that the content is what you intended to provide. + +- subresource integrity spec: https://w3c.github.io/webappsec-subresource-integrity/#use-casesexamples let's the benefit propogate. If my 1st connection is https, and I download a link to some other site, SRI specifies a constraint of the image, SRI protects against dependencies (jquery, etc). + +Systemic benefit -- more things are HTTPS, great cannon can be prevented. widely used site + +little sites are more likely to get caught up in tracking or advertising. + + +> 2) The best answer I have come up with to the above question is that +> HTTPS stops unsophisticated MitM attacks. Do you have any numbers or +> research of any kind on how common such attack are? + +No one knows. Mozilla is trying to get such stats, but so far, says Barnes, "we don't have it. + +> 3) HTTPS consists of several layers, will Firefox be grading these +> layers on a per-site basis and letting the user know the overall level +> of security? That is, I might have implemented HTTPS, but done so in +> such a way that my server is vulnerable to Heartbleed, BOOST, POODLE, +> etc or supports a weak, possibly compromised cipher suite, will Firefox +> warn users about the potential vulnerability? If so how? If not, why +> not? + + +is there a date? + +It's already happening. New features are https, fido hardware auth, etc + +- Gradually phasing out access to browser features for non-secure websites + +For every features that goes away, the question becomes, "how much are you going to break the web for it's own good?" + +To be completely frank, I don't care about URLs I care about secure connections. So if you can get a secure connections via HSTS et al + +geo location api, get user media (mic camera), + + +HSTS and the upgrade-insecure-requests CSP + +Still treated as mixed content, HSTS you discover as you browse, + +"HSTS priming spec" + + +> 4) LetEncrypt is great, but it's still way beyond the capabilities of +> non-technical users. Yet part of what makes the web amazing is how +> simple it is to just create a few text files, put them in the folder, +> upload it to a server and you have a site (this is I believe one of the +> central parts of Mozilla's Maker efforts, that anyone can create things +> on the web). + +Fix the transport level. + +Big site concerns: + +- not too complex +- dependecies -- media sites can't go HTTPS without their ads being HTTPS as the ecosystem moves in that direction the big sites don't have to worry as much. + + +Little site concerns + +- complexity (config, etc) +- same level of automation as DNS - caddy server +- dependencies + + +> 5) 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? Is a secure web that's only 10% of +> the web better than an insecure web? +> + +Tim has been a really useful contraian voice. His views have driven the browser and web community to address concerns he has raised. HTST priming is designed to address. + + |