* 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
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.
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.
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.
apt-get install apache2
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
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.
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.
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.
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.
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.
Not everyone on the internet is a multi-millionare YCombinator alumnus.
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.
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.
Same for most other mobile chipsets.
Not everyone has modern hardware. My hosting provider doesn't have AES-NI for example.
e.g. https://www.startssl.com/?app=1
Also, if HTTPS became a requirement, then demand would increase for free HTTPS certificates in exchange for, say, advertising.
Any plan that puts more advertising on the web is going to get a big fat thumbs down from me.
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.
And if StartSSL is the only option, then I'm sticking to HTTP. They're a nightmare to deal with even for non-commercial use, let alone commercial.
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.
Because it does not require user to install any other software and still have access to the device (PLCs and other embedded controllers)?
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.
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.
Can't modern hardware do AES at slightly over a gigabit per second per core even without the pervasive 10x accelerators?