Please consider the impacts of banning HTTP

Let's Encrypt, if it goes according to plan, is only a few months away. It's not just some fairytale that we're hoping will come true someday. It could be reality very soon! It's got some pretty big names behind it, including one of the Big Three browsers, so I'd say that it has a pretty good chance of success.

And if Let's Encrypt fails, surely someone else will try something similar in the near future. Some registrars are already handing out a free certificate with every domain. I got ~10 certificates in the last year alone, half of them for free (StartSSL) and the other half for $5/yr (PositiveSSL). The momentum is there, it's irreversible. Even if we don't hit $0, we're asymptotically headed toward it.

Moreover, given the pace at which governments and other large organizations move, I have zero worry that HTTPS-only will be "enforced" before free certificates become widely available. Ditto for browser vendors. Chrome will not risk blocking non-HTTPS websites before the time is ripe, because if it did, people will just delete Chrome and move to another browser.

This whole debate is just a bunch of FUD concerning entirely unrealistic scenarios. Why are we spreading this sickening FUD instead of, say, supporting the two well-known organizations (EFF & Mozilla) that are trying to bring free SSL to everyone?

As it stands, we punish people who want "half security" much more than people who go for "no security"

If any solution to this mess exists, it is going to require this UI. A fundamental problem with PKI is the trust decisions are not being made by the people that rely on that trust for protection.

What we need is pluggable trust, where it is easy indicate that I trust the shared-by-hand-only cert a friend made for chats between a few friends, a different cert for communications with my bank that I got a copy of by walking into a local branch, and some well-known CA for everything else. This is not "web of trust", though the concepts may overlap; this is about having a easy way to plug in whatever trust model you care to use and allowing different trust models for different endpoints.

I don't see that HTTPS-encrypting .gov websites provides much security advantage.

If Let's Encrypt is as close to completion as HTTPS-only advocates claim, then you have very little to lose by simply waiting until it's finished, and then start the evangelism. It isn't like we're standing at a cusp and tomorrow some committee's going to vote whether to permanently ban HTTP or permanently keep it. Right now it's like you're a doctor yanking a patient's access to an important medicine because "there's a better medicine coming along, it's in the last stages of clinical trials, it should be ready any month now".

As for bulk data transfers for government-funded scientific research, data integrity for anything having to do with clinical trials or personally-identifiable information is among my highest concerns. And unless we're pumping that data across private fiber, the latency and bandwidth limits of the global Internet far outweigh the overhead caused by encryption/authentication algorithms.

(I would add that I think bulk data transfers ought to be encrypted over private/internal networks as well, but that's an argument for when I'm not on mobile.)

Google is already using ChaCha20-Poly1305 inside Chrome to talk to Google servers, if your hardware doesn't support AESNI. It's been doing this since early last year, and Adam reported at that time nearly 40% of all traffic to Google was going through it (including mobile devices IIRC): https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...

Not true. It's something like 30-40 cycles per byte to do AES without specialized instructions. That makes saturating 100mbit trivial, and saturating gigabit one of the easier problems. How much traffic can your toaster and router possibly be terminating?

Don't do straw men, please. I said that it's not as big an issue as the author said it was. Nothing more, nothing less.

> Reduced performance. Increased latency. Increased complexity. Increased attack-vector size. But indeed: so what?

Not that much increased complexity in most cases. But the performance is a potentially good argument. The author should have used that instead.

HTTPS is not throwing away HTTP. It just protects it with TLS.

>Increased attack-vector size. But indeed: so what?

I think you meant 'decreased'. By not being able to modify the payloads or steal cookies, attackers are only left with the TLS protocol to try to mess with, which is a much smaller attack vector than being able to tweak HTTP headers and so-on.

It doesn't seem to me like you grasp the real world. There is a bit of a disparity between how we handle static content vs. dynamic API calls, and you demonstrate a willingness to conflate them repeatedly in this thread. It's baffling.

You are not required to have a domain to have a website; just using an IP address works fine too, and - more importantly - unlike what would happen if the proposal to ban plaintext goes through, browsers don't give big scary warnings if you use an IP instead.

As I remember it, the proposal for mandatory opportunistic encryption was that it'd still be the http:// scheme with no padlock, so no expectations are set but some benefit is there.

For example: "Stunnel is a proxy designed to add TLS encryption functionality to existing clients and servers without any changes in the programs' code."

https://www.stunnel.org/

That's a weak argument. If places like Libraries continue to block all HTTPS content, before long they would have blocked so much of the internet that the entire service would lack a coherent point.

Most sites in the top 50 are HTTPS only now. How long until they all are?

If that's the argument, it reasonably applies to everything, everywhere, and we should scrap TCP alltogether.

Instead we need to implement a replacement which ensures everything everywhere at every level of every stack does crypto as well. Let's call it STCP!

Or does that suddenly sounds zealous? It just follows from your base argument.

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)

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.

http://www.w3.org/TR/SRI/

https://wiki.whatwg.org/wiki/Link_Hashes

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).

There are a lot more funny cat picture sites than banking websites. They are fine using the same protocol they have been since 1995.

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.

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.

I can see good arguments for _encouraging_ HTTPS where necessary but not the blanket prohibition of HTTP.

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.

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.

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.

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.

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.

The problem is that the data is going to be encrypted per user https session and this adds a load to the server (say if you are streaming a movie or downloading a large file). With https the data has to be encrypted per user so there really is no caching on the output. Sure, the original data file can be in a cache, but what goes out (payload sans header) is the encrypted-per-user byte set. Unlike http where the payload across all users is the same.

And that's one of the core reasons I dislike HTTPS everywhere. It will lead to organizations like schools installing their own root certificates to MITM traffic, lessening the security of those things where encryption is the most important, like online banking.

Implementing web filtering is a condition of receiving federal subsidies; they take it seriously. A school with only a handful of PCs might use a host-based solution but proxy-as-the-only-way-out network design is very, very common.

So the question is: What is more important, allowing HTTPS proxies, or stopping governments with a CA from MitM-ing traffic (e.g. Iran, China, etc).

A nice compromise might be to inform users that they're being MitM-ed by an installed CA, but only once and subtly so.

This is also in a country which still doesn't teach comprehensive sex ed' in many places and for which many adults don't want kids to have access to that information.

I am starting to think this is some weird plot to make entry into any web software harder and protect those already here because the arguments for this don't make sense. I assume that caching is going to end.

Well, that's very non-REST.

You have not demonstrated any flaws in it, REST says communication is stateless and cacheable except for acknowledging some select minority cases when it's not the case.

Turning the minority cases into the only way of communication nullifies most of the benefits of REST, because the whole rationale of the paper is lost. I.e. intelligent shared processing and caching by intermediaries.

I'm taking no stance on what "the reality is". I'm taking no side about which side is more correct. I'm stating what both sides want, and finding it curious they don't see the contradiction.

Want more people to call bullshit when people in government use lazy arguments as an excuse to compromise privacy of citizens.

"But if there's encryption, my job is more work" arguments from NSA, CIA, FBI, military, etc, exactly like this are a huge threat to civil liberties & freedom.