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.
Most arguments I've seen against HTTPS everywhere seem to fail to realise that it's not just the data confidentiality that's important, it's the integrity too.
If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place? If you do care about it being wrong, HTTPS isn't a bad way to help ensure that what you're getting is what the server is giving out. It's not perfect, but nothing is.
> If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place
Perhaps I'm not overly concerned with the prospect of someone altering a gif of a cat falling over because someone put ham on its face.
People can send me fake letters and post can be intercepted but it's still useful.
I'm not saying that security isn't important or that we shouldn't be securing more than we are but the argument that it's vital everything is secured is clearly false. There is traffic that I simply do not care if it is public, and the risk of it being modified (and the consequences if it is) are so low that I think the added time and stress of worrying about it would be more detrimental to me.
So if I intercepted kittens.gif and altered the content type to be 'text/javascript' and the body to be a javascript payload that tries to exploit your browser, you're not overly concerned?
Not really, since javascript loaded into an image tag shouldn't run and I was already following an unknown link to an unknown location coming from an unknown server. The risk that it was intercepted by you is low, and the consequences seem to be low too.
You're also skipping straight over the risk that it happens at all, which is a fairly important part of a risk assessment.
A more realistic situation could be a malicious attacker intercepting the cat picture and replacing it with an image containing something that could land the viewer in jail for having any trace of it on his computer (child pornography), and then sending an anonymous tip to law enforcement...
This counter-argument fails because HTTPS is much easier to implement and web servers already use it. Whereas TCP is much lower level and to make "STCP" we would have to recode servers entirely to handle both TCP and STCP requests from clients.
TCP is a transport level protocol. It's job is to get messages from A to B in a way that tries to guarantee delivery (amongst other properties). HTTP is an application level protocol, it's job is to encapsulate messages and commands between two applications that may be remote. We have already built mechanisms that secure traffic on the transport layer (see IPSec) and they actually work well when they're needed/useful. It turns out that right now, securing data on the application layer is much easier / cheaper than trying to do IPSec everywhere.
Finally, HTTP is a bit of a special case, because much of the time data delivered over HTTP is code that's going to be executed on a client's machine. If anything, this makes it much more important that the integrity is preserved.
Cryptography cannot be separated from authentication, and only the application can know how to do authentication. E.g. emails are designed to be forwarded between servers and not care about the exact path they take, so it would be foolish to apply hostname-based encryption to emails; instead emails are (or should be) encrypted using S/MIME or OpenPGP, to the specific intended recipient. It's then fine, indeed desirable, for these encrypted emails to be passed around over cleartext transports such as TCP.
> Cryptography cannot be separated from authentication
Frequently repeated but still wrong. Cryptography requires one of the following:
1. Two key pairs, or
2. A shared secret.
The shared secret implies authenticity. But there are entire classes of cryptosystems based on not knowing with whom you are communicating. Crypto establishes a channel through which Alice and Bob can then negotiate authenticity. (To put it in simple terms: it's better to be phished over secure transport than to be phished over plaintext.)
For some reason, a large number of people seem to have completely skipped over this basic advantage of unauthenticated channels: you have now isolated the communication to you and your prospective phisher. This is a gain, this is an advantage, and it borders on absurd that people go to such lengths to deny this.
Cryptography without authentication still provides protection against (non-MITM) eavesdroppers, which is very important with public wifi networks nowadays.
Which is why it's strange that self-signed connections are represented to the user as dangerous, while unencrypted connections do not have such a warning even though the former is strictly better.
Public WiFi is the anti example since if you can read to the WiFi, you can write to it and MITM connections. Passive is probably best, right now, against large scale fiber taps. And only as a stopgap.
jhourcle has addressed this for his type of data with an https side channel for checksums of files available for download. See the response to the comments (also explains why rsync is not appropriate in their system for a specific class of file).
jhourcle is not against https, but he/she wants the ability to use http where an exception is needed. The cost of the certificate is negligible, but the ability to keep a fragmented, heterogeneous (age wise) environment is part and parcel of the job, and NO additional funding is being provided to accomplish or operate this under https.
From reading the original and the response to other comments, it is apparent to me that jhourcle has thought this through and is only asking for an exception process that they can file for. Just as they do today for systems that are not in compliance (not related to https) for various reasons (ref: comment response).
HTTP is very useful for caching and mirrors for Linux distributions because signatures are checked by package managers outside of the transport protocol.
And additionally signature verification provides far better security than HTTPS on its own because a compromised mirror cannot compromise the signature.
What about confidentiality of the package downloads though?
e.g. Snoop the traffic, notice they are downloading a fix, they probably don't have it, automatically attack them before they apply it.
HTTPS doesn't protect much from that either. A third party can figure out what you just downloaded based on the download size, since the size of package files are well known. Even if there is some uncertainty between sets of packages it could be inferred from your other downloads, since decisions on what to download are based on known logic (dependency tree, what the victim likely had installed before, etc).
I suppose in your case the window would be smaller using HTTPS, as the package downloaded could probably be inferred only after the download is complete. But your method would need automation anyway, so I don't think the difference in timing would really matter in practice.
But if you are in the position to automatically attack someone, why wait to see if they are downloading a fix? Why not just try to attack with known recent vulnerabilities anyway?
Imagine you've MITM'd funnycatpictures.com. Why, as an end user would I care about the integrity of the funny cat picture you maliciously send me. Provided it is still a funny picture of a cat, your evil http version of the website is still just as useful as the original.
There are a lot more funny cat picture sites than banking websites. They are fine using the same protocol they have been since 1995.
We could really do with an HTTP referent-integrity specification. Just as you specify the size of a linked image, you could add a hash to specify the expected content of a resource. Particularly useful with large linked non-browser resouces.
HTTP: here is the length (response header) and here is the payload transfered with checksums (tcp).
HTTP has quite good integrity of the data you requested.
If you mean HTTPs is great to check if it's coming from the right server (identity/authority) then well, see how well the CA system works and how weak certificates really are (e.g. "Ron was wrong, Whit is right").
You can work around that by doing certificate pinning (see google chrome for example) and stuff like that, but in that case I'd already be better off signing the payload and sending that as part of the response.
The scientific institutes of germany worked around all the CA headaches by becoming an intermediate CA (see who signed https://www.pki.dfn.de/ ). I'd just expect more intermediate CAs popping up as a result of HTTPs only which will weaken HTTPs even more.
(And yes, I'm using https everywhere and would enable https for just about every site, except e.g. for linux iso downloads and alike)
HTTP has quite good integrity of the data you requested
Not for the values of "integrity" that include the possibility of intermediate tampering. You have no indication that the request received by the server is the one you sent, nor the response that you received is the one that the server sent.
Except HTTPS does not (currently) solve data integrity issues in real life use cases, getting a certificate issued for someone else's domains is far from difficult... Especially since DNS is still plaintext.
From what I can tell, they're only resellers, the companies that actually issue the certs are GeoTrust and Symantec.
In any case, I know it can and does happen, I just don't agree that it is "far from difficult". Having to hack an SSL provider is out of reach for the vast majority online thieves and casual snoopers.
Well yes, none of them would actually have their own name on said certs. But all of them had API access to make symantec or geotrust issue certs. End result is the same.
Having been involved in all of the hacks I linked, I wouldn't describe them as anything extraordinary.
Well yes, none of them would actually have their own name on said certs. But all of them had API access to make symantec or geotrust issue certs. End result is the same.
Last time I used a RapidSSL reseller, I had to authenticate my domain against a GeoTrust controlled page before the cert was issued. Is this not the case with WebNIC?
DNSSEC is meant to solve the integrity issue. Now, whether you feel it actually does the job is another matter.
Personally, I use it on three domains, one which was done for testing purposes, and the other two because there are DNS records I would like to keep secure from manipulation. It'd be nice if TLSA/DANE was more widely supported, if only to be an additional bar against certificate forgery, but unfortunately it's not.
It'd be good if DNS servers other than Knot had decent native support for signing, but they don't in general.
Sorry; but this is just ignorant. If you request a carrot cake recipe but receive a modified recipe that uses arsenic instead of carrots.. Without https, this kind of thing can easily happen. You think you are downloading poison control instructions but instead the instructions are modified; causing death or injury. HTTPS is not for "sensitive" data but for the integrity of all data. Imagine going to a voter registration page in Africa; you show up at the address and it's an ambush by anti-democracy militants because they were able to hijack the information on the official website.
The 1990s bullshit opinion that HTTPS is somehow only for 'sensitive' data is very destructive to a safe Internet.
> If you request a carrot cake recipe but receive a modified recipe that uses arsenic instead of carrots.. Without https, this kind of thing can easily happen
I can easily get struck by lightning when I go outside in the rain. I can easily get eaten by mountain lions who break out of their cages when I go to the zoo.
There being a one in ten million chance of something happening doesn't dismiss all of the valid concerns the linked article raises.
The importance of HTTPS' added security is something for both the host and user to consider. The host can choose not to implement it, and the user can choose not to trust/view the data if they have even the slightest possible reason to believe their data might be modified maliciously in transit; or tracked for some sort of profiling that they want to avoid.
As it stands, I'm weary about accessing any Chinese servers without HTTPS; but I'm not at all concerned about my ISP or government MITM'ing my connections to Ars Technica for nefarious purposes. Nor do I care in the slightest if my ISP knows I read a story there about Norway planning to drop FM radio transmissions.
> the user can choose not to trust/view the data if they have even the slightest possible reason to believe their data might be modified maliciously in transit; or tracked for some sort of profiling that they want to avoid.
If every internet user were educated enough to behave in such a way, then I'd say that would be a fair suggestion, but I don't think it's reasonable to expect that the average user is capable of making such judgements.
+1
And the premise that some commenter on HN should even enter into an argument about which of YOUR data is sensitive is destructive. It's your security. You should decide what imperils it.
This is basically gaslighting. Network security is real and people really need it. Please refrain from shaming people for talking about the things they need.
You know, in this case, there'd be nothing wrong with making checksums available via https (to verify integrity) and leaving the bulk data available over http. Mind you, 95% of people would never verify the checksums, but at least in theory it keeps their bulk data distribution easy.
In theory if you got a good original OS download the package managers would be doing all this verification automatically.
Maybe that's acctually a good idea to consider as some sort of specification. Large file download via HTTP with some HTTPS checksum available via a single click.
You consider abortion non-sensitive and you should read legal (or whatever) information with HTTP. You are comfortable with that. Someone else is not, and would want to use HTTPS.
A million times this. I cannot believe that the current HTTPS-nazis totally fail to see something this obvious.
There's countless use-cases where plain HTTP is not only OK, but probably the simplest and best option.
Trying to ban it to address some vague possibly-maybe security-related theoretical issues seems asinine.