letsencrypt.org will solve this problem.
> It will also pretty much get rid of privacy, since to get the cert you will need to provide someone with your detailed information.
That's something that applies to buying/owning a domain as well. Domain-verified certificates require very little private information, and I suspect letsencrypt.org might be able to provide a way to get trusted certificates without giving up privacy.
> Using self-signed certs will become harder.
How so? The proper way to use self-signed certificates would be to distribute them in a safe way (e.g. deploy them through your Active Directory Domain, provide the fingerprint through a separate channel, etc.) and install them in your trust store. I couldn't find any intended changes to this in their announcement.
> Yes, it's a good idea to use https _almost_ everywhere, but forcing everyone to use it is a terrible, stupid idea.
I agree that it should be a slow process, and I think that's exactly what they're suggesting. Eventually, when the tooling and processes around SSL/TLS catch up with the new "encrypt everything" mentality, it would probably be no big deal to deprecate almost every use-case of HTTP without SSL/TLS.
Because Let's Encrypt might solve this well, or it might not solve it well, or it might never even be released. At the moment, factual statements about what effect Let's Encrypt will have on the world are similar to "$(THIS_YEAR+1) will be the year of Linux on the desktop."
Mozilla is one of the backers behind letsencrypt. I'm sure they won't be deprecating anything until well after it is up and running. This was an email to the Mozilla community asking for feedback, not an announcement of any major deprecations in the next version of Firefox.
Letsencrypt is based on an open protocol [1], I'm sure there will be implementations for all major platforms.
If you're using a self-signed certificate, you don't need to provide information to anyone.
> Using self-signed certs will become harder.
Why?
I haven't given this much thought yet, but these don't sound like convincing arguments against the proposition.
Care to convince me otherwise?
Edit: never mind. Mailman was late.. got it now!
Edit: I bet there are 1000x more IE6 users, than users of these devices. Shall we support IE6 until every single of it's users upgrade?
Also, you are a developer. I am sure we can figure out some way for developers to re-enable plain HTTP in some hidden settings. That way people like you and me can continue to do what we do, while the rest of the web users are enjoying the benefits of being more secure by default.
I'm a developer, but my clients are not.
Getting rid of HTTP will make people more secure. It will ensure that basically all sites people visit will be protected by a trusted cert.
Note that nobody is talking about installable malware here. We are talking about protecting the web. For example, if your connection to news.ycombinator.com is protected by HTTPS, this makes it that much more difficult for the NSA to spy on you, or for me to insert a goatse into the content while you are at work, and I am sitting in the next office over form you.
No we didn't. Telnet is still pervasive as a communications protocol, partly because of its simplicity and partly because of its momentum. This is particularly true in the realm of embedded devices; even rather-modern enterprise-grade HP printers (for example) open up a Telnet port for terminal-driven configuration by default.
The analogous case might be if you're doing plaintext password authentication over HTTP. I agree that for that use-case you should switch to HTTPS.
Apple.com is a great example of this. It's served over plain HTTP, and likes to http://store.apple.com. Can I intercept that link and send you to http[s]?://store.appl.com or http[s]://store.apple.con? I can then grab your credit card. Heck, I could process your order so you won't even know something went wrong. Or how would it look if suddenly people started getting a goatse instead of the latest video of Jony Ivy tilting his head to the side?
Finally, Read this thread for use cases for http. They may not apply for you, but are sufficient that I think we can keep http around for awhile longer.
My problem is that we still allow plain HTTP. That should never be the case, just like we should not use telnet for remote server access.
DNS hijacking is a problem. It is a problem at a different layer of the system. Just because that layer is vulnerable, does not mean that we should leave a gaping security hole at a different layer. I don't buy the argument that we must have perfect security or no security. Besides, there are ways to mitigate the DNS hijacking issue, such as the HSTS header.
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.
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?
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.
How is this not going to destroy the cachability of the internet?
Being able to operate transparent caches is important for institutions (Edit: some which may not have access to their users local cert stores).
There is many things like blogs, news articles, photo galleries that gain zero value by being encrypted. Encrypting these things is going to require more hardware, more energy usage and more bandwidth and thus again more energy usage.
If my employer wants to use caching, they can install a cert for their proxy on my machine (or require me to do so), so it's not a problem - although it is more technically complex.
It only prevents caches that are in the middle and trusted by neither end. I'm okay with that in almost all cases.
I totally am for securing POSTs, HTML, etc with SSL, but images and CSS, etc really make little sense.
As an analogy this strikes me as deprecating an array for a linked list because a list has certain features that array's don't. Ie. there is a time and place for both.