|
Certificates are used to encrypt communications, most notably seen through the widespread use of HTTPS, which forms the backbone of securing a large portion of the world's internet traffic. Let’s Encrypt is an open and automated Certificate Authority (CA) that provides free SSL/TLS certificates to any compatible client. The core of Let’s Encrypt functions off the ACME protocol which enables servers to request, install, and renew certificates automatically. Background / History of CAs The widespread adoption of SSL/TLS in the mid-to-late 1990s created the need for a trusted way to verify that a website is really who it claims to be, to establish trusted, encrypted connections. This led to the emergence of CAs: organisations responsible for cryptographically signing digital certificates that bind public keys to a website’s identity. Web browsers and operating systems soon began to ship with a list of popularly-trusted root CAs which were used as an authoritative base to verify certificates and establish secure connections without the need for end-users to manually vet and select their own CAs. Over time, a small number of commercial CAs with verified security practices and reputable track records came to dominate the trust ecosystem, forming the foundation of today’s Public Key Infrastructure. For much of the internet’s history, public TLS certificates were largely provided by commercial vendors, often at a significant cost and time investment. This created friction in enabling encryption for small to medium-sized organisations, personal projects, and even some large corporations (such as the BBC) which all contributed to significant portions of internet traffic remaining unencrypted. When Let’s Encrypt emerged in 2015, it fundamentally changed this model by introducing a fully automated, free certificate issuing service, removing financial and operational barriers to HTTPS adoption. Let's Encrypt was founded by the Internet Security Research Group, a group founded and sponsored by Mozilla, the Electronic Fronier Foundation (EFF), University of Michigan, Cisco and Akamai. Leveraging their reputation, they are now recognised as a root CA across almost all browsers and operating systems worldwide. Becoming a publicly trusted root CA is a demanding process that involves rigorous security audits, strict operational controls, and final approval from major multi-national technology vendors. Importantly, Let's Encrypt met these same standards, undergoing extensive scrutiny and partnering with well established organisations before its root certificate was accepted into global trust stores in October 2015 through a cross signing agreement with IdenTrust. This ensured that Let’s Encrypt maintained the same technical, reputational, and security assurances as long-established commercial CAs, which enabled it to operate at massive scale throughout the next decade. NZISM Considerations The NZISM offers minimal guidance on the secure use of CAs such as Let's Encrypt. However, it does provide guidance around the cryptographic algorithms that should be utilised for digital certificates and the minimal acceptable key sizes. Firstly the NZISM recommends the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) for all new systems, aligning with the industry’s perspective that elliptic curve algorithms provide greater security with smaller key sizes compared to RSA:
Secondly, the NZISM states that where RSA keys are used for digital certifications, systems operating at all classifications must use a modulus of at least 2048 bits (equivalent to a ~256 bit ECDSA key):
Let’s Encrypt therefore meets the NZISM’s requirements, accepting P-256 or P-384 ECDSA keys and 2048, 3072, and 4096 bit RSA keys. When implementing secure communications further, NZISM controls should be considered outside of just the CA scope. For example the TLS version, secure cipher suites, etc. Extended Validation One argument against Let’s Encrypt has been around how it exclusively issues Domain Validation (DV) certificates, which only verify control of a domain, but do not attempt to validate the legal identity of the person(s) or organisation behind it. In contrast, Organisation Validation (OV) and Extended Validation (EV) certificates involve more stringent identity checks, with EV historically being marketed as providing the highest level of trust due to in-depth entity verification. This was previously indicated to end-users through visually prominent browser elements. While EV was originally intended to provide stronger assurance, this model relied heavily on users noticing and correctly interpreting these indicators. In reality, industry experience and academic research have shown that these visual indicators did not meaningfully improve the average user’s security outcomes as the EV-indicators rarely caused users to change their behavior. Troy Hunt has noted “The effectiveness of EV has been called into question numerous times over the last few years, there are serious doubts whether users notice the absence of positive security indicators and proof of concepts have been pitting EV against domains for phishing.” As a result, modern browsers such as Chrome, Firefox, and Safari have removed EV-indicating UI elements from the address bar. Given this, DV certificates which provide the same strong encryption and protection against passive interception attacks as EV certificates, essentially provide all of the practical security benefits that users and organisations require. This makes Let’s Encrypt a pragmatic and effective choice for most services, delivering on modern security expectations with lower cost and overhead traditionally associated with commercial offerings. Summary Let’s Encrypt provides the same key security features as other CAs with the certificates it issues with the exception of EV, which has been shown to offer little to no benefit. Based on this, Let’s Encrypt certificates can be an appropriate mechanism to use within any organisation, if your risk profile allows for it. The move to short lived, regularly renewed certificates should be celebrated and moved to, independent of which CA is leveraged. References
Authors: Julius Staufenberg, Aum Patel, David Watson, Quinn Simmons Comments are closed.
|