path: root/published/https-cuts.txt

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

---