I recently hit a bit of a snag intercepting traffic in the Burp proxy during one of the tests. The usual traffic interception settings wouldn’t work.
I had the private key (.key) and a certificate (.pem) file that would be used in the authentication process but a key? private key? for TLS authentication? Since when did TLS require a client certificate exchange?
After an eternity of searching, all fingers (sources) pointed to mTLS. Now,
What the heck is mTLS?
Long story short: TLS authentication but on both, the server and client, sides.
Technically, it’s a process of establishing a two-way encrypted TLS connection in which both parties present their digital certificates (X.509) to authenticate each other.
How does it work?
Armed with this information, I still couldn’t figure out a way to set up the proxy. Tried to upload the certificate (.pem) file in Burp, but it didn’t solve anything. It must have something to do with the .key file?
To give you the solution, here it is:
Generate a PKCS#12 file (.pfx) using the openssl tool and load it in Burp.
Steps to configure Burp:
You should now be able to intercept the traffic.
What was the actual cause?
Presenting a trusted server certificate to the client was possible for the proxy. And although Burp proxy’s CA certificate was trusted by the client, the server does not recognise it. Therefore, it wasn’t possible to create a successful connection.
Bundling up the private key with its X.509 certificate into PKCS#12 format and configuring Burp proxy to use it, bypasses the restriction because Burp was now able to present the legit client certificate. This enabled Burp to intercept the traffic.
References:
