Lab: Digital Certificates and Trust

By Drs. Anthony Vance and Dave Eargle

Part 1: Understanding Digital Certificates

A digital certificate “is essentially a public key accompanied by a signature of that key and associated information” (Aumasson 2018, Serious Cryptography). For TLS (X.509) certificates, this information includes the domain name, optionally alternative domain names that a cert is valid for, issue and expiration dates, and other details.

Examining details of IBM.com’s Certificate

Browse to ibm.com and inspect the certificate details. For example, in Firefox:

  • Click on the padlock icon in the URL bar.
  • Click on the arrow to the right of the domain name.

  • Click on “More Information”
  • Click “View Certificate”

  • Click on the “Details” tab.
Question: What is the root certificate authority for ibm.com?
Question: What is the intermediate certificate authority?

The purpose of an intermediate authority is the following:

“Every publicly-trusted Certificate Authority (such as Let’s Encrypt) has at least one root certificate which is incorporated into various browser and OS vendors’ (e.g. Mozilla, Google) trusted root stores. This is what allows users who receive a certificate from a website to confirm that the certificate was issued by an organization that their browser trusts. But root certificates, by virtue of their widespread trust and long lives, must have their corresponding private key carefully protected and stored offline, and therefore can’t be used to sign things all the time. So every Certificate Authority (CA) also has some number of “intermediates”, certificates which are able to issue additional certificates but are not roots, which they use for day-to-day issuance” (Let’s Encrypt 2020).

What are some of the other domains for which this certificate is valid?' In Firefox, these are listed under "Certificate Subject Alt Name."
Question: What are some of the other domains for which the ibm.com certificate is valid?

For TLS X.509 certificates, the signature in the certificate is signed by the public key included in an intermediate or root certificate authority certificate (see figure below). An intermediate certificate, if any, is signed by the public key included in a root certificate. The root certificate is signed using the public key in its own certificate (a self-signed certificate). Linking certificates in this way forms a certificate chain.

Certificate chain image from Wikipedia

Question: For IBM's certificate, what algorithm do they use for their public key?
Question: What is the keysize of their public key?

Root Certificate Authorities

  1. In your Kali VM, open Firefox. Click on the “hamburger” icon in the top-right, and select “Preferences.”

  2. Select “Privacy & Security” on the left-hand side of the preferences window, and scroll down to the bottom to see the “Certificates” section. Click the “View Certificates” button.
  3. Under the ‘Authorities’ tab, find the “DigiCert Global Root CA” certificate that was ultimately used to verify the authenticity of IBM’s certificate. Click “Edit Trust.”

    Question: What can this DigiCert root certificate be used for?
  4. Now find any of the root certificates for Symantec Corporation. Select one and click “Edit Trust.” What can this Symantec root certificate be used for? What can it not be used for? Examine other certs in the list to see what a “normal” cert in Firefox’s store can do.

    Question: What can this Symantec root certificate be used for?

    Why is the trust for Symantec’s cert anomalous? To help you answer this question, look at one or more of the following resources:

    Question: Why does Firefox trust Symantec's Certificates in this way?

Untrusted Root CA

  1. Under the “Servers” tab of the View Certificates” dialog, certificates for what organization are listed? Click on one of the certificates and click the “View” button.
  2. There is a message at the top of the View window’s General tab. What does Firefox say about the trust of this Root Certificate authority? Why does Firefox say this?

    To help you answer this question, look at one or more of the following resources:

    Question: What does Firefox say about the trust of this Root Certificate authority? Why does Firefox say this?

Perfect Forward Secrecy

  1. On any computer with Google Chrome installed (your Kali VM does not have Chrome), browse to https://static-rsa.badssl.com
  2. From the hamburger icon in the top right-hand corner, select “More Tools” > “Developer Tools.”

  3. Select the “Security” tab from the Developer Tools. This tab displays details about the connection. What does Chrome say about the connection settings for RSA key exchange, and why?

    To help you answer this question, look at one or more of the following resources:

    Question: What does Chrome say about the connection settings for RSA key exchange, and why?

Part 2: MITM with Burp Suite

In this section, you will use a tool called Burp Suite in your Kali VM, and you will configure Kali’s Firefox to route all traffic through Burp Suite. You will feign a MITM attack and intercept a username|password that you submit to bankofamerica.com. This lab uses the free Burp Suite Community Edition.

Burp Suite is a network traffic proxy application created by PortSwigger. The tool can be used by developers and researchers to inspect and manipulate any network traffic to which Burp Suite has access. It is commonly used in the cybersecurity community for inspection and manipulation of web requests. See articles such as this one which rely on Burp Suite for analysis of a smartphone app’s web requests. Alternatives to Burp include mitmproxy, Fiddler, ZAP, and Charles.

Configure Burp Suite as a proxy

  1. Launch Burp Suite. Follow the steps displayed below to get through the launch process.

    • search for Burp Suite using the kali launcher, and click it.

    • ignore the warning about the jre version

    • skip the Burp Suite update

    • choose to launch a temporary project

    • launch with the default settings

    When Burp Suite is started, it by default “listens” for incoming traffic on localhost:8080, as shown below.

    Turn off interception from the “Proxy” > “Intercept” tab. Interception is used when the goal is to modify requests before they are sent on their way. The goal of this section of the lab, however, is to show that https traffic can be readily decrypted if a MITM attack is successful.

  2. Configure Firefox to route all internet traffic through Burp Suite.

    • Firefox >

    • “Hamburger” icon on upper-right > Preferences

    • (scroll to the bottom or search) Network Proxy - Settings >

    • Manual proxy configuration, HTTP Proxy localhost (or equivalently 127.0.0.1), Port 8080, check box for “use this proxy server for all protocols”

    Firefox is now proxying all web requests through Burp Suite.

    Note: the above instructions are also described when the following link is clicked:

Attempt to visit a secure website

  1. Now that Firefox is passing all traffic to Burp Suite, try to visit an https-site. The following will work against any https site, but we will visit https://bankofamerica.com

    You receive an SSL connection error!

    1. Inspect the cert. You can do this by clicking the “View Certificate” button.

    2. Alternatively, you can copy the base64-encoded version and use a web cert decoder. To do this, on the SSL error page, click “Advanced”, then click the link to the error code. Copy the —BEGIN CERTIFICATE– block to your clipboard.

      Search the internet for an “ssl cert decoder”, such as https://certlogik.com/decoder/ or https://www.sslshopper.com/certificate-decoder.html, to decode the base64-encoded cert that you copied in the previous step.

  2. Configure Firefox to trust Burp Suite’s self-signed certificate.

    Burp Suite generates a unique ssl keypair for each installation. We need to instruct Firefox to trust Burp Suite’s public key for authenticating websites. As seen earlier in this lab, Firefox maintains its own certificate authority list.

    Follow the instructions on the following website to install Burp Suite’s CA certificate in Firefox: link

    Note: The linked-to instructions above show Burp Suite Professional, but the instructions also work for Burp Suite Community Edition. You don't need to install another version of Burp Suite than the one that is already installed on your Kali VM.
    Note: When the instructions say, "In the top-right corner of the page, click "CA Certificate" to download your unique Burp CA certificate. Take note of where you save this.", you should choose "Save File", and your file will be downloaded with filename "cacert.der".

  3. Use Firefox again. Close the Bank Of America error page, and use a new tab to attempt again to navigate to https://bankofamerica.com

    It loads!

    Examine the HTTPS SSL connection:

    • In the Firefox address bar, click the lock next to url
    • click the > button on the resultant popup dialog
    • click More Information

Capture Login

  1. Pretend that you are logging in to Bankofamerica.com. Enter as your username your TUid. Choose any fake password. Submit your login request. It will fail.

  2. Burp Suite should have logged the login attempt – Let’s find it. Go back to Burp Suite.

    1. Within Burp Suite, navigate to the “Proxy” > “HTTP history” tab. Click the “Filter” bar to open the filter dialog, and change the settings as follows to make the visual search easier.

      • Login requests submit fields such as usernames and passwords using “parameters”,
        so select “Filter by request type” > “Show only parameterized results.”
      • Login requests – at least for this site – use MIME type “html”, so in “Filter by MIME type,” uncheck all except for HTML.

      That should be sufficient to easily find the HTTP POST request which was the attempted login.

      A POST request allows parameters such as the username and password to be sent in the body of the web request.

    2. Look for and select (click) the entry with:

      • a POST method
      • a URL similar to /login/sign-in/entry/:

      Select it, and then in the populated view beneath the list entries, select “Request” tab and then “Params” tab. Scroll down until you can see the “passcode” and “onlineid” named entries. These should be the values you submitted on your login attempt.

      You should see your TUid and fake password.

      Question: Submit a screenshot showing your username and fake password within the Burp Suite window for the Bank of America login attempt. Show your entire Kali view in your screenshot. Example screenshot below.

  3. But wait, this was an HTTPS connection, so the web transaction such as the submitted username|password) should have been encrypted. How could Burp Suite have decrypted it?

    This is the essence of a man-in-the-middle attack – a secure connection to an evil server which talks to your intended server on your behalf.

    In our pretend case, Burp Suite is the evil server, and Bank Of America’s server is the intended server. All secure content is visible as plaintext to the attacker, because the attacker’s SSL cert was used to establish the secure HTTPS connection.

  4. Finally, clean up by reconfiguring Firefox to no longer use a network proxy. To do this, revisit Firefox’s “Network Settings” page under the Preferences view, and select “No Proxy”.