April 11, 2019 By Koen Van Impe 6 min read

More and more, organizations and end users are embracing encryption to protect their data and traffic. By far the most visible part of this adaptation is the use of Hypertext Transfer Protocol Secure (HTTPS) for accessing websites. As opposed to the more basic HTTP, which is the plain text version, HTTPS makes use of Transport Layer Security (TLS) or Secure Sockets Layer (SSL) certificates to encrypt traffic between web servers and clients.

Does this mean that once you’ve implemented TLS/SSL certificates you should no longer worry? Not exactly. There are many cyberthreats that make it necessary to stay vigilant by following a zero trust security model.

Some of the latest threats originate from thriving dark web marketplaces for these certificates, which often come packaged with other cybercrime services. But before we get to that, a little more on HTTPS and TLS/SSL.

A Very Brief Introduction to HTTPS and TLS/SSL

HTTPS is HTTP with an extra layer on top, the TLS/SSL encryption layer. This layer ensures that both the client and the server can continue to speak HTTP with each other, but over a secure connection. Under normal circumstances, this serves three main purposes:

  1. Confidentiality — preventing others from reading your communications.
  2. Integrity — making sure the web content isn’t altered in transit.
  3. Authentication — ensuring that the client (your web browser, for example) connects to the intended web server.

Setting up a security layer on your web infrastructure and adding TLS/SSL certificates to your websites undoubtedly increases security and is in the interest of your customers and users. If there’s one key task you should tackle immediately it’s migrating all your existing HTTP-only sites to HTTPS versions. Although setting up HTTPS has now become a fairly easy process with the help of tutorials such as HTTPS Is Easy! and tooling such as Certbot, there are several key elements that you should be aware of.

When the secure layer is bootstrapped, a handshake happens between the server and the client in which, among other things, the server proves its identity via TLS/SSL certificates. This identity is included as a property of the certificate and describes which domain the certificate belongs to. During this handshake, the client will also check whether it trusts the certificate, or that the certificate is verified and trusted by a certificate authority (CAs) that it also trusts.

Proving Your Ownership of a Domain

To prevent people from acquiring a certificate for domains they do not own, a number of verification steps must be completed. These steps allow you to prove that you’re the rightful domain holder.

Depending on your certificate provider, you will need to prove that you control the DNS settings of the domain (by adding a TXT record, for example), have access to a specific email account belonging to that domain or are able to put up a text file on the public website of the domain.

The next level of identity checks of the domain holder happens with Extended Validation (EV) certificates. Previously, an EV certificate was represented differently in browsers via a green bar, but due to recent browser changes, these visual differences are no longer immediately noticeable for users. As such, because most users will not be able to visually differentiate between EV and non-EV certificates and because they are not necessarily more secure or cryptographically stronger than other certificates, there is really no extra value in spending on EV certificates.

HTTPS Doesn’t Mean Safe

A common misconception is that HTTPS automatically means safe. It doesn’t. It actually stands for secure, meaning that the underlying website that you access via that secure channel can still cause harm to you or your organization. This is very well demonstrated by Netcraft statistics on the number of phishing websites that make use of certificates.

But this isn’t the only threat you should be aware of when it comes to website security.

An Emerging Black Market for TLS/SSL Certificates

Research from Georgia State University and the University of Surrey, sponsored by Venafi, described the appearance of thriving marketplaces for TLS/SSL certificates on the dark web. This type of marketplace might sound strange at first. After all, you can get certificates for free, so why would you want to pay extra for obtaining TLS/SSL certificates, let alone do it on the dark web?

However, if you take a closer look at what exactly is for sale, it becomes clear that these sales do not only include a certificate, but a larger package deal.

According to the researchers, these packages include cybercrime services such as malicious websites and ransomware, but also aged domains, website design services and payment services. Some packages even offer deals that help the buyer set up a company, together with all the necessary company documents and a Data Universal Numbering System (DUNS) number. The deal is then complemented with an EV-SSL certificate from a known certificate vendor.

What Risks Are Associated With This Market?

The threats associated with these dark web offerings are not immediately linked to weaknesses in the certificates themselves, but rather to the services that are provided via the secure website that’s part of the offering.


Phishing websites that resemble legitimate websites remain a threat. But whether a phishing site was acquired via the dark web or not doesn’t immediately increase the threat. Cybercriminals can already register new domains that resemble existing ones and acquire a valid certificate from a legitimate certificate provider outside the black market. The added advantage of these marketplaces, from an attacker’s point of view, is the inclusion of web design services and support.

Financial Loss

Another potential consequence of black market TLS/SSL certificates is financial loss due to fraud. Website visitors who assume they are dealing with a legitimate e-commerce site might be inclined to buy goods and pay for them with their credit card or other payment information.

Illicit websites often present themselves as a real online store that is protected with a proper certificate and accepts money via a trusted payment system. Even trained security professionals sometimes have a hard time differentiating between a legitimate business site and a malicious one.

Credentials Theft

Although we warn our users not to reuse passwords and request they create unique, strong passwords, we know that in practice this is not always the case. This leads us to another risk: users signing up and creating detailed accounts on legitimate-looking business websites. The threat actors behind these fake sites can not only grab any entered passwords, but they also have access to any other personal information included in setting up the profile.

From an attacker’s point of view, this becomes increasingly interesting when a victim signs up with his or her business email account or other credentials used to access corporate networks or resources. This kind of threat is typically deployed on fake online dating or job listing websites.

Man-in-the-Middle Attacks

Another risk that comes to mind with black market TLS/SSL certificates is attackers spying on encrypted traffic or conducting man-in-the-middle (MITM) attacks. This has happened in the past due to vulnerabilities in cryptographic software libraries or protocol implementations, the most prominent examples being Heartbleed, BEAST and Logjam.

Besides abusing these vulnerabilities, skilled attackers can also attempt to steal the private keys of the certificate. The latter almost always involves a breach of the company infrastructure by an attacker with advanced capabilities.

BGP Hijacking

Yet another important threat you should be aware of is Border Gateway Protocol (BGP) hijacking to obtain valid certificates — valid in the sense that the certificates have not been stolen from their rightful owner and that, according to the CA, the verification process was successful. One method involves an attacker conducting a local hijack to make the CA believe they are the owners of a targeted domain. The hijack consists of redirecting the network, especially the path used for the verification, to a network under the attacker’s control. Although this only works well if the attacker is close enough — networkwise — to the CA and the victim is relatively far, your incident response plan should take this risk into account.

How Do You Defend Against These Threats?

There is no single solution that you can apply as a defensive measure against these attacks. Instead, these are threats you can only combat with zero trust security, a layered defense model and security best practices. Get started by checking off some of these quick wins:

  • Implement certificate pinning — note that this is being overhauled by Certificate Transparency, an open framework for monitoring and auditing SSL certificates.
  • Monitor for issued certificates that closely resemble the name of your organization or products. This monitoring can alert you if attackers start targeting your brand, sometimes even before a campaign has started.
  • Monitor and possibly block domains that have a high deceptive domain score.
  • Subscribe to the feeds provided by initiatives such as Phishtank or OpenPhish to proactively block access and review the proxy logs for access attempts.
  • Filter access to newly observed domains (NODs). Be aware that some offerings in the marketplace provide packages of “aged” domains, bypassing this protection measure.
  • Subscribe to a threat feed or collaborating closely with an information sharing and analysis center (ISAC) or computer security incident response team (CSIRT) to get timely updates about new malicious sites.

Further enhance your defenses with the following best practices for zero trust security:

  • Encrypt your internal traffic, especially in environments that utilize single sign-on (SSO). It’s important that every resource that requires authentication supports an encrypted communication channel.
  • Implement role-based access and make sure that users are only put in groups that are strictly necessary to do their job. Avoid having too many users with escalated privileges.
  • Lock down the environment in which users work, possibly giving them thin clients or systems that are restored to a known good image overnight.
  • Monitor your entire IT environment, including endpoints, servers and internal network traffic, and consider applying advanced technologies such as artificial intelligence to help.

More from Identity & Access

Passwords, passkeys and familiarity bias

5 min read - As passkey (passwordless authentication) adoption proceeds, misconceptions abound. There appears to be a widespread impression that passkeys may be more convenient and less secure than passwords. The reality is that they are both more secure and more convenient — possibly a first in cybersecurity.Most of us could be forgiven for not realizing passwordless authentication is more secure than passwords. Thinking back to the first couple of use cases I was exposed to — a phone operating system (OS) and a…

Obtaining security clearance: Hurdles and requirements

3 min read - As security moves closer to the top of the operational priority list for private and public organizations, needing to obtain a security clearance for jobs is more commonplace. Security clearance is a prerequisite for a wide range of roles, especially those related to national security and defense.Obtaining that clearance, however, is far from simple. The process often involves scrutinizing one’s background, financial history and even personal character. Let’s briefly explore some of the hurdles, expectations and requirements of obtaining a…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today