A hacker's guide to SSL certificates, featuring TLSx

Introduction

In today's digital world, online security is more important than ever. As we rely increasingly on the internet, we must have a way to keep our communications private and secure. That's where SSL and TLS come in.

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are like secret handshakes for the internet. They establish a secure connection between a website and your browser, ensuring that any information exchanged between them is private and can't be intercepted or tampered with by anyone else.

However, SSL and TLS do more than just keep your information safe. They also help verify that a website is who it says it is. So, when you see that little padlock icon in your browser's address bar, you know you're on a legitimate website and not a phishing scam.

In this blog, we'll dive deeply into SSL and TLS protocols. We'll learn how to use these certificates for reconnaissance, various vulnerabilities and misconfigurations, and learn how to use tools like the TLSx tool by ProjectDiscovery to find vulnerabilities and misconfigurations.

How does TLS work?

To the end user, the process is mostly invisible. But the whole process is actually quite involved.

1. The client initiates the process by sending a request to the server to establish a secure connection.
2. The next step involves the server responding by sending a copy of its SSL/TLS certificate, which includes the server's public key.
3. Next, the client verifies the certificate and extracts the server's public key.
4. The client then creates a symmetric key and encrypts it with the server's public key, and the client sends the encrypted key to the server.
5. Next, the server decrypts the key using its private key, and both parties have the same symmetric key.
6. From this point on, all data exchanged between the client and server is encrypted and decrypted using this symmetric key.

TLSx - A fast and configurable TLS grabber

TLSx is a quick and configurable tool that acts as a Swiss army knife for finding TLS misconfigurations and performing reconnaissance. It is yet another feature-rich command-line tool which can help automate the recon and vulnerability scanning for the SSL/TLS certificates. It supports various features, including:

1. Misconfiguration scanning: It can check for multiple vulnerabilities in SSL and TLS certificates, such as expired certificates, and others.
2. SAN and CNs detection: It helps detect and extract the SANs and CNs fields from an SSL/TLS certificate.
3. Certificate parsing: TLSX can parse SSL and TLS certificates and extract information such as the expiration date, the issuing authority, and the encryption algorithms.
4. JARM/JA3 Fingerprinting: TLSX can generate JARM and JA3 fingerprints of SSL and TLS connections to identify the specific software and versions used on a website.
5. Reporting capability: TLSX can generate reports with the extracted information and the vulnerabilities found, making it easy to analyze the results.
   The installation process for this tool is straightforward, and detailed instructions can be found at: https://github.com/projectdiscovery/tlsx.

In the coming sections, we will also cover different aspects of SSL/TLS implementation that can be used to amplify hacking efforts. Where applicable, TLSx will be used as a demonstration.

Certificate transparency logs

Certificate transparency logs are public append-only logs that store information about SSL/TLS certificates. They are used to increase transparency and improve the security of the applications by allowing anyone to monitor the certificate issuance process and detect mis-issuance.

They are maintained by independent organizations and are verifiable by anyone via public key infrastructure. Furthermore, they allow for detection if a certificate has been issued improperly.

Verifying Ownership

The ownership of a host can be determined by checking the details on the SSL/TLS certificate associated with the host. There are multiple ways to check for this information: manually checking through the web browser and using tools such as TLSx.

In a web browser, you can usually find the owner of a host by following these steps:

1. Visit the website you want to check, such as https://ginandjuice.shop/.
2. Click on the lock icon in the address bar and click on the “Details” or “Certificate” tab.
3. Look for the "Subject" or "Issued to" field, which should contain the owner's information.

To check for ownership using the TLSx tool, run the following command: Command: tlsx -u https://ginandjuice.shop -cn

This command will return the certificate's subject, which is the owner of the website. Using the tool, you can quickly check the ownership of multiple hosts by providing multiple URLs as arguments.

SSL/TLS Protocols

There have been various protocol versions since the inception of SSLv2 in 1995 to TLSv1.3, the most recent version. Let’s briefly discuss multiple SSL and TLS protocols:

1. SSLv2: SSLv2 was the first version of the SSL protocol. It was published in 1995. It is considered highly insecure as it has several known vulnerabilities and is not recommended.
2. SSLv3: SSLv3 was the next version of the SSL protocol. It was published in 1996. It is also considered insecure and is not recommended as it is vulnerable to the POODLE attack.
3. TLSv1.0: This is the first version of the TLS protocol. It was published in 1999. It is susceptible to specific attacks, such as the POODLE attack, and it is recommended to disable it if possible.
4. TLSv1.1: This protocol version was published in 2006 and was designed to address some of the security weaknesses of TLSv1.0. It is considered more secure than TLSv1.0 but is still not recommended for use as it does not support perfect forward secrecy and is not as resistant to certain types of attacks as the newer versions.
5. TLSv1.2: This protocol version was published in 2008 and is considered more secure than previous versions. It is recommended for use as it supports perfect forward secrecy and other security improvements.
6. TLSv1.3: This protocol version was published in 2018 and is considered the most secure. It provides significant security improvements over previous versions, such as improved encryption and faster performance.

Generally, it is recommended to use the most recent version of the protocol supported by the client and the server, which is currently TLSv1.3. It is also important to note that even the most current protocol version should be configured correctly, and vulnerable ciphers and weak configurations should be avoided.

Run the following command to identify the protocol version using TLSx:
Command: tlsx -u https://ginandjuice.shop -tv

As shown in the above screenshot. The tool highlighted that the application https://ginandjuice.shop was using the TLS1.2 protocol.

Common Misconfigurations

Several misconfigurations can occur with SSL/TLS certificates, potentially leading to security vulnerabilities. Some common misconfigurations include:

1. Expired Certificates: An expired certificate has passed its expiration date and is no longer valid. This can occur if the certificate is not renewed in time.
2. Self-signed Certificates: A self-signed certificate is signed by the entity that owns the website rather than by a trusted certificate authority (CA).
3. Mismatched Certificates: A mismatched certificate does not match the domain name it is associated with. This can occur if the certificate was issued for a different domain name or if it is being used on another website than intended.
4. Revoked Certificates: A revoked certificate has been canceled by the issuing certificate authority (CA) before its expiration date. This can occur if the certificate was compromised, the certificate was issued to the wrong entity, or the certificate signing request needed to be verified.

Overall, the TLSX tool can detect these misconfigurations by running it with the URL of the website as an argument and checking the certificate details. It can reveal if the certificate is expired, self-signed, mismatched or revoked.

Run the following command to detect common misconfigurations using the TLSx tool: Command: ./tlsx -l hosts.txt -ex -ss -mm -re

Observed that the above command highlighted various misconfigurations, such as expired and revoked certificates from the above-supplied hosts list.

Enumerating ciphers with TLSx

One of the features of TLS is the ability to negotiate the use of different encryption ciphers during the initial handshake process. Enumerating ciphers allows one to understand and identify if any weak ciphers are used.

There are multiple ways to enumerate the ciphers and TLSx also provides a simple way to enumerate the ciphers by running the following command:

Command: tlsx -l hosts.txt -cipher -ce

To enumerate for the weak ciphers, you can use Nuclei as we have created a template for the same, which can be found here: https://github.com/projectdiscovery/nuclei-templates/blob/main/ssl/weak-cipher-suites.yaml

A scan with the nuclei for weak ciphers would look something like this:

Command: nuclei -u https://cbc.badssl.com/ -t weak-cipher-suites.yaml

SAN/CN

The Subject Alternative Name (SAN) and Common Name (CN) are fields in an SSL/TLS certificate that provide information about the domain name(s) associated with the certificate.

Subject Alternative Name (SAN): The SAN field extends to the X.509 standard, allowing multiple domain names to be associated with a single certificate. This means that a single certificate can secure multiple domain names, making it easy to add or remove domain names from a certificate without having to issue a new one.

Common Name (CN): The CN field is used to specify the primary domain name that the certificate is associated with. It is the domain name that the certificate is issued.

SAN and CN fields can be used for reconnaissance to discover hostnames associated with a target domain.

Run the following commands for performing SAN and CN scans using the TLSx tool: Command for SAN scanning: tlsx -u google.com -san

Command for CN scanning: tlsx -u google.com -cn

JARM/JA3 fingerprinting

JARM (JSON Application Renegotiation Metrics) and JA3 (SSL/TLS Client Fingerprinting) are methods of fingerprinting SSL/TLS clients.

JARM: JARM is a method of fingerprinting SSL/TLS clients by capturing the parameters of the SSL/TLS handshake and encoding them in a JSON format. This allows for easy comparison of the fingerprint against a known set of fingerprints to determine the client software and version.

JA3: JA3 is a method of fingerprinting SSL/TLS clients by capturing the parameters of the SSL/TLS handshake and generating a unique hash from them. This allows for easy comparison of the fingerprint against a known set of fingerprints to determine the client software and version.

Run the following commands for performing JARM and JA3 fingerprinting using the TLSx tool:
Command for JARM fingerprinting: tlsx -u google.com -jarm

Command for JA3 fingerprinting: tlsx -u google.com -ja3

Output data in JSON with TLSx

TLSx supports various feature flags that can be used to gather specific information. It also allows using -json feature flag to output the data in the JSON format that is the most convenient option for automation and post-processing. It could be really helpful to know if you are to build an automation pipeline, say for reconnaissance, and extracting data becomes much easier.

Run the following command to output data in JSON using TLSx: Command: ./tlsx -l hosts.txt -san -cn -json

To retrieve the data in a pretty view, run the following command: Command: ./tlsx -l hosts.txt -san -cn -json | jq

Summary

We discussed the importance of SSL and TLS certificates in securing online communications and how they can be helpful in penetration testing and bug bounty hunting. We briefly summarized the TLS protocol and its workings and introduced the TLSx tool, a powerful tool for scanning and analyzing SSL/TLS certificates.

Overall, this blog provides an overview of SSL/TLS, its importance in securing online communications, and how the TLSx tool can help security professionals identify and mitigate security risks in their SSL/TLS infrastructure.