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.
* 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.
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.
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.
Any plan that puts more advertising on the web is going to get a big fat thumbs down from me.
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.
Because it does not require user to install any other software and still have access to the device (PLCs and other embedded controllers)?
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.
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.
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.
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.
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.
Can't modern hardware do AES at slightly over a gigabit per second per core even without the pervasive 10x accelerators?
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.
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.
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.
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."
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.
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.
telnet www.example.com 80
GET / HTTP/1.0GET /
Sure: host a web server anonymously. With HTTPS+PKI (and it's the PKI half of this that people are complaining about) I have to claim an identity.
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, I'm sure that the communication between my browser and the test app I'm running on localhost doesn't need to be encrypted.
> It's obvious that governments are systematically weaponising any non-SSLd connections.
Over the public internet, sure.
OTOH, if a government controls a root CA trusted by your target population, TLS doesn't provide any protection at all against them anyway.
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).
Really? How?
[0]: http://en.wikipedia.org/wiki/Transport_Layer_Security#Certif...
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.
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'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.
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.