The 1st of September 2020 marked a new era for the TLS certificates ecosystem: all publicly trusted TLS certificates will have a lifespan of 398 days or less. This is roughly half of the previous certificate lifespan. This latest change is an indication that machine identity lifetimes will continue to shrink.
Many security professionals discussed the managerial implications of shrinking the lifetime of TLS certificates. On the other hand, this industry move indicates the importance of placing trust in the fabric of billions of transactions and communications every day.
Digital keys and certificates act as machine identities that authenticate connections and communications. In other words, these machine identities control the flow of sensitive data to trusted machines in a wide range of security and operational systems. Enterprises rely on machine identities to connect and encrypt over 330 million internet domains, over 1.8 billion websites and countless applications.
However, reducing the life span and effectively managing these identities is not enough. When produced, the TLS certificates need to be free of vulnerabilities and weaknesses that are then inherited by millions of organizations relying on them. Let’s discuss which are the most common vulnerabilities and what we can do about them.
A certificate is untrusted if it has not been signed by a trusted Certificate Authority (CA). For a browser to accept a certificate, it must be able to link it to a trusted root certificate. Trusted root certificates are embedded into popular browsers and they are used as trust 'anchors' to verify the legitimacy of all website certificates that the browser encounters. If a browser encounters a certificate that is not signed by one of these roots, then it will state it is untrusted and visitors will see an error message.
'Untrusted' errors are usually caused by one of two reasons:
- Self-signed certificates
- Intermediate certificates are not installed
Untrusted certificates can be leveraged by cyber criminals to conduct man-in-the-middle (MitM) attacks to impersonate banking, e-commerce, and social media websites.
Weak hashing algorithms
A hashing algorithm is used to provide a certificate with a digital signature to ensure that its contents have not been altered. Algorithms once thought of as secure and unbreakable have become either weak or breakable. The MD5 algorithm went from being a strong hashing algorithm to a weak hashing algorithm to a broken hashing algorithm. The SHA-1 is “fully and practically broken” and is subject to hash collisions which would facilitate the generation of fraudulent certificates.
Despite SHA-1 being deprecated since 2011, it is still being used widely. While published findings don't appear to present an immediate danger, the risks associated with the SHA-1 hashing algorithm are greater than expected. If a collision attack succeeds, a malicious group or individual could masquerade as a trusted service and be privy to all the data passed between a user and that service.
Weak cryptographic keys
TLS certificates are signed using keys. NIST defines a cryptographic key as “A parameter used in conjunction with a cryptographic algorithm that determines its operation in such a way that an entity with knowledge of the key can reproduce, reverse or verify the operation, while an entity without knowledge of the key cannot.” Key length defines an algorithm's security, since it is “associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system.”
Continued use of weak keys in certificates puts your clients' sensitive data at risk. Exhaustive key searches/brute force attacks against certificates with weak keys are a danger to network security.
As computational power increases so does the need for stronger keys. The current minimum acceptable key length for an RSA key is 2048 bits, while the minimum acceptable key length for an ECC (Elliptical Curve Cryptology) key is 233 bits.
Improperly signed certificates
Improperly signed X.509 certificates contain one or more violations of the restrictions imposed on it by RFC 5280. The existence of such certificates indicates either an oversight in the signing process or malicious intent. The reasons for improperly signed certificates might be the following:
Certificate name mismatch
If the domain name (FQDN) in the TLS/SSL certificate does not match exactly the domain name displayed in the address bar of the browser, the browser stops the connection to the website and displays a name mismatch error. Errors create mistrust when connecting to a site and can cause clients to avoid your site. Possible reasons for receiving the mismatch error are the use of self-signed certificates, misspelled domain name and the wrong type of TLS certificate.
Industry standards prohibit Certificate Authorities (CAs) from issuing certificates to internal names. An internal name is an IP address or domain that is part of a private network (see RFC 2606). Validation cannot be completed for internal names because they can't be externally verified. Examples of internal names are:
- Server names with non-public domain suffixes, such as .test, .example, .localhost
- Anything without a public domain such as NetBIOS names or short hostnames
- Any IPv4 address in the RFC 1918 range
- Any IPv6 address in the RFC 4193 range
Additionally, non-unique internal names carry too much potential for malicious misuse. For example, a CA can issue a publicly trusted certificate to a company for https://mail/. Because this name is not a unique name, anyone else could get a certificate for https://mail/.
Missing or misconfigured fields and values
Industry standards define the fields and values that Certificate Authorities (CAs) must include in publicly trusted TLS certificates for these certificates to be secure. These fields and values help CAs tackle existing and future threats to online security. Self-signed certificates and certificates not signed by a CA may not contain all the required information. In addition, the cryptology may not be adequate.
Continued use of certificates with missing values may put your clients' sensitive data at risk. Certificates without the necessary fields and values may cause browsers to display warnings. Warnings create mistrust when connecting to a site and can cause clients to avoid your site. Missing fields and values in certificates may also obstruct applications programmed to look for these fields from operating properly.
How Venafi helps minimize the impact of certificate vulnerabilities
“Business digital transformation today relies more and more on certificates to secure online transactions,” says Dimitris Tsambiras, PKI & Authentication Specialist at ADACOM. “Increase of certificate vulnerabilities becomes a risk factor that businesses should take seriously in order to secure transactions, data and of course company reputation. Lately, we’ve seen a rise in MitM attacks targeting big corporations and governments. But the longest battle we must fight in the cybersecurity space, is for faster adaption of stronger keys, ciphers and algorithms. Even though more than half of the internet sites have enabled HTTPS, it’s estimated that over 800.000 sites still use a weak TLS implementation to date,” adds Tsambiras.
Whether it is inadequate internal controls, human error or technology malfunction, a certificate vulnerability can allow attackers to perform man-in-the-middle attacks to impersonate legitimate properties or can allow attackers to issue fraudulent certificates for virtually any site. Organizations can simplify the management of certificates and prevent business interruptions by using an automated solution for machine identity protection such as the Venafi Trust Protection Platform.
The platform validates that the certificate and chain on every server is correctly installed on a nightly basis. It also supports the automated installation of CA certificate chains with certificates along with the ability to provision and manage such chains. The Venafi Platform enforces trust stores across all systems.
- If Your Keys Are Too Short, Does that Leave You Vulnerable?
- What Is the Hashing Function and Can It Become Vulnerable?
- Where Is a TLS/SSL Handshake Most Vulnerable?