I asked to myself: “Hey, how does Burp work with HTTPS and why do some apps break even after trusting the Burp cert?” and honestly, it messed me up.

I thought I understood HTTPS. I knew about SSL and certs in theory. But the moment I hit a real app doing SSL pinning, everything broke and I had no idea what was going on.

So I sat down and rewired my brain. This article is me, re-explaining everything I wish someone explained to me when I was just starting out.

After a successful TCP handshake, the TLS handshake begins. This is where encryption and identity verification take place before any real HTTP data (like a GET request) is exchanged.

Now how does it work:

The client or browser will send a ClientHello message to the server. The server responds with a ServerHello, along with its public key and certificate. The certificate is used to prove that the certificate belongs to a valid organization and is not some phishy attacker.

The browser validates the certificate by:

• Checking expiration
• Verifying it’s signed by a trusted Certificate Authority (CA)
• Ensuring the domain matches

Internally, the browser uses the CA’s public key to decrypt the signature in the server’s cert and checks if it matches the expected value. If it does — the cert is trustworthy, and the TLS handshake finishes successfully.

Boom — now a secure tunnel is set up and real HTTP communication (like GET, POST) begins.

You can read more in depth about the actual communication here: https://tls12.xargs.org/

When you configure your browser to route traffic through Burp:

• You configure your browser to use Burp Suite as a proxy (typically HTTP/HTTPS proxy on 127.0.0.1:8080).
• The browser sends the HTTPS request to Burp, thinking Burp is the destination server (e.g., example.com).
• Burp connects to the real example.com server and retrieves its SSL/TLS certificate.
• Burp generates a fake certificate for example.com, signed by Burp’s own internal Certificate Authority (CA).
• Burp sends the fake certificate to the browser.
• The browser accepts the fake certificate only if Burp’s CA certificate has been installed and trusted in the browser.
• Burp then relays data between the browser and the real server, decrypting and possibly modifying traffic in both directions.

Now the browser does one of two things:

• If Burp’s CA isn’t trusted: Browser throws SEC_ERROR_UNKNOWN_ISSUER, TLS fails
• If Burp’s CA is trusted: TLS handshake succeeds, and Burp can now see/decrypt HTTPS traffic

Burp essentially performs two TLS handshakes:

• One with the real server
• One with the browser

This is what makes interception possible.

SSL pinning is when an app doesn’t care what the OS/browser trusts. Instead, it hardcodes its own trust.

“I trust only this exact cert or public key — nothing else.”

Pinning protects apps against MITM attacks even if the user installs a malicious CA (like Burp’s). So even with Burp’s CA added, the app says:

“This cert isn’t what I was expecting. Connection refused.”

Types of pinning:

• Cert pinning — pins full cert (PEM/X.509)
• Public key pinning — pins SHA256 of public key
• SPKI pinning — pins hash of SubjectPublicKeyInfo block

Where is it pinned?

• Hardcoded in Java code (CertificatePinner.add())
• Inside network_security_config.xml
• Stored in native libraries (.so files)

Here’s what a pinned app does when making an HTTPS request:

1. Connects to the server
2. Gets the certificate from the server
3. Extracts the public key or full cert
4. Compares it to the pinned version
5. If match → allow request, If mismatch → block the request

This breaks interception.

There are two main ways:

1. Dynamic Bypass (Frida, Objection)

Hook the function that performs the pinning check and force it to always return true. There are a lot of scripts available online you can refer to.

2. Static Bypass (APK patching)

• Decompile the APK using apktool or jadx
• Find the pinning logic
• Remove it or force it to accept all certs
• Rebuild and re-sign the APK

This is more permanent but riskier — could break functionality.

• You don’t see traffic in Burp even after trusting Burp’s CA
• App shows network errors
• logcat shows: Trust anchor not found, SSLHandshakeException
• Cert verification fails in Frida logs

I will write a specific article on how to properly bypass SSL Pinning if needed.

• SSL = encryption + trust
• Burp fakes trust with its own CA
• SSL pinning ignores system trust and validates the cert manually
• Bypass tricks the app into accepting any cert again

That is it for this article thingy, Happy Hacking :)