Non-sensitive web traffic does not exist. Every request is sensitive in the sense that it's another piece of data that can be used to build a tracking profile of the computer that sent it. You might not care that a particular request is tracked, but that doesn't change anything because you may decide you do care at some unknown point in the future. Using HTTP takes that choice away.
There's countless use-cases where plain HTTP is not only OK, but probably the simplest and best option.
That doesn't mean HTTPS everywhere is a bad idea. There definitely are use-cases where HTTP would be faster/cheaper/easier/simpler/etc, but the move to ban HTTP takes all that in to account, and argues that banning it is still a good idea because the implications for privacy are simply more important than any of those issues.
I'm concerned about building profiles of internet users, probably more than the average person is, but I see the HTTP/HTTPS question as fairly marginal for that particular issue. Building profiles of users' browsing behavior is primarily done via methods that HTTPS lets pass through, such as the Facebook "like" button, Google AdSense ads, etc. Much of this data (though probably not Google's) can then be bought and cross-correlated into databases.
Something that concerns me is that the major browser manufacturers seem to be able to dictate what HTTPS certificates are OK, and therefore what sites non-technical people will have access to.
Surely a move towards centralised control of the web is not good from the tracking/privacy point of view.
The short-term benefits might look nice, but this looks to me like a long-term play. The fact that this movement has been led by Google - who value tracking - would seem to suggest that their tracking is not harmed.
Something that concerns me is that the major browser manufacturers seem to be able to dictate what HTTPS certificates are OK, and therefore what sites non-technical people will have access to.
I'd say that's more about censorship than tracking/privacy, which is also a very important issue to consider. For things like banking (this has to be the most widely mentioned use-case for SSL) it is arguably a centralised entity we're interacting with so it somewhat makes sense, but the Internet is more than that - much more.
> Every request is sensitive in the sense that it's another piece of data that can be used to build a tracking profile of the computer that sent it.
HTTPS does not solve this problem. SNI leaks the hostname of the requested resource, the timestamp of the request and, if not used in conjunction with an anonymizing proxy/VPN/TOR, the identity and possible location of the requesting machine. In case of static IPs even HTTPS-only allows a fair share of tracking and profile-building by ISP or other snoops.
> There definitely are use-cases where HTTP would be faster/cheaper/easier/simpler/etc, but the move to ban HTTP takes all that in to account, and argues that banning it is still a good idea because the implications for privacy are simply more important than any of those issues.
Where are these arguments? I haven't seen any argument that acknowledges that we are losing a big part of what made the web initially great; that it was dead simple to create your own website.
I'd respect the https-only crowd if they would acknowledge this as a legitimate big loss. But instead they seem to ignore it. I think they are just ignorant to the needs of anyone but their large corporate employers.
How much more difficult is it to get and set up a cert, compared to getting and setting up a domain? It's a hurdle, but not large compared to the existing system, as far as I see it.
But that's only if you want your own domain. Back then, people used Angelfire and Geocities, and so can you nowadays use Neocities (great project!) and get HTTPS without doing anything.
When any society (and the web is a society) starts to sacrifice the freedom for its citizens to act in public if they so choose in the name of "protecting them" from the poor behaviour of a few bad actors, it becomes awfully difficult to characterise that society as "free".
...especially if that protection involves authorisation by centralised entities. I would be far more supportive of ubiquitous encryption if it was controlled by the users.
Notice how encryption which is under control of the user (mobile device encryption, cryptocurrencies, full-disk encryption, self-signed certificates) is seen as a threat, while systems like the SSL CA model where governments could more easily obtain keys if they wanted to, are not?
"Those who give up freedom for security deserve neither."
"My choice to do something is a freedom that cannot be taken from me" is the same sort of argument people use to carry assault rifles around shopping centres. Sometimes you should be willing to give up a freedom if the result is a benefit for the whole of society, even if you happen to like or benefit from the status quo. That's part of being a member of humanity (or at least, it should be).
Surely such an argument is true for any network communication. My (admittedly vague) understanding of such monitoring is that it happens at the TCP/IP level. Therefore, should we outlaw all 'insecure' TCP/IP communication?
I can see good arguments for _encouraging_ HTTPS where necessary but not the blanket prohibition of HTTP.
> Every request is sensitive in the sense that it's another piece of data that can be used to build a tracking profile of the computer that sent it.
HTTPS does not protect you from third parties profiling what sites you visit, only the specific URL paths you access (since who you connect to is still in the clear).
In a big organization, a caching HTTP proxy server would provide the caching benefit, where an HTTPS-only Internet cannot. But while a home user has a single IP, all users behind a caching HTTP proxy server effectively share the same IP (or cluster of IPs), and are mix-anonymized (unless the proxy is not configured this way).
So sure - HTTPS ensures that URL paths accessed are private. But there are cases where there is a caching benefit and the real-world privacy-loss isn't as big as you make out in those situations.
If you're bothered about organizations spying on their users, then sure, those users can use HTTPS. My argument is about the cases where users are doing things where they want the caching though.
> Using HTTP takes that choice away.
Users and websites can still have the choice of using HTTPS. If we were talking about banning HTTPS or not requiring HTTPS to be available, then you'd have a point. But we're talking about banning HTTP. That takes choice away by definition, so don't pretend this is about taking choice away from users. In reality what you're arguing for here is to foist your choices about trading cacheability for privacy onto others by taking their choices away. There's nothing wrong with this position, but let's not pretend that it is something that it isn't.
I'm certainly in favor of sites being HTTPS only when they involve directly private information. I also accept that access to anything involves a tracking trail which in aggregate is privacy-sensitive. But where there is a caching benefit (or some other benefit) of not using HTTPS, perhaps users should have the choice to do so. Maybe clients shouldn't do it by default, and maybe it's reasonable for sites to always offer HTTPS as an option. Still, "don't ban HTTP" does have a case in such scenarios.
I think part of the problem here is that HTTP has spawned a number of use cases larger than any of us can contemplate at once. This is much broader than the general "web app" or "information browsing" use cases for which the HTTPS case is really important. "Ban HTTP" means banning all of these cases. It's very difficult to convince anyone that all use cases have really been genuinely considered on neutral grounds, and much easier to make the decision first and then pretend that workarounds are enough when a new use case is presented.
Implementing your suggestion would make things very convoluted when it all works perfectly already.
When I'm at work and want to access my online banking securely, I don't want my organization's proxy cache to MITM me. So I choose not to use my organization's MITM CA.
When I'm at work and am working on testing my reproducible server deployment, I really want to use my organization's caching proxy server so that I can download packages at 1 or 10 Gbit instead of the much lower speed of my organization's shared Internet connection.
This is very easily done right now: I use HTTPS for my online banking, and HTTP for my distribution package downloads. Everything points at my organization's proxy server, but no other special arrangements are required.
You're telling me that my organization has to roll out its own CA, implement HTTPS MITM caching, and I have to add the CA in my test deployment, all for what? So my organization can MITM my online banking, or that my organization's MITM proxy is now an additional attack surface for my online banking?
Sure, there are technical ways round this, but it involves jumping through hoops for no privacy gain. As I've pointed out elsewhere, downloading distribution packages over HTTPS offers no real privacy benefit since what users are downloading can be inferred from download sizes anyway.
Again: all I'm saying is that there are valid use cases for the current status quo.
This might sound like a stupid question, but unless I am grossly under-informed, with HTTPS, all a proxy server can do is forward the connection and the data.
The proxy could not see the URL(s) being requested, so caching is not going to work. Or is it?
The proxy can MITM the connection, as long as the browser accepts the proxy's certificate. Corporate environments tend to have their own CA infrastructure, so this isn't much of a problem for them.
> Corporate environments tend to have their own CA infrastructure, so this isn't much of a problem for them.
That's a very broad statement. Some corporate environments certainly do, and so this isn't much of a problem for them. But some corporate environments certainly do not, and so this is a problem for them. What you're essentially doing here is requiring that all corporate environments that don't currently have a CA infrastructure deploy one instead of using HTTP caching that works today. You're positively encouraging CA MITMing here.
So, some researcher sitting at his computer in his lab in his university, connecting to another university's or NASA's server, downloading freely available, government-funded research data, used to do his publicly funded research grant, the results of which will be published in a journal for the whole world to see--
This HTTP request is sensitive? It's secret? A profile is going to be built from it? A profile of what? Bob Roberts, Ph.D., University of Studyton, downloading NASA solar data to his lab computer? Oh no, poor Dr. Roberts, now the NSA will know what he downloads...
Come on. Insensitive web traffic certainly does exist. If you think it doesn't, you must have no imagination.
There's countless use-cases where plain HTTP is not only OK, but probably the simplest and best option.
That doesn't mean HTTPS everywhere is a bad idea. There definitely are use-cases where HTTP would be faster/cheaper/easier/simpler/etc, but the move to ban HTTP takes all that in to account, and argues that banning it is still a good idea because the implications for privacy are simply more important than any of those issues.