This post was syndicated from: The Hacker Factor Blog and was written by: The Hacker Factor Blog. Original post: at The Hacker Factor Blog
The Electronic Frontier Foundation (EFF) is one of my favorite non-profit organizations. They have a huge number of attorneys who are ready to help people with issues related to online privacy, copyright, and security. If you’re about to make an 0-day exploit public and receive a legal threat from the software provider, then the EFF should be the first place you go.
The EFF actually provides multiple services. Some are top-notch, but others are not as high quality as they should be. These services include:
If you need an attorney for an online issue, such as privacy or security, then they can give you direction. When I received a copyright extortion letter from Getty Images, the EFF rounded up four different attorneys who were interested in helping me fight Getty. (Getty Images backed down before I could use these attorneys.) Legal assistance is one of the EFF’s biggest and best offerings.
The EFF continually releases news blurbs and whitepapers that discuss current events and their impact on security and privacy. Did you know that U.S. companies supply eavesdropping gear to Central Asian autocrats or that Feds proposed the secret phone database used by local Virginia cops? If you follow the EFF’s news feed, then you saw these reports. As a news aggregation service, their reports are very timely, but also very biased. The EFF’s reporting is biased toward a desire for absolute privacy online, even though nobody’s anonymous online.
The EFF occasionally promotes or releases software designed to assist with online privacy. While these efforts have good intentions, they are typically poorly thought out and can lead to significant problems. For example:
- HTTPS Everywhere. This browser extension forces your web browser to use HTTPS whenever possible. It has a long set of configuration files that specify which sites should use HTTPS. Earlier this year, I wrote about some of the problems created by this application in “EFF’ing Up“. Specifically: (1) Some sites return different content if you use HTTPS instead of HTTP, (2) they do not appear to test their configuration files prior to releasing them, and (3) they do not fix bad configuration files.
- TOR. The EFF is a strong supporter of the TOR Project, which consists of a network of servers that help anonymize network connections. The problem is that the EFF wants everyone to run a TOR relay. For a legal organization, the EFF seems to forget that many ISPs forbid end consumers from running public network services — running a TOR relay may violate your ISP’s terms of service. The TOR relay will also slow down your network connection as other people use your bandwidth. (Having other people use your bandwidth is why most consumer-level ISPs forbid users from hosting network services.) And if someone else uses your TOR relay to view child porn, then you are the person that the police will interrogate. In effect, the EFF tells people to run a network service without revealing any of the legal risks.
The EFF recently began promoting a new technical endeavor called Let’s Encrypt. This free CA server should help web sites move to HTTPS. News outlets like Boing Boing, The Register, and ExtremeTech all reported on this news announcement.
A Little Background
Let’s backup a moment… On the web, you can either connect to sites using HTTP or HTTPS. The former (HTTP) is unencrypted. That means anyone watching the network traffic can see what you are doing. The latter (HTTPS) is HTTP over SSL; SSL provides a framework for encrypting network traffic.
But notice how I say “framework”. SSL does not encrypt traffic. Instead, it provides a way for a client (like your web browser) and a server (like a web site) to negotiate how they want to transfer data. If both sides agree on a cryptographic setting, then the data is encrypted.
HTTPS is not a perfect solution. In many cases, it really acts as a security placebo. A user may see that HTTPS is being used, but may not be aware that they are still vulnerable. The initial HTTPS connection can be hijacked (a man-in-the-middle attack) and fake certificates can be issued to phishing servers. Even if the network connection is encrypted, this does nothing to stop the web server from tracking users or providing malware, and nothing to stop vandals from attacking web server. And all of this is before SSL exploits like Heartbleed and POODLE. In general, HTTPS should be considered a “better than nothing” solution. But it is far from perfect.
Even with all of the problems associated with SSL and HTTPS, for most uses it is still better than nothing. So why don’t more sites use HTTPS? There’s really a few limitations to entry. The EFF’s “Let’s Encrypt” project is a great solution to one of these problems and a partial solution to another problem. However, it doesn’t address all of the issues, and it is likely to create some new problems that the EFF has not disclosed.
Problem #1: Pay to Play
When an HTTPS client connects to an HTTPS server, the server transmits a server-side certificate as part of the cryptographic negotiation. The client then checks with a third-party certificate authority (CA server) and asks whether the server’s certificate is legitimate. This allows the client to know that the server is actually the correct server.
The server’s certificate identifies the CA network that should be used to verify the certificate. Unfortunately, if the certificate can say where to go to verify it, then bad guys can issue a certificate and tell your browser that it should be verified by a CA server run by the same bad guys. (Yes, fake-bank.com looks like your bank, and their SSL certificate even looks valid, according to fake-ca.com.) For this reason, every web browser ships with a list of known-trusted CA servers. If the CA server is not on the known-list, then it isn’t trusted by default.
If there are any problems with the server’s certificate, then the web browser issues an alert to the user. The problems include outdated/expired certificates, coming from the wrong domain, and untrusted CA servers.
And this is where the first barrier toward wide-spread use comes in… All of those known-trusted CA servers charge a fee. If you want your web server to run with an SSL certificate that won’t generate any user warnings, then you need to pay one of these known-trusted CA servers to issue an SSL certificate for your online service. And if you run multiple services, then you need to pay them multiple times.
The problems should be obvious. Some people don’t have money to pay for the trusted certificate, or they don’t want to spend the money. You can register a domain name for $10 a year, but the SSL certificate will likely run $150 or more. If your site doesn’t need SSL, then you’re not going to pay $150 to require it.
And then there are people like me, who cannot justify paying for a security solution (SSL) that isn’t secure. I cannot justify paying $150 or more, just so web browsers won’t see a certificate warning when they connect to my HTTPS services. (I use self-signed certificates. By themselves, they are untrusted and not secure, but I offer client-side certificates. Virtually no sites use client-side certificates. But client-side certs are what actually makes SSL secure.)
The EFF’s “Let’s Encrypt” project is a free SSL CA server. With this solution, cost is no longer an entry barrier. When their site goes live, I hope to use it for my SSL needs.
Of course, other CA services, like Entrust, Thawte, and GoDaddy, may lower their prices of offer similar free services. (You cannot data-mine users unless they use your service. Even with a “free” pricing model, these CA issuers can still make a hefty profit from collected user data.) As far as the EFF’s offerings go, this is a very disruptive technology for the SSL industry.
Problem #2: Server Installation
Let’s assume that you acquired an SSL certificate from a certificate authority (Thawte, GoDaddy, Let’s Encrypt, etc.). The next step is to install the certificate on your web server.
HTTPS has never been known for its simplicity. Installing the SSL server-side certificate is a nightmare of configuration files and application-specific complexity. Unless you are a hard-core system administrator, then you probably cannot do it. Even GUI interfaces like cPanel have multiple complex steps that are not for non-technies. You, as a user with a web browser, have no idea how much aggravation the system administrator went through in order to provide you with HTTPS and that little lock icon on the address bar. If they are good, then they spent hours. If it was new to them, then it could have been days.
In effect, lots of sites do not run HTTPS because it is overly complicated to install and configure. (And let’s hope that you don’t have to change certificates anytime soon…) Also, HTTPS certificates include an expiration date. This means that there is an ongoing maintenance cost that includes time and effort.
The EFF’s “Let’s Encrypt” solution says that it will include automated management software to help mitigate the installation and maintenance effort. This will probably work if you run one of their supported platforms and have a simple configuration file. But if you’re running a complex system with multiple domains, custom configuration files, and strict maintenance/update procedures, then no script from the EFF will assist you.
Of course, all of this is speculation since the EFF has not announced the supported platforms yet… So far, they have only mentioned a python script for Apache servers. I assume that they mean “Apache2″ and not “Apache”. And even then, the configuration at FotoForensics has been customized for my own needs, so I suspect that their solution won’t work out-of-the-box for my needs.
Problem #3: Client Installation
So… let’s assume that it is past Summer 2015, when Let’s Encrypt becomes available. Let’s also assume that you got the server-side certificate and their automated maintenance script running. You’ve got SSL on your server, HTTPS working, and you’re ready for users. Now everything is about to work without any problems, right? Actually, no.
As pointed out in problem #1, unknown CA servers are not in the user’s list of trusted CA servers. So every browser connecting to one of these web servers will see that ugly alert about an untrusted certificate.
Every user will need to add the new Let’s Encrypt CA servers to their trusted list. And every browser (and almost every version of every browser) does this differently. Making matters worse, lots of mobile devices do not have a way to add new CA servers. It will take years or even decades to fully resolve this problem.
Windows XP reached its “end of life” (again), yet nearly 30% of Windows computers still run XP. IPv6 has been around for nearly 20 years, yet deployment is still at less than 10% for most countries. Getting everyone in the world to update/upgrade is a massive task. It is easier to release a new system than it is to update a deployed product.
The EFF may dream of everyone updating their web browsers, but that’s not the reality. The reality is that users will be quickly trained to ignore any certificate alerts from the web browsers. This opens the door for even more phishing and malware sites. (If the EFF really wanted to solve this problem, then they would phase out the use of SSL and introduce something new.)
There is one other possibility… Along with the EFF, IdenTrust is sponsoring Let’s Encrypt. IdenTrust runs a trusted CA service that issues SSL certificates. (The cost varies from $40 per year for personal use to over $200 per year, depending on various options.) Let’s Encryption could piggy-back off of IdenTrust. This would get past the “untrusted CA service” problem.
But if they did rely on the known-trusted IdenTrust that is already listed in every web browser… the why would anyone buy an SSL certificate from IdenTrust when they can get it for free via Let’s Encrypt? There has to be some catch here. Are they collecting user data? Every browser must verify every server, so whoever runs this free CA server knows when you connected to specific online services — that’s a lot of personal information. Or perhaps they hope to drive sales to their other products. Or maybe there will be a license agreement that prohibits the free service from commercial use. All of this would undermine the entire purpose of trying to protect user’s traffic.
Problem #4: Fake Domains
Phishing web sites, where bad guys impersonate your bank or other online service, have been using SSL certificates for years. They will register a domain like “bankofamerica.fjewahuif.com” and hope that users won’t notice the “fjewahuif” in the hostname. Then they register a real SSL certificate for their “fjewahuif.com” domain. At this point, victims see the “bankofamerica” text in the hostname and they see the valid HTTPS connection and they assume that this is legitimate.
The problem gets even more complicated when they use DNS hijacking. On rare occasions, bad guys have temporarily stolen domains and used to to capture customer information. For example, they could steal the “bankofamerica.com” domain and register a certificate for it at any of the dozens of legitimate CA servers. (If the real Bank of America uses VeriSign, then the fake Bank of America can use Thawte and nobody will notice.) With domain hijacking, it looks completely real but can actually be completely fake.
The price for an SSL certificate used to be a little deterrent. (Most scammers don’t mind paying $10 for a domain and $150 for a legitimate certificate, when the first victim will bring in a few thousands of dollars in stolen money.) But a free SSL CA server? Now there’s no reason not to run this scam. I honestly expect the volume of SSL certificate requests at the EFF’s Let’s Encrypt servers to quickly grow to 50%-80% scam requests. (A non-profit with a legal emphasis that helps scammers? As M. Night Shyamalan says in Robot Chicken: “What a twist!“)
“Free” as in “Still has a lot of work to do before it’s really ready”
The biggest concern that I have with this EFF announcement is that the technology does not exist yet. Their web site says “Arriving Summer 2015” — it’s nearly a year away. While they do have some test code available, their proposed standard is still a draft and they explicitly say to not run the code on any production systems. Until this solidifies into a public release, this is vaporware.
But I do expect this to eventually become a reality. The EFF is not doing this project alone. Let’s Encrypt is also sponsored by Mozilla, Akamai, Cisco, and IdenTrust. These are companies that know browsers, network traffic, and SSL. These are some of the biggest names and they are addressing one of the big problems on today’s Internet. I have no doubt that they are aware of these problems; I just dislike how they failed to disclose these issues when they had their Pollyannaish press release. Just because it is “free” doesn’t mean it won’t have costs for implementation, deployment, maintenance, and customer service. In the open source world, “free” does not mean “without cost”.
Overall, I do like the concept. Let’s Encrypt is intended to make it easier for web services to implement SSL. They will be removing the cost barrier and, in some cases, simplifying maintenance. However, they still face an uphill battle. Users may need to update their web browsers (or replace their old cellphones), steps need to be taken to mitigate scams, users must not be trained to habitually accept invalid certificates, and none of this helps the core issue that HTTPS is a security placebo and not a trustworthy solution. With all of these issues still needing to be addressed, I think that their service announcement a few days ago was a little premature.