Risks of modern free SSL certificates and stale DNS records
Reading time: 8 minutesSSL certificates have been embraced by a lot of websites in the past, but in the last four years, the SSL adoption has grown tremendously.
One of the major reasons for that giant growth is the fact that Google and other companies like Let’s Encrypt are encouraging users to protect their websites by encrypting the information using an SSL certificate.
Despite being around for over two decades, SSL certificates (HTTPS) started growing in popularity since 2014, and in the year 2018, it is one of the most popular security topics on the Internet.
Everybody wants their SSL certificate, even for a regular website or corporate blog. To be honest, this is a great thing: it’s great for your website security, and for the internet as we are building a secure environment for the public who visits your site too.
That’s why today we will explore the SSL background, the current moment and new risks discovered behind this massive SSL adoption.
Background
In the past years, it wasn’t that important if your site wasn’t using an SSL certificate. Only credit card and sensitive data processing websites were the ones that were bound to use SSL certificates. In fact, you would never earn a PCI valid certification for your online store if you didn’t install an SSL certificate. By that time, free SSL certificates were not an option, and most users had to rely on popular SSL providers like Symantec, Trustwave, or Comodo solutions.
Before 2014, moving your website to HTTPS was pretty tricky, as it would surely include an expensive SSL certificate, as well as extra hosting features for dedicated IPs, or paying for CDN SSL certificates on the edge.
But the problems of moving a website to HTTPS were not noticeable only on the money side. Installing a dedicated IP on your site, waiting for the DNS propagation, so you can start generating the CSR codes to send those to your SSL provider, and once the providers approve the SSL, they would get back to you with a CRT code; the one that you would finally install on your site to have your SSL setup ready.
Nowadays things have changed, free SSL are available for anyone, dedicated IPs are no longer needed, and the installation process can be done within a few clicks by average non-technical people in just a few seconds.
SSL Massive adoption
Since the early 90’s until 2014, the SSL adoption was pretty slow and as we said before, was only used by sites using credit card processing, or online banking, for example.
One of the first companies who started offering free SSL certificates was Cloudflare, who announced their Universal free SSL in 2014.
In March 2016 Google announced their aim for a secure Internet, showing their plans to make the Internet a safer place.
Let’s Encrypt was born later by several companies who founded the Internet Security Research Group (ISRG). This was the first step to make SSL certificates freely available to anyone.
Other companies like Comodo and cPanel joined forces to offer free SSL certificates, making the SSL setup even easier and almost 100% automated.
Now that free SSL certificates are available for anyone, the adoption has become massive for almost all website owners and internet-based services providers. Let’s Encrypt stats show a 70 million active certificates issued for fully qualified domain names since their founding date up until March 2018.
Most big IT companies are almost 100% encrypted as today, offering better security for all their users. One good example of this is how Google started migrating almost all their services and platform (93% at the moment) into SSL encryption:
Apart from offering free SSL certificates, another trick that helped this big SSL adoption was automating domain validations on the SSL installation process. Installing an SSL isn’t difficult at all, but it requires the SSL registrar/provider to ensure you are the owner of the domain before they approve your certificate. The new free SSLs offered by popular companies like Let’s Encrypt or Comodo work in an automated way that avoids the eternal waiting process until the registrar sends you the CRT code so you can install it on your website.
Instead of that, they use automated domain validation processes that speed up the domain ownership a lot. However, recent security investigations discovered new risks of this kind of domain validation when it is specially combined with DNS stale records.
Domain-based SSL validations and Stale DNS records
Security researchers from TU Delft, UT Dallas, and UC Santa Barbara published an interesting paper that shows the risks of using automated SSL trust-based domains to suffer takeover domains attacks by exploiting the IP address re-use on the two largest public Cloud providers in the World (Microsoft Azure and Amazon AWS). Stale DNS records are one of the key points in this investigation as well.
What is a Stale DNS record?
A stale DNS record is just a record you pointed to a specific IP in a past time.
Let’s suppose you purchase a Cloud service for your company online knowledgebase defined at the subdomain: kb.yourcompany.com, and point it out to a predefined IP like 11.22.33.44.
You use this for a couple of months or years, and then you migrate your knowledgebase to yourcompany.com/kb/.
In the end, you terminate the Cloud service you purchased originally. But you don’t delete the DNS record you created for kb.yourcompany.com. That is a stale DNS record, a record that still exists for a discontinued Cloud service.
Attackers can use stale DNS records to generate new attack vectors
By scanning DNS records via DNS history, an attacker could easily notice the stale DNS records present on your domain name. An attacker could then allocate IP addresses to which stale DNS records point to, impersonate the service and then install a valid domain-validated SSL certificate.
Imagine waking up one morning and discovering that your knowledgebase (remember the kb.yourcompany.com example) used by your clients in the past is now online, working with a full HTTPS certificate and probably used for malicious phishing, malware or spamming attacks.
In their tests, security researchers found that these kinds of attacks could easily execute the attack in less than 70 seconds (lower time than most of TTL configuration on DNS records), allowing attackers to even disrupt normal services without stale DNS records during the migration time from one service to another.
Is there any way to mitigate these kinds of attacks?
The best way to prevent this domain validation and DNS stale records based attacks is to introduce a new authentication method in the domain validation process.
Basically, the proposed mitigation includes the new called “Domain Takeover Resistant Identifier Validation Challenge” at the ACME protocol (currently used by Let’s Encrypt to automate SSL certification issuing process), specifically by introducing the new validation phase inside the ACMEv2 RFC.
One good thing about this new mitigation method is to keep the SSL domain-validation process as simple as possible for the end user, who is often non-technical.
In this case, this change is 100% transparent, as there is no additional certificate request needed: the same certificate request will be used in the SSL certificate issuing process.
How does it work?
The new challenge works in five simple steps:
- The client sends a certificate request for the domain name, e.g., “yourcompany.com” to a domain-validating Certification Authority.
- The Certification authority checks if an SSL certificate already exists for the domain or not.
- Certificate Authority issues the new challenge to the client (demanding the user who requests the SSL to place a token that needs to be hosted via HTTPS at a specified path at the domain of the requested certificate), as well as other additional challenges like a DNS-based or whois-based challenge if a prior certificate already exists.
- End user receives the challenge and needs to host the client receives our challenge, she will host the arbitrary number (token) at the URL specified by the challenge.
- Once the URL has been verified, the CA will authorize the SSL certificate to be issued.
The transitioning phase from the current validation model to the new one should not be difficult for current SSL providers, as there are plenty of validations already utilized in the present setups.
Resuming: adding the new layer of authentication and mitigation would not cause any additional issues, instead will help to prevent new security problems.
For full deep analysis of how this technical solution works can be found at the original research, inside the Cloud Strife: Mitigating the Security Risks of Domain-Validated Certificates, at chapter IV. MITIGATION (page. 08).
Apart from this new authentication challenge, authors suggest general security recommendations for domain owners and cloud-based providers to reduce their and their clients’ exposure to DNS staleness issues to avoid domain takeover attacks like rate-limiting IP address allocation and release operations, hardening DNS security, implementing DNSSEC, among others.
Conclusion
As you see, these risks can be reduced by adopting new mitigation technologies by the SSL providers, but also by most Cloud providers who need to follow the best TCP/IP and DNS server practices, as well as changing the IP allocation models.
Are you looking for a way to prevent security attacks in your own company or project? Start using SecurityTrails to analyze your domain names, servers and IP addresses today, and see if you have any DNS stale records inside your active domains so you can prevent the attacks we mentioned here.
If you want to avoid doing manual lookups with our toolkit, grab a free API account and integrate our powerful cybersecurity platform with your own apps too.
