Web browsers may have gotten the security message wrong when they opted to tell users when a website is secure, rather than when it isn’t. In 2018, that lock has started to flip: A large percentage of sites worldwide now feed traffic out over HTTPS. For Firefox browsers, the percentage of web pages using the secure protocol has steadily risen from about 30 percent in late 2013 to 75 percent in mid-2018. The nonprofit project Let’s Encrypt has played a big part in that shift.
The group made its public debut in beta in 2015. It came on the heels of revelations from former NSA contractor Edward Snowden and others detailing the extent to which the U.S., UK, and other governments routinely tapped into unencrypted traffic at data centers and internet service providers’ networking nexuses. During this period, research and reporting revealed unnerving information about how ISPs, mobile carriers, and advertising networks increasingly collected and collated data to track and market to people without their full knowledge or willing consent. Privacy advocates raised frequent and loud alarms. Let’s Encrypt stepped into the fray, making site encryption more widely available.
Encrypting websites isn’t a cure-all for these problems, but it does fortify sites against both casual and focused attempts to intercept, spy on, sift through, and extract data. Let’s Encrypt offers free, automatically renewable certificates, diminishing many of the traditional barriers to encryption, including cost and complexity. Its efforts, supported by a number of major internet companies, privacy groups, and foundations, have been wildly successful, though not without their share of controversy. While it’s now the largest issuer of HTTPS certificates, and it currently covers 130 million fully qualified domain names, the company has opted to only offer Domain Validated (DV) certificates; tension persists around the ramifications the prevalence of such “lower-level” certificates might have for casual users.
The certificates Let’s Encrypt offers don’t meet every need: An e-commerce company that retains private customer information, for instance, likely needs to make more of an effort to prove that they are who their site says they are in order to meet regulatory or industry requirements. But Let’s Encrypt’s free certificates work for the vast majority of websites, which mostly feed out static pages. Much of the publicly accessible web consists of text and images on sites that capture little or no information about you—except that you leave behind a trail of what you’ve seen and where you’ve been. HTTPS largely suppresses that data.
A secure web connection has at its core a digital certificate that enables a strongly encrypted connection between a browser and a server. For most of the two decades since Netscape introduced the first iteration of secure HTTP via Secure Sockets Layer (SSL)—which has since been replaced by Transport Layer Security (TLS)—obtaining a certificate for all but the largest businesses was a manual and relatively expensive process.
Often, the main reason a website lacked a certificate had to do with complexity, rather than cost. Installing the cert into a web server could be baffling, even if you knew the server software well, and head-bangingly frustrating for email and other software. (I write from experience, having configured Apache, sendmail, and other server software since the mid-1990s.)
The digital certificate infrastructure solves the problem of how two parties that don’t know each other can exchange a strong encryption key to manage a session of swapping data with some assurance that no one will be able to intercept or misdirect it. Public-key cryptography provides the elements needed to handle this exchange.
A certificate’s identity ties it to a fully qualified domain name (FQDN). That’s typically a host portion (like www) plus the domain name to form something like www.example.com, although it can also be the domain name by itself, like example.com. But domain name spoofing and network poisoning techniques abound, which can fool an operating system and browser into visiting the wrong site. How can a browser be sure that the certificate it receives when attempting to visit a website with a given FQDN is from the legitimate owner of that domain and server?
There are two parts to solving that validation problem. First, there are certificate authorities (CAs), of which Let’s Encrypt is one. Hundreds exist worldwide, and their function is to take a request from a website operator and cryptographically sign an identity certificate that the operator then installs. Second, modern operating systems and some browsers have root certificate stores that contain the public keys of CAs that meet their certification standards. The set varies slightly among Apple, Google, Mozilla (the makers of Firefox), and others, but as of this year, it includes Let’s Encrypt.
When a browser (or other client software) attempts a secure connection to a server, the server transmits its digital certificate. The browser checks the validity of the CA signature against its local preinstalled and updated cache, and confirms directly with the CA that the certificate hasn’t been revoked. Since certificates are just static documents, revocation checks are important, as certificates can be issued in error or even fraudulently. Sometimes entire CAs get kicked out of operating systems and browsers for violating rules.
Wrapping encryption around web connections doesn’t prevent an outside party insinuated at the right vantage point from knowing that you visit a given site, how many pages you request, or how often you return. But encryption does obscure most metadata, such as searches, referring URLs, pages requested, and activities on a particular site.
Historically, obtaining a certificate as an individual or business generally required working with a commercial CA that charged a fee of about $20 to $100 for a standard DV certificate—a certificate that’s validated by domain name ownership alone. It was possible to get free certificates, typically just for personal, noncommercial, or nonprofit use, only after jumping through verification and technical hoops. Some web hosts also offered free DV certificates as part of a paid hosting package.
But the costs could add up, especially for those running low-revenue or free sites and using many domains, even as domain registration fees plummeted. Some organizations, for instance, have unique domains for every distinct purpose; it could cost $100 a year to renew 10 domains, but another $200 to $1,000 annually to add HTTPS. Especially for sites that didn’t collect personally identifiable information, require logins, or believe that what they offered was sensitive, the need for an additional layer of security wasn’t always clear, and the cost could be prohibitive, especially compared to free or extremely low-cost hosting.
It could also require technical expertise just to get a certificate issued—let alone to properly install it on a web server—that was in excess of what many people operating websites possessed.
It could also require technical expertise, including command line invocations, just to get a certificate issued—let alone to properly install it on a web server—that was in excess of what many people operating websites possessed. To push through that, free certificates also had to be easy to install and renew. It wouldn’t feel “free” if it took dozens of emails and hours of configuration, or broke someone’s website.
Let’s Encrypt developed a protocol called ACME (Automated Certificate Management Environment) to make installation and renewal straightforward and automated on its part, as well as automatable by site operators without a lot of training—a single crontab entry might suffice. (ACME is in a draft stage at the Internet Engineering Task Force, or IETF, and can be used by free and for-fee CAs alike. It’s not yet a released standard.)
In addition to reducing the installation burden, the group opted to just issue baseline DV certificates, which only require sufficient proof of ownership of a domain, and for which ACME automates that proof. Higher-tier certificates that purport real identity verification require real-world evidence, like a copy of a business license, a scan of a company owner’s passport, or even a letter from a bank manager verifying that a company has a legitimate checking account.
All of Let’s Encrypt’s certificates are free, which aligns with the group’s founding mission and that of its corporate and institutional sponsors. “A lot of people think we’re here to help the entities we give the certificates to,” said Josh Aas, executive director of the Internet Security Research Group (ISRG), which operates Let’s Encrypt as its primary project. “But we’re here to protect the people who visit your website, not you.”
Offering free, simplified access to HTTPS certificates also serves to mitigate resistance due to a very specific obstacle noted earlier, namely that the cost and complexity of securing a website may not appear to be worth it if there’s no obvious benefit—especially if a site generates little or no revenue. Without a reward, or inarguable simplicity, why bother?
If you aren’t incentivized to protect your customers’ browsing patterns, search requests, and data entry on your site, or you aren’t convinced that encryption is really so easy to obtain, Google has provided a new reason to encrypt. Over the last few years, Google’s Chrome browser has shifted aggressively from highlighting secured sites to calling out insecure ones. Back in 2015, Google Search began to favor HTTPS-enabled sites. And in July 2018, Chrome began marking sites without HTTPS as “Not Secure” in the location bar. Other major browsers have followed a similar course, but more slowly and with fewer exclamation points and warnings in the address bar.
Encrypting the whole internet is no small feat, and with the increasingly prominent need for HTTPS, Let’s Encrypt’s popularity has skyrocketed.
Encrypting the whole internet is no small feat, and with the increasingly prominent need for HTTPS, Let’s Encrypt’s popularity has skyrocketed. The group now fields nearly 130 million FQDNs and two billion certificate validity requests a day; you’d think ISRG would be facing substantial scaling issues. In mid-2017, the group issued about 400,000 new and renewed certificates each day; on a recent day in late 2018, over one million certificates were issued, and the daily average runs to several hundreds of thousands. These certificates are requested by individuals (like the author of this article), large organizations, and site hosts. DreamHost, for instance, has a streamlined method for requesting certificates that requires just a few clicks.
But Let’s Encrypt’s overhead remains relatively fixed because of the organization’s focus on automation, documentation, and favoring higher capital costs over continuing operational ones. ISRG has a $3 million budget, which covers 12 full-time staff, some part-time and contract workers, and its particular hardware and data center requirements as a CA. The budget comes largely from corporate and foundation sponsors that include Mozilla, Google (from its Chrome division), Akamai, Cisco, the Ford Foundation, and dozens of others. Individuals and small companies donate, too.
ISRG has a distinct advantage over many software projects in that it has a discrete set of certificate-related standards to support which change slowly, often involving years of discussion and multiyear phase-ins. As a result, Let’s Encrypt doesn’t push out many new features—maybe a couple a year, Aas said.
Despite the sheer volume of security documents Let’s Encrypt issues, its hardware needs are relatively modest, but constrained. As a CA, it must follow specialized requirements to conform to the rules set by OS and browser makers, like very expensive tamper-resistant hardware modules that sign all of the private certificates. They’re so secure that no one—not even Let’s Encrypt—knows or can extract the signing keys inside them. Aas said the group has to own its hardware and have triple redundancy in place, and tends to spend more up front on hardware if it reduces operational burdens that require more staff time.
Let’s Encrypt faced criticism from the commercial CA world before and after its launch for a variety of reasons. Some of this may have stemmed from a concern about competition. Let’s Encrypt allows anyone to get a DV certificate, which potentially includes millions issued to low-hanging fruit for existing CAs: website owners who have decided to secure their sites and are already paying to do so.
While that criticism has largely died down, especially with so many major firms across the internet and networking ecosystem supporting and sponsoring ISRG, another issue still surfaces from time to time: Because Let’s Encrypt issues certificates automatically and only offers domain validation, phishers can easily take advantage of the service to secure their fake sites. One critic at a certificate reseller noted that Let’s Encrypt issued credentials to over 15,000 domains that contained some variation of “paypal.”
Technology writer Brian Krebs, who has broken news on data breaches and other security issues for decades, thinks that criticism is ultimately misguided. “SSL in general has taken on a much bigger role than it was ever intended to play,” he said. “It has always been conflated with identity, and it has absolutely nothing to do with that.”
He noted that phishing sites will naturally migrate to HTTPS because Google Chrome increasingly punishes insecure sites. He also pointed out that phishing domains look benign at the time they are registered and have a short lifespan while actively engaged in cybercrimes. This makes it more or less impossible for CAs to do much about any given fraudulent site in a meaningful time frame. Phishing sites and their domains are typically discovered and shut down by some combination of the hosting company, the network provider, and the domain name registrar.
Krebs also pointed out that treating Let’s Encrypt like a perpetrator of this problem is flawed logic: Other CAs have moved to automate most of the process of issuing DV certificates, whether at no cost or for a fee, which leads to the same issues. (Phishers often have access to stolen credit card numbers, allowing them to “pay” for free, too.)
Aas, for his part, doesn’t believe it should be up to the CA to make a decision about the validity of a domain name. But that doesn’t mean a CA is without responsibility: ISRG responds to court orders and laws, and the service uses Google’s Safe Browsing API to block issuance to known malware and phishing sites.
Aas also echoed Krebs’s point on the conflation of a secure connection and a site that has some kind of seal of integrity. “For all you know, Satan himself is on the other end of that line,” he said. A secure site is not necessarily a well-intended site; the certificate assures you only that the person who controls the domain is the same person running the site.
Getting 100 percent of websites secured isn’t possible, but somewhere in the high 90s is absolutely doable, Aas said. He also noted that he’s analyzed his own browsing habits and found that 99 percent of the pages he loads are secured. He’s tested his friends, and they score about the same.
Aas’s examples are anecdotal, sure, but he argues that for large sections of society, “the web is already almost entirely encrypted today.”
Many companies and nonprofits will need more than Let’s Encrypt can provide, and can pay to have their real-world identities validated through the arguably more thorough Organization Validated (OV) and Extended Validation (EV) certificates. There’s some dispute as to whether that validation has a real benefit, but higher-tier certificates can be required by legal counsel, corporate auditors, or even business customers whom policy dictates cannot connect to sites that haven’t had that extra level of scrutiny applied.
And if you want a phone number to call so you can dial up a CA at 2 a.m. on a Sunday morning? “You’re going to want to call a commercial CA,” Aas said.
Let’s Encrypt addresses a baseline need for security that the internet clearly lacked, and which no commercial organization or existing technical group had stepped in to provide. The rise of secured domains shows that ISRG’s assumption was right: Most of those domains weren’t paying for certificates, and they probably never would have if the obstacles of the past had remained in their way. On the road to securing all communications, the group has made a steep slope seem climbable.