In a certificate-based authentication, a user or machine proves their identity to the servers and networks with a certificate that is digitally signed by a certificate authority, a trusted centralized entity responsible for issuing and managing certificates. Many popular servers support certificate-based authentication, but people often opt in for a password or key-based authentication to avoid certificate management overhead. But it is increasingly becoming effortless to implement certificate-based authentication. More so with tools like Remoteler, which automates CA and certificate management solving the boring and tricky part of certificate-based authentication.
Although certificate-based authentication is a better and more secure form of authentication when compared to passwords or static key-based authentication, it has its fair share of security risks. The major risks associated with certificate-based authentication include:
In this blog post, we will explain a few security best practices applicable to both the developers and administrators of certificate-based authentication, focusing on infrastructure access.
“Do not self-implement cryptographic algorithms and libraries!” This is probably the de facto suggestion to any cryptography-related best practices, and you probably have heard of it many times. But still, it’s worth mentioning every time. Cryptography engineering is a complex domain and depends upon lower-level bit calculation. It is super easy to misimplement it. The safe way to avoid the risks is to use algorithms that are vetted by the government bodies (they will likely have the most requirement for secrecy), such as NSA’s Commercial National Security Algorithm (CNSA) suite and FIPS modules and libraries maintained by popular cryptography community such as OpenSSL, BouncyCastle, crypto++ or tech industry giants such as Google’s BoringSSL, tink.
For certificate-based authentication, one of the most concerning security risks is avoiding collision attacks. Collision attacks occur when two different sets of input values output an identical hash value. Researchers have provided a proof of concept showing how weakness in MD5 hash functions can be exploited to create a rogue Certificate Authority with a valid signature trusted by the majority of web browsers. MD5 has long been considered insecure for security purposes and is usually not included in safe cryptographic operations. Even SHA-1 is advised to be avoided for certificate signing operations.
There’s also this security incident by Flame malware which exploited the MD5 hash collision vulnerability in Windows OS (Vista and above) to generate rogue digital certificates derived from trusted the Microsoft CA.
Unlike passwords or static keys, certificates are dynamic and, at a minimum, have a user identity and expiration time attached to them. Certificates can have many additional attribute values that can be added to subject fields or, via certificate extensions, to build a dynamic authentication model where many variables can be computed in an authentication process. These attributes may include access scopes, network addresses, roles, permissions, etc.
Below is a sample of how a Remoteler-generated certificate adds scopes in the Subject:
$ openssl x509 -in teleadmin-x509.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1e:e2:c6:5d:19:cb:90:55:4c:d2:...
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=example.dev, CN=example.dev/serialNumber=475504…
Validity
Not Before: Apr 29 03:12:11 2022 GMT
Not After : Apr 29 15:13:11 2022 GMT
Subject: L=root, L=ubuntu, L=ec2-user, postalCode={"aws_role_arns":null,"db_names":null,"db_users":null,"kubernetes_groups":null,"kubernetes_users":null,"logins":["root","ubuntu","ec2-user"],"windows_logins":null}, O=access, O=editor, CN=teleadmin/1.3.9999.1.7=example.dev
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b2:c2:2d:c8:d4:7c:b9:e8:aa:3c:0b:96:01:df:Along with additional authentication attributes, developers of certificate-based authentication should implement a full certificate verification process where possible. A weak implementation may only verify valid signatures on the client certificate and call it a day. A good example to follow is how OpenSSH handles certificate-based authentication. Further, both the client and server should verify each other’s certificates as mutual authentication and calculate additional attributes for contextual authentication.
Using vetted cryptography algorithms and libraries is the first step to secure certificate-based authentication, but careful consideration must be taken while implementing the final authentication logic. Take this example of DoveCot’s certificate-based authentication bypass issue. As described in the issue description, Dovecot supports certificate-based authentication where only the username assigned in the x500UniqueIdentifier field would be allowed to log in. But if the x500UniqueIdentifier field was removed entirely, it would completely bypass the authentication model. Under this vulnerable configuration, the user would be able to log in as any user they want to! This is a classic example of a misconfigured verification method. This is why it’s so important to audit the authentication logic once it is implemented.
Certificate authorities are the heart of Public Key Infrastructure (PKI), so the security of your CA is critical. It is easy to generate a CA, and it is common practice to use a self-managed CA inside internal infrastructure. Below is an example of creating a certificate authority, which is as easy as simply using the OpenSSL command:
Given the simplicity and access to the tools to generate and maintain a CA, teams can overlook the security aspects and keep the CA keys unprotected. If CA keys are compromised, it is “game over” for any certificate-based authentication, including the PKI infrastructure. Hardware security modules (HSM) are the recommended place to store and secure CA keys. Ideally, a CA key should never leave the HSM.
In certificate-based authentication, both the user and server certificates will be derived from the CA. For security or periodical maintenance, certificate revocation and CA rotation may be required. If both the user and server certificates are derived from the same CA, it can be challenging to rotate all of them at once. Issuing separate certificates for users, servers and machines will allow applying different sets of security policies independently.
Figure: Gif from https://gfycat.com/devotedportlycero
Whether it’s passwords, keys, or certificates, once stolen, they can wreak havoc. Certificates however have a built-in expiration property which allows the generation of short-lived certificates. This means that these certificates have a short validity period or time-to-live (TTL) value. Given it’s harder to detect stolen credentials and the average time to detect a data breach always remains longer, short-lived certificates greatly reduce the blast radius of a credential leak, as attackers have much less time to use them in an exploit before they expire.
It’s a good practice to periodically rotate your Certificate Authority, invalidating all the pre-distributed certificates. This is a sweeping method where any compromised certificates get automatically invalidated. To avoid downtime, perform phased rotation (separate CA’s for user and server authentication come in handy here) with a grace period so that all users, servers, and machines get time to retrieve their certificates and avoid being locked out from authentication.
At Remoteler, we have implemented a standardized built-in feature to automate CA rotation which goes through five phases:
standby: All operations have been completed or haven’t started yet.init: All components are notified of the rotation. A new certificate authority is issued but not used. It is necessary for remote trusted clusters to fetch the new certificate authority; otherwise, new clients will reject it.update_clients: Internal clients certs are updated and reloaded. Servers will use and respond with old credentials because clients have no idea about new certificates at first.update_servers: Servers reload and start serving TLS and SSH certificates signed by the new certificate authority but will still accept certificates issued by the old certificate authority.rollback: The rotation was aborted and is rolling back to the old certificate authority.Administrators have the option to execute commands to transition between each rotation phase manually or have Remoteler do it all.
In this post, we listed a few best practices for certificate-based authentication relevant both for developers and administrators. In summary, both the implementation of authentication logic and secure management of CA keys are essential for the overall security of certificate-based authentication. All cryptographic operations related to the generation and issuance of certificates should be performed only with vetted cryptography algorithms and libraries.
Remoteler supports certificate-based authentication to all infrastructure access, including SSH, RDP, databases, HTTP and Kubernetes. Remoteler automates the management of CA, which helps implement many of the best practices mentioned in this blog post.