How SSL certificates are leaking sensitive information

SSL certificates mark the first step in a commitment to user safety and security and HTTPS, SMTPS, IMAPS, POP3S have become the standard protocol for web traffic. Given that these certificates carry an ocean of internal information, they might be leaking the sensitive data to potential threat actors, according to new research from Detectify Labs that analysed over 900 million public SSL/TLS certificates. 

Securing your website with an SSL/TLS certificate is no longer optional, even for businesses that don’t have sensitive customer information on the web. While Secure Sockets Layer (SSL) or Transport Layer Security (TLS) certificates are a subset of encrypted communication, they are a key component in terms of user safety and security. Providers like Let’s Encrypt have improved internet security through automated ways to set up HTTPS easily and for free, making encryption easily accessible to smaller scale companies. 

While the information is encrypted when using SSL certificates, the risk of it being exposed continues to be there as companies use descriptive domain names. New research from Detectify Labs investigated over 900 million public SSL/TLS certificates and uncovered the pitfalls that can lead to company data being exposed or compromised by malicious actors. 

SSL certs – the Achilles heel of a company

Certificate log data can reveal the digital infrastructure, software and products used by organizations internally and externally – information that a malicious actor could leverage. Researchers at Detectify analysed patterns around SSL security and saw what could be revealed from collecting and wrangling these publicly available data points. 

Detectify collected close to 10 million certificate logs on a daily basis since July 2021 generated from issuing organisations including Let’s Encrypt, Digicert, Amazon and Google. The research showed that a majority of newly certified domains had descriptive names posing a potential data leak risk. The security risk gets escalated when domains get certified in the staging phase of the development cycle, before they are publicly launched. As Detectify co-founder and senior security researcher Fredrik Nordberg Almroth said, “That gives competitors (enough time) to do marketing or other efforts that could drive traffic away from the future announcement.” For instance, if company X is working on product Y and deploys its domain to staging using next-generation-of-product-Y.staging.companyX.com, 6 months before its public release, it’s competitors can potentially misuse that information. 

Almroth advised that companies must make sure to always choose code names or random strings over descriptive product names when deploying new domain names. “Whether SSL data is a risk or not, it’s something you should be aware of. Domain names will inevitably be indexed and they will be out on the internet, even if it’s for something internal. All you can do is to ensure you’re not divulging important information.” Furthermore, you could know if someone issued a certificate using GoDaddy, but on the other hand, an evil attacker could see all your domains that have a certificate to them. 

Don’t trust that padlock on the URL blindly; verify 

SSL vulnerabilities include weak hashing algorithms, expired or wildcard SSL certificates and weak RSA keys, among others. Using these methods, malicious hackers are constantly adjusting their obfuscation techniques to exploit user reliance on HTTPS as a trusted checkmark of a secure site by adopting this standard for malicious sites. In fact, 83% of phishing sites had SSL encryption enabled, as observed in the first quarter of 2021, according to a report by the Anti-Phishing Working Group. However, organisations can’t use this as a reason to let their guard down against SSL attacks. 

In another instance, the acme.sh script is easily accessible as it is written in Shell and supports more DNS providers than other similar clients. Security advisor Frans Rosen managed to issue SSL certificates signed by Let’s Encrypt for every domain hosted by providers such as AWS CloudFront and Heroku. 

Despite rigorous processes vetting certificate issuance, issuance of rogue certificates does happen. To monitor fraudulent certificates, a new protocol dubbed Certificate Transparency (CT) was established which includes publicly accessible logs publishing all certificates at the time when they are issued making any certificate belonging to any domain easy to search. 

Certificate Authorities (CAs) are now forced to submit their certificates to CT logs after Google made it mandatory. It continues to maintain a number of CT logs which are apparently used for monitoring performance and compliance of the logs. Facebook too launched its Certificate Transparency Monitoring tool to support certificate transparency. CT proved to be particularly helpful in discovering erroneous issuance of certificates in the case of Symantec issuing a rogue certificate for google.com. 

In a similar vein, Microsoft announced its latest Patch Tuesday advisory which included SSL encryption mitigations. It extended SSL defaults “to further enhance Internet Explorer’s default defense against clever attackers.” While these new protections do increase security, if SSL attacks target users’ browsers, SSL protections will be of limited effectiveness against an attacker who has already hacked into your systems. 

SSL data can be more than a harmless data point

Apart from descriptive domain names, there are a slew of ways an SSL can be compromised that might result in your company being eliminated. For instance, attackers can reuse certificates with a weak RSA key for multiple domains. In 2015, v3 of the SSL protocol was deprecated due to being vulnerable to POODLE attacks and the discovery of a critical flaw which allowed malicious attackers to extract secret information from encrypted communications. 

An example of useful information that can be extracted from the certificates are Subject Alternative Names (SANs). This field lists all domains where the certificate is valid. In this way, it can be possible to link numerous malicious domains that share a certificate together. 

Another red light is improperly signed X.509 certificates that contain one or more violations of the restrictions imposed on it by RFC 5280. This means that either a root or intermediate CA signed a certificate incorrectly. Certificates that fail to adhere to the restrictions in their extensions may be rejected by certain software. The existence of such certificates indicates either an oversight in the signing process or malicious intent.

Expired certificates 

Once SSL certificates expire, it can’t guarantee confidentiality of its users’ data leading to the increased likelihood of successful DNS spoofing or Man-in-the-middle attacks against affected services. While SSL revocation is possible for domain names that have been compromised during cyberattacks or mis-issued by CAs, another more insidious form of SSL vulnerabilities is where CAs themselves are at risk of SSL attacks. 

If an attacker sees a weak signature algorithm or an expired certificate, it can be exploited to listen in on website traffic or create another certificate with the same signature – allowing an attacker to pose as the affected service. Domain owners should pay extra attention if they notice new certificates being issued by unknown CAs – that could indicate that an attack is taking place or that a forgotten subdomain has been taken over.

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. Hashing algorithms come in various types, some of which have been cryptographically broken and are subject to hash collisions; an attack which would facilitate the generation of fraudulent certificates. If such attacks succeed, a malicious attacker could masquerade as a trusted service and be privy to all the data passed between a user and that service.

All certificates signed using weak hashing algorithms such as SHA-1 and MD5 are reissued and mandated to use the SHA-2 hashing algorithms. The point is you shouldn’t be able to crack the crypto. So if you can get through this type of attack down there, you know that you have failed.

SHA-1 was the primary algorithm from 2011 to 2015. However, SHA-1 witnessed multiple collision attacks, making SHA-2 the new standard. If you are receiving an SSL/TLS certificate today it must be using that signature at a minimum. 

Occasionally one will see certificates using SHA-2 384-bit. The 224-bit variety is not approved for use with publicly trusted certificates, and the 512-bit variety is less widely supported by software. SHA-2 will likely remain in use for now. However, some unexpected attack against the algorithm could be discovered which would prompt an earlier transition.

Weak RSA key lengths

SSL keys can currently be compromised without the knowledge of SSL certificate owners because most SSL certs aren’t revoked until after they’ve expired which means information encrypted by these certificates could remain private even if the SSL keys are stolen. 

There are three basic ways SSL keys can become compromised : 

1. Where attackers hack into the systems used by CAs to issue SSL certificates 
2. SSL key theft where authorized users of SSL certificates including websites and company IT staff with authorized access could have their passwords or private keys stolen
3. When an attacker issues a fake SSL cert for a domain name belonging to another organization without its owner’s knowledge.

Furthermore, SSL certificates signed using RSA keys less than 2048 bits are considered weak, as given advances in computing power they are increasingly vulnerable to being broken in a reasonable time-frame. A successful attack of this nature would provide an attacker with clear text access to encrypted data as it’s in transit between client and server. In fact, 2048-bit keys might not cut it in five to ten years from now. The National Institute of Standards and Technology (NIST) issued NIST SP 800-57 in May of 2020, with the main takeaway being that 2048-bit RSA keys are not recommended for use past the year 2030. 

To ensure better security in terms of private keys, Almroth suggests that companies must generate their own private keys on a secure and trusted environment – preferably on the server where they will be deployed or a FIPS or Common Criteria compliant device. 

It’s important to keep a track of who has been given access to private keys. If a private key has been compromised, revoke all certificates for this key, generate a new key pair, and issue a new certificate for the new key pair. In addition, renew certificates as often as practically possible, using a freshly-generated private key each time. 

Wildcard certificates 

Wildcard certificates automatically vouch for any and all host names within their domain.  Server administrators frequently create self-signed “wildcard” certificates on-demand using free, OpenSSL. This can be convenient for administrators but also poses the risk of vouching for rogue hosts. In fact, the US National Security Agency (NSA) has warned of the dangers stemming from the use of broadly-scoped certificates to authenticate multiple servers in an organization because they open the door to ALPACA (Application Layer Protocols Allowing Cross-Protocol Attack) hacks wherein attackers could potentially steal cookies, private user data, or perform cross-site scripting attacks. Despite proven vulnerabilities, aforementioned Detectify Labs’ research found that around 13% of the domains collected use so-called wildcard certificates. 

Say for instance, a certificate for *.google.com, and it would be valid on https://YY.google.com/ and https://XX.google.com/ – but maybe not on https://google.com/ or https://my.mail.google.com/. The asterisk can match any one single segment of a hostname, but nothing with a full stop in it. As a result, the XX.google.com server got hacked, and YY.google.com would also be affected as the certificate on XX.google.com was a wildcard certificate for *.google.com. A potential thief can use it to impersonate the mail.google.com server and intercept people’s email traffic, even though the mail.google.com server was never hacked. 

Using a wildcard certificate on a publically facing web server increases the risk that cybercriminals will use the server to host malicious websites in phishing campaigns. To eliminate this problem, organizations should avoid using wildcard certificates on production systems, especially public-facing ones. Instead, Almroth says it’s better to use subdomain-specific certificates that are rotated often. For more on wildcards, stay tuned. 

The keys to mitigating SSL leaks 

To protect against advanced persistent malware, organizations need to identify all systems using SSL/TLS, install new keys and certificates on servers, revoke vulnerable certificates, and validate new keys and certificates are installed and working

Moreover, it’s key to ensure that the certificate authority you choose offers services such as Extended Validation (EV) certificates, bulk/automated certificate issuance via an intuitive API or the ACME protocol, easy certificate life-cycle management and monitoring services, and support for integration with an extensive list of third party solutions.

We’ve already talked about subdomain takeovers and how it creates an attack scenario by increasing a company’s attack surface. If you are a cloud provider, we recommend not  allowing trailing dot domains at all, or that your conflict check properly handles this case. In addition, continuously monitoring one’s certificates should be part of every organisation’s efforts to protect their external attack surface. 

Lastly, although an SSL is nearly impossible to hack, it’s essential to take the necessary steps to ensure yours won’t be compromised as it is yet another data point that you can tap into. And remember — never depend on an SSL to take care of any web security needs beyond creating encrypted connections.

Detectify users are covered to monitor these risks and keep a track of their attack surface

Curious to see what the Detectify’s web app scanner can find in your web apps? Start a free trial today.