Secure socket layers (SSL) and its evolutionary descendant, Transport Level Security (TLS), are the most widely used protocols for ensuring confidentiality among service information exchanges. Despite this fact, their implementation is one of the most misunderstood, misconfigured, and prone-to-human-error options available.

Codebreaker and government intelligence pioneer Elizabeth Friedman.
Source: Jason Fagone’s book “The Woman Who Smashed Codes”

“Why?” you may ask. Opinions on the matter differ greatly, but generally, when implementing SSL/TLS encryption you’re facing a life-like organism that continuously mutates and needs constant re-evaluation and caring.

Remarkably, cryptanalysts such as Elizabeth Friedman (pictured above) did this in the past with only the use of pen and paper (no modern OSINT tools to crack such things at the time!).

In the tradition of greats like Friedman, a vast number of mathematicians and codebreakers are constantly testing different cryptography algorithms for strength, usability, and any problems that could possibly arise if used broadly.

This is true not only for brand new encryption algorithms (as we featured before in “All Things Quantum”) but also for currently used ciphers that are broken or will be at any point in the future. They leave room for misconfigurations, deprecated implementations (such as expired certificates), and other problems to be addressed.

Do I have SSL certificates deployed?

This is a valid question, especially if you’re not running your infrastructure and want to analyze for any possible attack vector that could allow a posterior compromise.

To address this, we’ll show you how to check for the history of deployed certificate records using SurfaceBrowser™, by performing a certificate discovery starting from your company’s name or a desired hostname.

Then, we’ll use our SecurityTrails API™ to show how you can do nearly the same thing using different tools and interfaces.

Scraping your company’s certificates using SurfaceBrowser™

After logging into the interface you’ll find the text box with the option Company Domain selected. Enter your desired hostname, then check the results:

Results for this or any other desired hostname will be displayed in the following fashion, as a listing with all recovered digital assets ordered by categories. On the left menu, you can find the SSL label and click into it to get all certificate-related information.

Here you can see all the certificates found, and you can order them by different criteria such as expired and valid dated registries.

By clicking on the certificate name you can go one step further and visualize particular information about every certificate—such as hashing fingerprints, creation and expiration dates, issuer, and subject information among others.

In case you want to play around and do cross-checks of information by using an SQL syntax, we invite you to check out our latest post, Product Update: SurfaceBrowser™ – SQL Explorer: SSL Certificate Scraping Showcase.

Find your company’s SSL historical records with SecurityTrails API™

API documentation is available here and you can also find SSL-related functionality at Domains > SSL Certificates (Pages) and Domains > SSL Certificates (Streams).

These pages will provide all the certificate information related to a certain hostname you enter, and below you can see the query results, which are output in JSON format.

Every record will be separated and you can browse between all options, labels, and results information.

Streams, on the other hand, will output everything together and you’ll have to take care of every corresponding label identification. Here’s what it looks like:

We’ve covered how to get all of your certificate’s information using SecurityTrails API™. Now let’s go a little further and check out how well those certificates are implemented in the following sections.

Checking your SSL certificate historical records

It’s very important to check up on how certificates are implemented, and one critical area is finding out whether the service’s actual offering is valid or not. For this, we’ll use the SQL Explorer feature in SurfaceBrowser™ to explain why it’s a bad idea to not renew certificates.

In the following query, we’re asking for all certificates that have configured their “not valid after” date before the time of this writing, which means that they have expired.

As you can see in the above example there are some hostnames with the apex_domain equinix.com matches the query’s specification, those results are worthy of an additional in-detail analysis.

Services using expired certificates are prone to impersonation by malicious third parties that may interfere with normal communications. Man-in-the-middle attacks take advantage of these misconfigurations, and by using different elements (such as the best phishing tools) they trick users into accepting fake certificates, to inject and sniff traffic into communications.

Once the user has accepted the false/fake/expired/invalid certificate, the attacker can capture traffic as if it were unencrypted. It’s also possible, however, to inject packets and place all sorts of payloads that may compromise client applications.

Testing your certificate implementation

It’s very important to keep track of your implementations and regularly check against deprecated ciphers or misconfigurations. There are different options for you to automate this, so we’ll showcase a few tools that may complement our API’s certificate discovery with a more in-depth and specific service analysis.

Using your web browser for particular checks

One of the most commonly used services for SSL/TLS analysis is Qualys SSL Labs, which we’ve featured in the past. To show an analysis using this tool you must enter the site (using the above link) and select “Test your server”:

After placing your desired target in the Hostname text box you’ll get a result similar to the above. Just remember to check “Do not show the results on the boards” if you don’t want your results to be exposed at their site.

If you already checked your infrastructure and want to re-run a check after making any changes to the services, you must click the Clear cache link to avoid using previously saved scanning results again.

Using the command line for bulk analysis

Web browser interfaces often allow us to use only one domain or IP at a time to conduct checks against the service we want to analyze. To overcome this there are some useful command-line tools that we can use to include them inside our batch scripts and use them with several targets. We’re covering two of them below.

Using ssllabs-scan

In the following, we’ll check different services running SSL certificates using two different tools:

 $ docker pull jumanjiman/ssllabs-scan:latest latest: Pulling from jumanjiman/ssllabs-scan 6e53f611f3e5: Pull complete 6836ab1d7e3b: Pull complete 2b3390b5d16d: Pull complete Digest: sha256:31478434ccc7bde64ba335b3d266d8f9770959c20bb438cef8fcdfcaba16b28a Status: Downloaded newer image for jumanjiman/ssllabs-scan:latest docker.io/jumanjiman/ssllabs-scan:latest

After the image pulling, you can run the application and check the different options:

 $ docker run --rm -ti jumanjiman/ssllabs-scan Usage of /ssllabs-scan: -api string API entry point, for example https://www.example.com/api/ (default "BUILTIN") -grade Output only the hostname: grade -hostcheck If true, host resolution failure will result in a fatal error. -hostfile string File containing hosts to scan (one per line) -ignore-mismatch If true, certificate hostname mismatch does not stop assessment. -insecure Skip certificate validation. For use in development only. Do not use. -json-flat Output results in flattened JSON format -maxage int Maximum acceptable age of cached results, in hours. A zero value is ignored. -quiet Disable status messages (logging) -usecache If true, accept cached results (if available), else force live scan. -verbosity string Configure log verbosity: error, notice, info, debug, or trace. (default "info") -version Print version and API location information and exit

This check will simply ask for the grade of the scan and use SSL Labs’ cache in case the hostname has already been scanned by another user:

 $ docker run --rm -ti jumanjiman/ssllabs-scan -grade -usecache equinix.com 2020/09/11 14:23:46 [INFO] SSL Labs v2.1.7 (criteria version 2009q) 2020/09/11 14:23:46 [NOTICE] Server message: This assessment service is provided free of charge by Qualys SSL Labs, subject to our terms and conditions: https://www.ssllabs.com/about/terms.html 2020/09/11 14:23:49 [INFO] Assessment starting: equinix.com 2020/09/11 14:23:50 [INFO] Assessment complete: equinix.com (1 host in 98 seconds) 216.221.225.13: B HostName:"equinix.com" "216.221.225.13":"B" 2020/09/11 14:23:50 [INFO] All assessments complete; shutting down

You can play around with the different options and output formats to put the obtained information to better use.

Using testssl.sh

Testssl.sh is another useful tool for your command line. In this example, we’ll use the run command to pull the official image located here and check the –help flag output right away.

 $ docker run --rm -ti drwetter/testssl.sh Unable to find image 'drwetter/testssl.sh:latest' locally latest: Pulling from drwetter/testssl.sh cbdbe7a5bc2a: Pull complete 808f0c986961: Pull complete 337fce52f936: Pull complete 5b6dc4bb67fd: Pull complete b004a1d6ca1b: Pull complete Digest: sha256:077f90dd099c061a6657ea48422fc8b60dfcbeab6774b6c9ba2dcd0fb8e4ded2 Status: Downloaded newer image for drwetter/testssl.sh:latest "testssl.sh [options] <URI>" or "testssl.sh <options>" "testssl.sh <option>", where <option> is mostly standalone and one of: --help what you're looking at -b, --banner displays banner + version of testssl.sh -v, --version same as previous -V, --local [pattern] pretty print all local ciphers (of openssl only). If search pattern supplied: it is an an ignore case word pattern of cipher hexcode or any other string in its name, kx or bits [...]

Now we’re going to analyze a domain name’s MX record and then try to analyze the SMTP’s certificate implementation security (we’re just highlighting the most interesting findings).

The command line indicates the use of STARTTLS in conjunction with the SMTP protocol. We also need to specify the hostname followed by a colon and the port (e.g. :587):

 $ testssl -t smtp mx-record.my-domain.tld:25

Results as follows:

 [..] Testing cipher categories NULL ciphers (no encryption) not offered (OK) Anonymous NULL Ciphers (no authentication) offered (NOT ok) Export ciphers (w/o ADH+NULL) not offered (OK) LOW: 64 Bit + DES, RC[2,4], MD5 (w/o export) offered (NOT ok) Triple DES Ciphers / IDEA offered Obsoleted CBC ciphers (AES, ARIA etc.) offered Strong encryption (AEAD ciphers) with no FS offered (OK) Forward Secrecy strong encryption (AEAD ciphers) offered (OK) [...] Testing vulnerabilities Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension CCS (CVE-2014-0224) not vulnerable (OK) ROBOT not vulnerable (OK) Secure Renegotiation (RFC 5746) supported (OK) Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), potential DoS threat CRIME, TLS (CVE-2012-4929) not vulnerable (OK) (not using HTTP anyway) POODLE, SSL (CVE-2014-3566) not vulnerable (OK), no SSLv3 support TLS_FALLBACK_SCSV (RFC 7507) Downgrade attack prevention supported (OK) SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers [...] RC4 (CVE-2013-2566, CVE-2015-2808) VULNERABLE (NOT ok): ECDHE-RSA-RC4-SHA AECDH-RC4-SHA ADH-RC4-MD5 RC4-SHA RC4-MD5 [...]

There’s also an experimental rating that tries to be compatible with the one at SSL Labs. For this examination, the resulting grade is T (with A+ being the best grade).

 Rating (experimental) Rating specs (not complete) SSL Labs's 'SSL Server Rating Guide' (version 2009q from 2020-01-30) Specification documentation https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide Protocol Support (weighted) 0 (0) Key Exchange (weighted) 0 (0) Cipher Strength (weighted) 0 (0) Final Score 0 Overall Grade T Grade cap reasons Grade capped to T. Encryption via STARTTLS is not mandatory (opportunistic). Grade capped to B. TLS 1.1 offered Grade capped to B. TLS 1.0 offered Grade capped to B. RC4 ciphers offered

In case you have multiple IP addresses associated with a hostname (multiple DNS A records per domain or subdomain) the tool will run all tests for every record and let you know which addresses it has checked when finished:

 Done testing now all IP addresses (on port 1443): 1.2.3.3 5.4.3.2 6.5.4.8

As mentioned above, SSL/TLS implementations occur across different services on the server-side—such as SMTP, HTTP, POP3, IMAP, XMPP, VNC, to name a few—but as establishing communications requires at least two parties, the same checks are also valid for client applications.

Checking web browsers for weak ciphers

Silently forcing the downgrade of a web browser could be an attempt to compromise communications. Servers may offer a suite of “only weak ciphers” and if the browser accepts them, then a malicious third party could potentially sniff, capture and decrypt the network stream.

To reduce the attack surface, you can check the list of available ciphers that your application accepts as valid, acknowledge which are weak, and remove them from the supported ciphers list. We’re showing an example of a web browser check at SSL Labs (Projects > SSL Client Test):

This check will provide an insight into what your web browser supports and whether it’s able to be compromised with the most common SSL/TLS vulnerabilities.

Summary

Service communication encryption using SSL/TLS is an incredibly exciting, sometimes obscure, and often difficult to understand topic which we’ve covered in the past. We’ve even addressed it from different perspectives:

The implementation of such protections brings with it several subtopics to analyze and understand, which makes the use of encryption even more prone to human errors.

But we’re in luck! The number of resources and tools to perform both intelligence gathering and certificate analysis is on the rise. And that includes different articles you’ll find throughout the web, beginning with the useful information we’ve featured in this blog!