Lesson Notes
Burp Suite: Web Proxy
Module 3: Tools of the Trade. Intercept HTTPS (with cert install).
Module 3: Burp Suite Web Proxy — Comprehensive Theory Guide
Burp Suite is the industry-standard platform for manual web application security testing. It acts as an HTTP/HTTPS proxy between your browser and the target server: every request and response passes through Burp, where you can inspect, modify, and replay them. To see the contents of HTTPS traffic (cookies, POST bodies, API payloads), you must install Burp's Certificate Authority (CA) certificate in your browser or OS trust store. Without it, you will see only the TLS handshake and encrypted application data blobs—useless for finding injection points or session issues. This lesson explains in detail how a web proxy works, why HTTPS interception requires a custom CA, and how to use Burp ethically on authorized targets only.
How an HTTP/HTTPS Proxy Works
When you configure your browser to use a proxy (e.g. 127.0.0.1:8080 for Burp), the browser does not connect directly to the target server. Instead, it sends every HTTP or HTTPS request to the proxy. The proxy receives the request, can hold it (intercept), log it, or forward it to the real server. The server's response comes back to the proxy, then to the browser. From the server's perspective, the client is the proxy; from the browser's perspective, the server is the proxy. This man-in-the-middle position is exactly what allows you to see and modify traffic. For HTTP (port 80), the data is plaintext—you see full headers, query strings, and body. For HTTPS (port 443), the browser expects to speak TLS to the server; if the proxy does not handle TLS correctly, you see only ciphertext.
Why HTTPS Interception Requires a Custom CA
In a normal HTTPS connection, the browser connects to the server, receives the server's certificate (signed by a trusted CA like DigiCert or Let's Encrypt), and verifies the signature. Then it negotiates a session key and encrypts application data. If you simply forward the browser's TLS connection to the server, the proxy cannot read or modify the encrypted stream. Burp therefore acts as a TLS endpoint: the browser connects to Burp with TLS, and Burp opens a separate TLS connection to the target server. The browser receives a certificate from Burp—but that certificate is for the target hostname (e.g. example.com) and is signed by Burp's own CA. By default, the browser would show a certificate error because Burp's CA is not in the trust store. Once you install Burp's CA certificate as a trusted root, the browser trusts any certificate Burp signs for any hostname. Burp can then decrypt the browser→Burp stream, inspect or modify the request, re-encrypt it, and send it to the real server over the Burp→server TLS connection. You see plaintext in Burp; both legs (browser–Burp and Burp–server) remain encrypted.
Installing Burp's CA Certificate
In Burp, go to Proxy → Options → Import / export CA certificate. Export the certificate in DER format. On your machine: for Firefox, go to Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import, and select the Burp CA file. For Chrome (which uses the system store on Windows/macOS), import the cert into the OS trust store (e.g. Windows Certificate Manager, or Keychain on macOS) under Trusted Root Certification Authorities. Restart the browser if needed. After that, when you visit an HTTPS site through Burp, the browser will trust Burp's dynamically generated certificate for that host, and Burp will show the decrypted request and response in the HTTP history and Intercept tabs. Never use this setup to intercept traffic to sites you are not authorized to test.
Intercept, Modify, and Replay
With Intercept turned on (Proxy → Intercept → Intercept is on), Burp holds each request until you forward or drop it. You can edit the request (URL, headers, body) before forwarding—for example, change a parameter to test for SQL injection or add a header to bypass a check. The response from the server is also visible after you forward. Repeater lets you send a request multiple times with different payloads without re-browsing. Intruder automates fuzzing (e.g. many values for a single parameter). All of this depends on seeing plaintext; hence the critical role of the CA install for HTTPS. Use these features only within authorized scope.
Key Takeaway for Lesson 11
Burp Suite is a web proxy that sits between browser and server. To intercept HTTPS you must install Burp's CA certificate so the browser trusts Burp-issued certs; then you see decrypted requests and responses. Use Burp only on authorized targets. Next: Nikto and Dirb for vulnerability and directory discovery in web recon.