HTTPS, the cryptographic protocol used to secure web traffic as it travels across the Internet, has been in the news a lot recently. We’ve heard about security problems like Goto Fail, Heartbleed, and POODLE — vulnerabilities in the protocol itself or in specific implementations — that resulted in major security headaches. Yet the single biggest problem with HTTPS is that not enough sites use it. More than half of popular sites — and a much larger fraction of sites overall — still use old-fashioned HTTP, which provides no cryptographic protection whatsoever. As a result, these sites and their users are vulnerable to eavesdropping and manipulation by a range of threat vectors, from compromised WiFi access points to state-level mass surveillance. When deployed correctly, HTTPS defends against all these attacks.
Why don’t more sites use HTTPS? The major obstacle is that it’s too difficult for web sites to set up and maintain. Switching to HTTPS involves purchasing a digital certificate (a cryptographic statement that your domain name belongs to you) from a “certificate authority,” an identity-checking organization that users’ browsers are programmed to trust. This process involves a long series of manual steps, as well as fees that range from tens to hundreds of dollars a year. Site operators must also navigate a complicated process to generate crypto keys, validate the site’s identity, retrieve a certificate, and configure their server to use it. These steps, which have to be repeated every year or so when the certificate expires, are also prone to human error, with the result that a substantial fraction of all HTTPS sites have configuration problems that jeopardize their security.
For the past two years, I’ve been working with a talented group of people to do something about these problems. My student James Kasten and I joined forces with Peter Eckersley and Seth Schoen from EFF and Eric Rescorla, Josh Aas, and Richard Barnes from Mozilla. Our goal is to remove the barriers to deploying HTTPS and see an encrypted web completely replace unencrypted HTTP.
Today, we’re announcing Let’s Encrypt, a new certificate authority we’re creating that will begin operation in Summer 2015. What makes Let’s Encrypt different is that it takes the pain out of switching to HTTPS. Web site operators simply install a small piece of software that takes care of the entire process. This software interacts with Let’s Encrypt to validate the server’s identity, obtain a certificate, securely configure the server to use HTTPS, and automatically renew the certificate when necessary. With Let’s Encrypt, one click or one command is all it will take for a site to deploy HTTPS.
It’s also going to be free. With the rest of the process automated, arranging payment would be the one remaining headache, as well as a barrier to adoption for smaller sites and individuals. Let’s Encrypt will do away with fees and provide domain-validated certificates to nearly any server with a domain name, at zero cost.
Becoming a certificate authority isn’t a simple process, but we’ve already cleared some of the biggest hurdles. We recently completed a cross-signing agreement with IdenTrust that will let certificates from Let’s Encrypt be trusted by almost all web browsers from day one. We’re also going to work with browser makers to have our root integrated into major browsers going forward, to ensure lasting trust.
Let’s Encrypt will be operated by a new organization called ISRG, the Internet Security Research Group. ISRG, chartered to work towards a more secure Internet in the public interest, is a California public benefit corporation whose mission is to reduce financial, technological, and education barriers to secure communication over the Internet. Crucially, ISRG has “research” right in its name. It will serve as a vehicle for conveying advances from security research into practice more quickly. For instance, Let’s Encrypt will involve a number of new technologies, such as an automated certificate management protocol we’re developing called ACME, which includes support for new and stronger forms of domain validation.
ISRG and Let’s Encrypt are being made possible by an amazing group of sponsors, including Cisco, Akamai, Mozilla, IdenTrust, and EFF. We are still welcoming additional sponsors — if your company or organization is interested in providing financial support for this effort, please get in touch.
We have a lot of work left to do before we can start providing Let’s Encrypt to web site operators: We have to complete the software that will power the CA, the certificate management software for use by web sites, and the open, secure protocol that they’ll use to speak to each other. Today, we’ve posted a draft protocol specification and prototype implementations, which are available on Github. If you’d like to help by contributing to development and security review, please take a look at the code.
For server operators, watch this space. Let’s Encrypt will be available starting in Summer 2015, making free, automatic, browser-trusted HTTPS certificates available to everyone.
More links:
- Let’s Encrypt web site
- EFF blog post
- EFF press release
- Andreas Gal’s blog post
- Demo video by James Kasten
J. Alex Halderman is a computer science professor at the University of Michigan and director of Michigan’s Center for Computer Security and Society.
Most protein shakes are loaded with sugar, fat, and other ingredients that aren’t even necessary for the body.
If you want to build a considerable business, you’ll have to be able to come
up with constant leads. You must know what to choose in obtaining your goals.
I am very, very happy to hear this news I first saw posted by the Electronic Frontier Foundation. As a long time application developer I have always considered dealing with Certificate Authorities a great headache – so much so I put off supporting servers and their potential applications for my personal domains. Between the continuous annual costs and third party administrative processes unique to each enterprise Java application server it was a prohibitive problem. If ACME is done right this should accelerate adoption of open source applications benefiting all. Removing more corporate barriers between legitimate application developers and end users is seen as clear progress in my eyes. Thank you to all involved in this project.
as an everyday user, who’s not so techie, can anyone point me to a simpler clarification as to how this will affect my everyday usage
What about websites on shared hosting? Will there be a way that providers of shared hosting can make this available to the customers. I’d like to see an option in cPanel to enable it.
I applaud this effort! It is a major undertaking and we will all benefit! But it is only one step in the direction of securing the Web. But if you really want to fix SSL and prevent man in the middle attacks, take a look at Greg Slepak’s DNSChains and okTurtle browser extension.
So what becomes of CACert.org?
Next step: get sites which already have HTTPS to use it by default on non-login/non-payment pages. And *not* redirect HTTPS requests back to plain HTTP (I’m looking at you, Amazon!)
Michael Martinez: “The single biggest problem with HTTPS is that it won’t protect anything. Your bank account details can still be stolen from any database that is hacked into.”
Exactly, which is why I don’t lock my car or my apartment, because someone can just smash the window.
The single biggest problem with HTTPS is that it won’t protect anything. Your bank account details can still be stolen from any database that is hacked into.
And if you think using HTTPS in your local coffee shop will protect your privacy from sniffers and hackers, the details for how to turn any smart phone into a Wifi hot spot (complete with names that look like legitimate coffee shop networks) have already been distributed on the Internet free of charge.
And if you think using HTTPS anywhere will prevent Man-in-the-Middle attacks where bad Websites pretend to be good Websites, that lie has been laid bare many times this year, including a major MitM attack against Google itself (one of the champions of HTTPS conversion) in August.
And what will make Let’s Encrypt any more secure from hacking or, worse, DDOS attacks, than the other certificate providers that were hacked and/or taken offline?
Getting everyone to switch over to HTTPS is not only a bad idea, it’s just stirring up false hopes about security and privacy.
Will you join me in acknowledging and addressing the flaws in the system or will you just bury these issues under a layer of misplaced hopefulness?
Michael Martinez: “blah blah blah, a bunch of dumb shit.”
You sir.. Are an idiot. Do you even understand how SSL works? Turning a phone into a hotspot doesn’t instantaneously break an encrypted connection a browser has with a server. The handshake and key exchange is between the browser and the server, not the browser and the access point.
There’s plenty more wrong with the things you’ve said, but it’s not worth the time to get into it all. Go back to SEO and middle earth.
SSL proxying is a thing. See the following link for details:
http://www.charlesproxy.com/documentation/proxying/ssl-proxying/
There are attempts in IETF to standardize proxying in order to allow, for example, corporation firewall/IPS to inspect SSL traffic for malware, or enable DLP appliances to stop exfiltration of sensitive data via HTTPS or FTPS. The browser would be presented with the proxy certificate signed by the CA of the proxy server, which the browser would trust as authentic if the proxy’s intermediate CA cert was signed by a root trusted by the browser (FYI, the browser would use the same compromised network connection to check any CRL’s). A proxy can be deployed on any device which functions as a router, which includes phone hotspots, although it would require a jailbroken phone to accomplish in order to load necessary kernel drivers.
It would be nice if we knew where the authorities servers will be hosted. That will give us a clue of what might happen if a FISC order arrives at the authority’s offices
It needs to be optional. There are still embedded systems or other things which don’t need, nor can support such encryption.
Unless you are willing to say “So sorry, we’re making your device DOA”.
This is great, just trying to understand- what’s going to take them 6 months?
While I understand the goal of expiry and renewal (limiting the duration of possible damage if a key gets compromised), have you considered issuing certificates with validity that matches the corresponding domain name duration, and then making sure people have the means to revoke?
Can’t decide whether copy paste support for Microsoft Console or this is better.
Joke aside, how have we been missing on this for so long? Thank you guys for liberating the web from a paywall which probably filled only the pockets of a few already rich organizations.