Can you list some of the use cases where you can do something using HTTP that you can't using HTTPS? I had always assumed one was a superset of the other, feature-wise.
As long as HTTPS offers all features of HTTP, then the reason to deprecate HTTP is to prevent accidental use of it, and websites which don't know/care from leaving their users vulnerable.
Things you can do with HTTP that you can't do with HTTPS:
* Create a website for free (you have to pay for certificates to use HTTPS)
* Report sensor data from small embedded devices with extremely limited CPU
* Your JS can talk to APIs that don't yet support HTTPS (e.g. NextBus). If your serve your JS over HTTPS, your browser will complain if you try to access a HTTP-only API.
* Transfer large files at gigabit speeds on consumer-grade hardware
> Create a website for free (you have to pay for certificates to use HTTPS)
No you don't. You can get free certificates.
But even if that was true, it's still a misleading argument. You can only make a website for free if you are OK with your website not having a domain name and running it off your personal laptop with electricity paid for by your roommates/parents. For any actual website, there are already a multitude of real costs of which a certificate is just one more.
> Report sensor data from small embedded devices with extremely limited CPU
If your CPU is really so limited then why are you using HTTP at all? Use a custom binary protocol with or without encryption as appropriate.
> Your JS can talk to APIs that don't yet support HTTPS (e.g. NextBus).
Then those APIs suck - avoid them and/or ask the providers to get with the program.
> Transfer large files at gigabit speeds on consumer-grade hardware
AES-NI can decrypt at 3.5 cycles per byte. With modern consumer grade hardware you will not find symmetric streaming crypto to be a serious bottleneck.
> You can only make a website for free if you are OK with your website not having a domain name and running it off your personal laptop with electricity paid for by your roommates/parents.
Actually, if you are willing to do without your own second-level domain name and just have a third- or fourth-level domain name, there are plenty of services where you can have a free web site (or app) running of over HTTP. E.g., any number of free (or free-within-limited-quota) static site hosting services, or even Google App Engine.
Of course, in the Google App Engine case, you also get HTTPS for free (within usage quota), as long as you are willing to have an <app>.appspot.com domain name, so the "create a website for free" isn't really a "with HTTP, but not HTTPS" thing.
Sure, although GAE is blocked in China. AWS works, and has a free tier that will get by for a year, but doesn't give you free certificates.
Also, for a lot of newbies, installing SSL certificates is a PITA.
0. You realize you need a SSL certificate. You're presented with a dizzying variety of options and already lost. Are you supposed to get Positive SSL, Negative SSL, Essential SSL, Comodo SSL, Start SSL, Wildcard SSL, EV SSL, Rapid SSL, Slow SSL, or EV SSL aux Mille Truffles et Champignons? Most newbies ask, "Why isn't there a simple [click here to get HTTPS certificate] button?"
1. You get your certificates by e-mail, but you still can't install them directly. Your webserver wants a .pem file, so you Google "How do I create a PEM file". The top 10 tutorials tell you to concatenate THREE files: your_domain_name.crt, DigiCertCA.crt, and TrustedRoot.crt in that order. What you received by e-mail was FOUR files: AddTrustExternalCARoot.crt, COMODORSAAddTrustCA.crt, COMODORSADomainValidationSecureServerCA.crt, and your_domain_name.crt. You're lost, no tutorial is helping with what to do with FOUR files instead of THREE, in what order to concatenate them, and StackOverflow bans your question. You're fed up, quit, and use HTTP. (Not me; I'm describing an actual case of observing someone else's frustration trying to set up HTTPS.)
The only way HTTPS will gain popularity is if we can get rid of the certificate-issuing economy and make it easy for newcomers. The majority of content creators unfortunately do not understand the basics of security nor can we expect them to have the patience to learn it.
@Hello71 That was funny :)
But with all due respect,
apt-get install apache2
or even opening up Ubuntu's GUI package manager and clicking Apache and then "Install" gets you a running webserver, zero questions asked. SSL certificates are a longshot from that. You're bombarded with questions throughout the process; I still can't memorize the command to generate a CSR. Also, from the perspective of achieving the objective of sharing content with the world, a website is a necessity while SSL is optional. In general, optional things that want to succeed need to be dead zero friction. Necessities like web servers can be hard and people will still get them because there's no alternative.
When Ubuntu can get you a working SSL web server, CSRs generated, certificates all auto-signed by authorities, set up and ready to go, zero questions asked, with
apt-get install apache2
that will be the day HTTPS will outshine HTTP. Yes, I know cryptographers are tearing their hair out at the thought of "auto-signed", but it would be a hell of a lot more secure world than now, because people would at least use HTTPS, rather than now, when the process is just seriously too much for most people that they end up resorting to HTTP instead. Better of two evils.
Alternatively, browsers should not throw huge error messages about self-signed certificates. They should just do what SSH does instead: display the fingerprint, ask yes/no, store the fingerprint, and warn the user if the fingerprint changes in the future.
That. I have managed to get through the steps but there was nothing simple about it and I wouldn't be able to replicate it without looking it all up again. Unfortunately, SSL isn't even an option on my el-cheapo shared webhosting service (as I understood it, it needs a dedicated precious IPv4 address).
Contrast this with Dan J. Bernstein's wonderful CurveCP. It's so simple to set up and requires no CA involvement; you just need to be able to add a NS server entry.
> as I understood it, it needs a dedicated precious IPv4 address
A good webserver would actually be able to provide multiple SSL certs on a single IP address by using "Server-Name Indication" (SNI). This is definitely (as far as I know) supported on nginx, and probably supported by Apache's httpd.
0. You realize you need an HTTP server. You're presented with a dizzying variety of options and already lost. Are you supposed to get Apache, Navajo, NGINX, IIS, Jetty, lighttpd, heavytpd, httpd, or ApacheNavajoNGINXIISJettylighttpdheavytpdhttpd? Most newbies ask, "Why isn't there a simple [click here to get HTTP server] button?"
1. You get your server by wget, but you still can't install it directly. Your OS wants an executable file, so you Google "How do I create an executable file". The top 10 tutorials tell you to use some software called Eclipse, but that needs some kind of "JVM". What you received in the archive was some ".c" crap. You're lost, no tutorial is helping with what to do with .c files, in what order to concatenate them, and StackOverflow bans your question. You are not fit to operate a computer. (I made this story up too.)
The only way HTTP will gain popularity is if we can get rid of the different servers available and make it easy for newcomers. The majority of content creators unfortunately do not understand the basics of security nor can we expect them to have the patience to learn it.
It actually is (or at least was; it's going to be significantly castrated soon) possible to "create a website for free with HTTP, but not HTTPS" if you use Heroku. An HTTP-only, single-1x-dyno setup is free, whereas if you want HTTPS, they will try to bleed you dry.
> You can only make a website for free if you are OK with your website not having a domain name and running it off your personal laptop with electricity paid for by your roommates/parents.
Many online free hosting sites that give you a subdomain are HTTP only because wildcard HTTPS certs are expensive.
Many of those services would go away or turn paid-only in an HTTPS-only world.
The children of the future have already lost Geocities and dial-in BBSes that we grew up with; how will they manage if their Internet isn't exactly like ours? /s
> If your CPU is really so limited then why are you using HTTP at all? Use a custom binary protocol with or without encryption as appropriate.
I might not want to write the client for said custom binary protocol.
Like it or not, a lot of embedded devices (Arduino, Spark Core) provide libraries for serving JSON over unencrypted HTTP. Restricting yourself to devices that are more powerful (say, Raspberry Pi 2) would require you to use a bigger form factor for the hardware, and/or would cost more.
No, but prices will go up. Free tiers will be significantly reduced or outright eliminated. Cheap tiers won't be as cheap anymore. A lot of individuals and small businesses will now suddenly be faced with more costs, and while $30/month might seem small to you, that adds up considerably over several years.
Not everyone on the internet is a multi-millionare YCombinator alumnus.
... Please. You're talking about the difference of a single paid plan or something. There's no viable product or company out there now where $30 a month is even make anyone blink.
Maybe if the entirety of your perspective comes from massive multi-million-dollar websites. For everyone else (particularly Mom-and-Pop small businesses, individuals trying to sell things online, etc.), that cost can very well be prohibitive, particularly when it dwarfs the costs of site hosting and even the domain name.
I'm talking about the little taqueria across the street from my house. They're perfectly viable, yet are going to be scared off from investing in a cert if it's going to be the single most expensive thing for their online presence. It's these sorts of folks that your argument blissfully ignores.
> AES-NI can decrypt at 3.5 cycles per byte. With modern consumer grade hardware you will not find symmetric streaming crypto to be a serious bottleneck.
The "old style" Raspberry Pi and, iirc, also the B2, don't carry crypto accelerators, and these are the first choice for people doing embedded linux prototyping.
I wouldn't exactly count on this. Chinese "pi alternative boards" already include gigabit ethernet, Android apparently also includes support for wired LAN (but somehow the manufacturer of my tablet went broke before they could sell the adapter cable)...
It is only an issue if you actually care about security. If all you want is a checkmark or the ability to show up in browser then that is more than good enough.
Their customer service is appalling, but you pay for what you get.
The original point was that requiring HTTPS would mean free-to-host HTTP services would go out of business as it was impossible to provide free HTTPS certificates, and in that sense, StartSSL proves them wrong.
The only free certificate authority that actually exists right now that I'm aware of is StartSSL, which I've at least found to be pretty damn horrendous to work with, and which only supports non-commercial uses of certificates, meaning that small businesses are still forced to pay up.
And no, Let's Encrypt doesn't count, seeing as it's not operational yet.
> For any actual website, there are already a multitude of real costs of which a certificate is just one more.
That's one more that can mean the difference between a mom-and-pop shop having a website and said shop not having a website because it's too expensive.
Just because plenty of factories dump industrial waste into rivers doesn't mean that I'm not an asshole if I dump a bottle of OxiClean down a storm drain.
> * Report sensor data from small embedded devices with extremely limited CPU
This proposal is specifically about web browsing.
> * Your JS can talk to APIs that don't yet support HTTPS (e.g. NextBus). If your serve your JS over HTTPS, your browser will complain if you try to access a HTTP-only API.
I believe that is the point of this proposal. NextBus will probably never switch to HTTPS without external pressure to do so.
Also: set up a web site on a private network, which works without modifying every browser/OS that needs to access it (e.g. installing a custom root cert), and which doesn't depend on a third-party organization. (e.g. a CA)
This will still be a problem even when you can get free domain-validated certs from Let's Encrypt. That's still an outside dependency for a private system.
Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.
In theory, HTTP is a subset of HTTPS. But that subset is much simpler for common tasks. HTTPS requires you to either subject yourself to the complexities of the CA system or be accused constantly of attacking yourself and everyone else who visits.
So why not require HTTPS, and let a thousand "make HTTPS simple" startups bloom? Seems like we're saying "we should just accept insecurity because we can't think of an alternative".
> So why not require HTTPS, and let a thousand "make HTTPS simple" startups bloom?
Much the same reason we don't all cut our hands off and let a thousand prosthetics startups bloom, I think.
> Seems like we're saying "we should just accept insecurity because we can't think of an alternative".
It seems more like we're saying "We should unnecessarily break the free Web and just cross our fingers that somebody figures out how to fix it sooner or later."
The analogy doesn't hold. There's absolutely no value in all chopping off our hands, but there _is_ value in requiring all traffic to go over HTTPS.
We can deprecate HTTPS for a decade without actually disabling it, and in the unlikely event that we _don't_ figure it out, we can undeprecate it some years later.
> there _is_ value in requiring all traffic to go over HTTPS.
I'm not so sure. It seems to me that there is almost no value in requiring all traffic to go over HTTPS compared to requiring a subset of traffic to go over HTTPS.
> We can deprecate HTTPS for a decade without actually disabling it, and in the unlikely event that we _don't_ figure it out, we can undeprecate it some years later.
If you want to deprecate it in name only, I guess I can't object since we wouldn't actually be doing anything. I'd figured this would involve trying to hinder HTTP use (similar to how we make self-signed certificates a royal PITA). At any rate, I think you're overestimating the likelihood that we'll figure it out in the short term — particularly given that the proposed happy scenario is to deprecate HTTP and then have thousands of additional for-profit actors trying to put themselves between people and the ability to have websites.
Probably Baidu thought the same thing about their Javascript. It's a public file, so why use HTTPS? Then they got turned into the Great Cannon and now they're being described as a weapon of the PRC in major newspapers.
It's obvious that governments are systematically weaponising any non-SSLd connections. If you don't use SSL, you're making it easier for them to hack your users and turn your website into a weapon. If you wouldn't let botnets run wild on your servers, you should take the same care to encrypt your website.
Yes, it absolutely does. If they actually use that CA to MITM connections, it is usually detected pretty quickly, and browsers quickly revoke that CA's trust.
Even in a scenario where this doesn't happen, it elevates the required attack from a passive eavesdropping attack (which is comparatively simple to conduct en masse, and to analyze data retroactively) to an active attack (which must typically be done in a targeted, real-time fashion).
Some people run TACK. Chrome also, IIRC, reports back on when certs have changed and Google can clearly see if there's widespread disagreement on what key is being served to visitors.
Chrome pins the Google certs, so MITM will only work if you get the user before they've first downloaded Chrome. And then you have to ensure you only ever MITM those clients, or your attack will be detected.
And TACK literally was designed to solve this problem. If the MITM interferes with you communicating to other TACK clients, you detect their attack. If they don't, you detect their attack.
People may need to run embedded servers on many different devices, and be able to access them. Forcing them to use not the latest version of the browser simply because they can't use it to connect to a device that costs 100k and will not be replaced every year like your average iDevice will not make anything better or safer.
The issue was authentication, not encryption. Though SSL of course does both.
Authentication can be done much more cheaply than encryption (well assuming you have the clout to force a change in standards). It could be implemented as simply as <script src="baidu" hash="a84b3">. In particular such a request could be transparently cached without security concerns.
It seems like this would still have one of the issues SSL has where it's easy to get wrong and then it's no better than not having it, except that people think they're safe. E.g. use a weak hash function and someone can write a malicious script that hashes to the same value.
Yes it does. For the umpteenth time, an unencrypted HTTP session allows an attacker to inject arbitrary content into the request/response stream. They can use this to do anything, from asking you to log in, sending them the password, to stealing credit card numbers, to presenting fraudulent content, to giving false information, to tracking you, to hijacking links from the page you are trying to view, to just showing you ads where there should be none, to defrauding the site/domain owner (via serving bogus content instead of your own).
And a MITM'd captive portal can do the same over SSL against users who don't understand the gravity of whatever warning their browser shows. For HTTPS to be everywhere, there needs to be zero reliance on certifying authorities that your uncle and grandmother have never heard of, zero dialogs/UI indicators that they'll just learn to ignore anyway, and zero effort to maintain the server-side of it.
It's a much bigger challenge, and I find it wildly cavalier for anyone to say "just use HTTPS everywhere" without directly addressing the faults pointed out by others. And by addressing, I don't mean dismissing out of hand.
Hell, I'd settle for acknowledging instead of addressing some days. There are real world problems on both sides that need to be considered.
I am acknowledging that there are issues with the CA system, and elsewhere have proposed plans for how to eliminate them from our trust chains (tldr: registrars issue you a CA that's only good for the domain you bought from them; then you are your own min-CA).
But these are two separate issues. Going from plain HTTP and HTTPS to HTTPS-only is a step in the right direction. It's also step 1. Step 2 is to drop CA's and work out a better trust system that relies on less parties being involved.
Also, let's give people some credit. Yes, some people ignore the self-signed cert warning. Some people also respond to Nigerian prince emails. We aren't talking about cutting off email because someone might get hurt. Unless you are ready to drop all untrusted certs, those dialogs need to stay in place.
As long as HTTPS offers all features of HTTP, then the reason to deprecate HTTP is to prevent accidental use of it, and websites which don't know/care from leaving their users vulnerable.