tips tools

SecurityTrails Blog · Sep 17 · by Nicolas Pence

SSL/TLS History: Discovering Service Encryption

Reading time: 11 minutes

Privacy in peer-to-peer communications throughout the World Wide Web has become an extremely widespread issue, especially over the last few years.

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.

Elizabeth Friedman

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:

Scrapping your company's certificates using SurfaceBrowser™

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.

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.

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.

Visualize particular information about every certificate

Fingerprints-issuer

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.

SSL certificates pages

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:

SSL certificates stream

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.

Checking your SSL certificate historical records

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.

Man-in-the-middle attacks

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”:

Using browser for particular checks

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):

Checking web browsers for weak ciphers

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!