▲ 180 points
back
293 comments
How about we solve the "certificate" situation first?
I've just paid lots of money for "certificates". I quote the word, because they don't actually certify or even signify anything. The whole procedure for "domain-verification" is a joke, and many outfits are incompetently run (their "verification" e-mails bounced from my servers because they ended up in RBL, which nobody seemed fit to correct).
I see this as a scam, or extortion — pay up, or you won't be "certified". And pay up significant amounts of money, if you want a wildcard cert.
If we care about encryption just for the sake of encryption, let's change our browsers to allow self-signed certificates. Label them as such, but don't label them as "unsecure", because the padlock icon really isn't any more secure than a self-signed cert.
But what kind of technology would think self-signed certificates could ever be better (let alone not infinitely worse) than no encryption at all? That sounds like hell. We should call this new, purely hypothetical protocol, SSHell, or SSH for short. Not that such a thing would ever be used by anyone, of course.
(Yes, I know that technically SSH uses key pairs; but they show you the key, you choose to trust it. Same real chance of a MITM as with a self-signed SSL certificate. But at least you (and others) can now detect when there's a change in who's sending your data, and choose who to trust yourself instead of relying on Mozilla to pick who to trust, like they did CNNIC.)
If all a domain-validation SSL cert means is that the certificate issuer could reach you via admin/administrator@domain.com - that's nearly all they do, besides ask for some payment information - why not automate that part of the process?
That is, the certificate presented by the site should be signed in a fashion that proves that whoever signed it owns the domain.
How do we know you own the domain? Because you control the DNS. If you control the DNS, you can control the domain in so many ways, including receiving the DV email, so it seems like a proper way to verify it.
If you control DNS, you can set a TXT record and put a public key in it.
So why not have browsers actually just ensure that a certificate is signed by the public key stored in DNS? Is there a good reason not to do this?
How do you check the difference between your self-signed cert for your site and my self-signed cert for your site?
You can get normal certificates for free these days and wildcard certs don't cost significant amounts of money.
At startssl you can get unlimited amounts of wildcard certs for 60 $. I know startssl isn't that popular and partly that's justified.
In summer hopefully let's encrypt will start and make it even easier to get certs for free.
Or in other words: People are working on solving the certificate situation - and even now it is not as bad as you make it sound.
Agreed. Enforcing SSL on the entire web will just mean a lot of very sloppy and bad SSL. Better to just make it abundantly clear when traffic is insecure, because that's a problem you'll have to solve whether you force SSL or not.
Let's Encrypt is scheduled to launch in mid-2015, so by later this year, the procedure to get a proper certificate will be something like:
sudo apt-get install lets-encrypt
lets-encrypt example.com
How about we solve both these problems and stop quibbling about which one we should solve first, given that they both need to be solved?
It seems kinda wrong to require encryption for say a static website receiving no input from the user in the first place.
Perhaps the web browser's shouting about security issues could be delayed until the moment when something happens where security is relevant.
> the padlock icon really isn't any more secure than a self-signed cert.
I understand this comes from a frustration, and an understanding that the certificate based authentication is not perfect. But labeling it as "as secure as a self-signed cert" when a self-signed certificate provide no authentication (or an unpractical one at best) is uncalled for.
So as long as no practical and better solution for server authentication has been found, this is the best we have and it is still working pretty well (you don't see a lot of rogue certificates in the wild).
You make a good point. This might be more of a UI issue: perhaps self-signed certificates could use a different browser icon that lets people know traffic is encrypted, but the identity of the site is not verified. Use a large "E" in the icon?
I don't mind at all visiting someone's personal site that has a self signed certificate but a UI change to avoid the glaring waring dialog would be nice.
There are large advantages of having almost all traffic encrypted.
This is especially bad on Firefox where the dialog to allow a self-signed cert isn't even very intuitive. At least on Chrome (last I checked, anyway) there is a clear "correct" thing to do if you want to allow the cert.
I wonder if web-of-trust SSL is the right way to solve this.
Well-stated. You are not the only one.
Hey, this is Richard, the author of the post. All the feedback here is great, but if you've got thoughts on whether we should pursue this strategy or not, please comment on the mozilla.dev.platform list.
https://lists.mozilla.org/listinfo/dev-platform
https://groups.google.com/forum/#!forum/mozilla.dev.platform
As I mentioned in the thread in question:
"Basically, the current CA system is - again, to put this as gently and politely as possible - fucking broken. Anything that forces the world to rely on it exclusively is not a solution, but is instead just going to make the problem worse."
Please keep that fact - that the CA system is, as I put it with all the gentleness and politeness it deserves, "fucking broken" beyond any repair - in mind.
(And no, "the CA system is fucking broken" is not an opinion; it is a verifiable fact, as much as the concept of gravity is a verifiable fact)
What is the point? If you need a secure connection then use https, if there is no value securing the connection then use http. Why deprecate a working technology that continues to have many valid use cases?
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.
It will just make it easier to create walled gardens, and charge companies and individuals for certificates. It will also pretty much get rid of privacy, since to get the cert you will need to provide someone with your detailed information. Using self-signed certs will become harder.
Yes, it's a good idea to use https _almost_ everywhere, but forcing everyone to use it is a terrible, stupid idea.
The point is that HTTP to HTTPS is what telnet is to ssh. There are no use cases for HTTP where HTTPS cannot fill that need. With free certificates available now, and more coming, there is no reason to not use HTTPS because of cost. The only valid reason I can see to continue supporting HTTP in some form is for legacy devices (consumer routers, printers, etc.) that don't yet do HTTPS. My 5 year old printer does HTTPS, so we should be able to get rid of these devices soon.
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.
This. Maybe I want all the transparent caches on the Internet to cache my stupid cat picture?
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.
I'm not saying it's a bad idea, but the thought that once HTTP is deprecated I'll need to go through extra effort to manage the myriad of devices in my LAN is bothering me. The configuration interfaces of these devices (routers, printers, IP cameras, etc.) mostly don't support HTTP. Most never had updates available and certainly never will. We're not just talking about 5+ year old devices (which despite their age still function as designed): none of the most recent routers I bought support it, except if flashed with some powerful and well maintained alternative firmware.
I'm already annoyed enough by firmware update tools that only work with a specific old version of Internet Explorer... I rather not throw dozens of equipment away just because browsers started to insistently refuse HTTP connections. Let's not talk about the fact that I often spin up simple HTTP servers on my computer just to be able to transfer files to other machines on the same network, and I rather not have to worry about creating certificates (to then find out that the machines in question are "obsolete" too and don't support HTTPS?).
Can we just consider HTTP to be like telnet? Old, super insecure, definitely not meant to be used by everyone daily and definitely not over the Internet, perhaps not even available/installed by default, yet super compatible and simple to implement both for the client and the server.
I really hope that should mandatory HTTPS become a thing (and I'm not saying it shouldn't), an exception is added for local area connections.
This just makes me think that we need is not an "improved HTTPS", but to rip out TCP/IP and encrypt everything at that level.
Now we only need to convince either Google or Microsoft to implement something like that in their OS and encourage/mandate the use of it. Only these 2 matter because they are the owners of the biggest platforms.
Yes Apple has a pretty big platform, too, but it's kind of irrelevant since it's a closed Apple-only ecosystem anyway so if it adopts something it doesn't mean the others will too. On the other hand, if either Android or Windows adopts something as major, I think the other one would, too.
What I'm thinking is something like MinimaLT or perhaps Trevor Perrin's "Noise" if it ever becomes real.
Share those thoughts on the mailing list.
I find myself with some cognitive dissonance. This makes perfect sense.
But selfishly, I've worked for many corporations that operate an http proxy that they scrutinize and they proxy https which they cannot scrutinize (without detection), so I feel comfortable that they are not. (Yes I periodically review the certificate store for changes).
If the vast majority of sites were https, they might decide to do MITM for those https connections and either instruct everyone to ignore the warning or install their own certs on all of the computers. Indeed I think many corporations may already do this. I would probably not use many websites if they made that change.
Wouldn't the corporation install it's own root certificate in that case? you can MITM without notification. presumably they could tack it on after workstation install.
If they're already going through the trouble of monitoring everyone's traffic, a few extra steps don't seem like that big of a hassle.
Of course, you're right, some large fraction won't bother with their own root cert, and their users will learn many bad habits.
This ship has long since sailed. SSL HTTPS interception for corporate entities is off-the-shelf and readily available.
I don't think there's anything inherently bad about trusted MITM. If the trust exists, then you can have a local caching proxy that can drastically reduce the load on servers, WAN links, etc, and is a major part of Roy Fielding's original description of the REST architecture. [1]
IMO, I think the majority of use cases that people care about with HTTPS are about integrity (i.e. authentication) rather than confidentiality. We don't need full-on encrypted requests for those use cases, we just need secure MACs[2] (significant performance difference) as part of the standard so that endpoints can verify it hasn't been tampered with, even if it's been cached somewhere along the way.
[1]https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
Scrutinizing traffic like that is dumb anyway because if a hacker gets in he could get control of such a system and "see everything".
As a principle, the benefits of encrypting everything always beat the benefits of "monitoring everything" in an enterprise.
> cognitive dissonance
Off-topic, but why can't people say "I'm not sure" or "I can see both sides of this argument". It's just an overused geek cliche.
All I ask is please don't block non-HTTPS sites from browsers. I don't want to have to set up a valid SSL cert for every development environment I work with.
Nobody has brought this up yet:
If we deprecate HTTP, then certificates can be used as tools of censorship by governments.
We require an alternative to the current HTTPS scheme first.
It's unfortunate that this is necessary. I like the concept of decentralized cache systems, but in the future CDN will be the only option for low latency.
Generally, I think this is a bad approach. I think that configurable blocking of HTTP with user-controlled (or, for managed environments, policy-controlled) opt-in to allow HTTP for safe domains makes some sense. But not deploying new features for HTTP and limiting existing features on HTTP does not; true, one could set up a root CA and deploy certificates and manage TLS for internal, including local-box, testing, etc., but it doesn't make sense for browser to require it.
Configurable blocking of HTTP provides all the benefits of HTTP deprecation without the adverse side effects for the situations where HTTPS is an unnecessary headache, so it should be preferred.
The biggest downside I see is that it would no longer be possible to host a simple website, without also having to publicly expose the vastly increased attack surface that the OpenSSL code base brings to the table.
If this is a very long-term plan, I'm all up for it. In the short term, we're just not quite where we need to be in order to enable SSL even on less-important sites or sites that don't require any credentials.
From a hardware perspective, I'd say that by now the problem is actually solved. Hardware is powerful enough to handle SSL connections.
What's currently tricky is that too big a chunk of clients still doesn't support SNI which really doesn't go well with the increasing scarceness of IP addresses.
Needing one IP address per unique domain name, aside of the administrative overhead (multi-homing still is somewhat inconvenient) will just not be feasible as the costs for IP addresses is starting to skyrocket.
This will be fixed by either IPv6 growth (you wish) or the death of non-SNI systems, but it'll be years if not decades before we can ignore XP and Android 2.3, especially as there's no good fallback path for these clients as the SSL negotiation (and subsequent hostname validation failure) happens way before the host could react.
Doesn't HTTPS require a dedicated IP address? With the exhaustion of the IPv4 address space, the timing couldn't be worse.
I agree with some of the skeptical comments here, and wanted to add one more use case they are not thinking about: http://localhost:NNN/
There are many cases where you might want a service on localhost to be reachable via HTTP. Technically this should be exempt from https rules entirely, since who would the man in the middle be? If someone can MITM 127.0.0.1, they own your box already.
It is impossible to get https certificates for localhost/127.0.0.1, making SSL with an approved cert impossible for local services.
I am wondering if this will go anywhere. It seems to me that if anyone would be willing to do this it would actually be the Chrome team, not Mozilla. Mozilla currently lacks the market share to pull this off, and lately their moves have been more targeted in a different direction.
Having said that, I am really happy others are thinking along the same lines as I: HTTP should be relegated to a legacy protocol and the warnings need to very similar to what you get when accessing a site secured by a self-signed cert.
The recent disabling of TLS1.0 on so many sites means I'm finally going to have to upgrade my cell-phone, as there aren't any TLS1.1+ supported browsers for PalmOS.
What about devices I access via IP address which have no DNS. Like my home router, or my printer, or my iPhone when I'm connecting to an admin web interface, or my NAS...?
Obviously I'm not going to setup a home domain, DNS, and SSL certs installed on all these devices just so they can use the latest HTTP/2.x features in their admin panels or user interfaces?
What the hell. Someone please stop this madness.
I know Google wants to do something similar with Chrome.
I have so many comments - but the first being don't they realize that they will have to make this option which will be disabled by most enterprises?
In order for this to really take off a campaign with the popular basic plug and play hosting providers to install free/cheap SSL would be needed.
Do child protection software filters work with HTTPS?
In my opinion:
* A big warning sign when the site is not using TLS, but not a pop-up
* No warning when the site is using TLS
That would be a correct way to force websites to use TLS.
First .google domains, now this? We should stop using this stupid thing named DNS.