.svg "2024_Full_Logo_Full_Color_SVG (1)"){kind=logo}
The Problem
For newcomers to application penetration testing, a reasonably common question is How do you proxy HTTPS traffic?
I’ve heard it frequently from students and from seasoned developers alike. Their instinct is correct, in that we have to do something extra to make that work. While this post won’t go into a deep dive on the technical elements of TLS, let’s take a high-level look at interception of HTTPS traffic. If you have been learning in a lab environment like SamuraiWTF, there’s a reasonable possibility that the target apps have all been served unencrypted (HTTP). For Burp Suite to intercept TLS-encrypted (HTTPS) traffic, it has to decrypt it. The traffic is captured in Burp Suite, then re-encrypted and sent to the browser. The problem with this is that SSL/TLS uses certificates to ensure that the traffic was encrypted by expected authority. When the secureideas.com website performs its side of the TLS handshake, it sends a certificate that has been issued by a certificate authority (CA). This authority is either trusted directly, or has implicit trust granted by another authority. And that chain-of-trust can continue several levels up, as in the hierarchy pictured below. The Starfield Class 2 CA is widely trusted by default, and that trust is granted to their Services Root CA, which then grants the trust to the Amazon Root CA 1, and so on until we get to the certificate the website is actually serving.
Going back to Burp Suite, it doesn’t have the private key associated with the *.secureideas.com certificate. So when you browse to secureideas.com, and Burp decrypts and re-encrypts your traffic, it is sent from Burp to your browser with a root certificate generated by your Burp Suite instance. Since this certificate wasn’t granted by an authority that your computer already trusts, your browser receives it and responds the same way it would if an unauthorized party was intercepting your traffic from a person-in-the-middle position. Which looks something like this:
Not only is the browser upset with the situation, but Burp Suite is raising alarms about the problem too. You can see them in the Event log under the Dashboard tab in Burp Suite.
The Solution
This is easy to fix. All we need to do is tell our browser that the Burp CA can be trusted. Because every new installation of Burp generates a different CA, this doesn’t create a risk of somebody else intercepting your traffic surreptitiously with their Burp instance. The actual steps to perform this vary slightly by operating system. For today, we’ll just cover Linux since that’s what I use for all my testing, and it’s applicable to Burp Suite.
Linux
1. Export the Certificate from Burp
Under the Proxy -> Options tab, click the Import / export CA certificate button.
You want to export the Certifcate in DER format. For convenience, save it with a .der file extension.
2. Add the trust in the browser
These steps are for Chrome, but the process is similar for Firefox.
Open the menu, and select Settings
Navigate to the Privacy and security section, then click the More button to expand the options, and choose Manage certificates
Trust this certificate for identifying websites, and click OK.
And you’re done. Just like that, you can proxy TLS-encrypted traffic through Burp without any issues. If your TLS issues persist, one thing to check is whether the website is using HTTP Public Key Pinning (HPKP). This is an uncommon security control that has some major drawbacks, but it breaks your ability to do person-in-the-middle interception properly.
As long as your Burp CA remains the same, you won’t have to go through these steps gain in that browser (or at all on Mac/Windows, as they use system-level cert trust stores)