Notebook/content/documentation/securité/ssl_bumping/ssl_bumping.en.md

title, date, weight, cascade

title	date	weight	cascade
SSL Bumping: How to Analyze SSL Traffic	2025-06-22T20:00:00+02:00	3	type docs

Introduction: What Happens Behind the Padlock?

The padlock icon in your browser's address bar is supposed to guarantee that your exchanges are encrypted and unreadable by a third party. Yet, in many corporate networks or school environments, this traffic is indeed analyzed. How is this possible without breaking the encryption?

This is where SSL Bumping (or TLS interception) comes in. Far from being a simple hacking technique, it's a commonly used and legitimate mechanism for inspecting HTTPS traffic.

Understanding SSL Bumping means understanding the limits of end-to-end encryption in certain contexts, and knowing how companies secure (or monitor) their networks. In this article, we'll dissect how this technique works and see how to set it up via a hands-on lab: squid-ssl-bumping-lab.

Part 1: The Concept of TLS Interception

An Acknowledged "Man-in-the-Middle"

The principle of HTTPS is comparable to sending mail in a safe where only the sender and the recipient have the key. If a network device (like a corporate proxy) needs to analyze the content to block malware or prevent a data leak, it hits a wall: the traffic is encrypted.

SSL Bumping gets around this problem by inserting itself in the middle of the communication:

The proxy will:

1. Intercept the client's HTTPS connection.
2. Decrypt the traffic to analyze it.
3. Re-encrypt the data before sending it to the final server.

Instead of having a single secure connection between your browser and the website, there are two: one between you and the proxy, and another between the proxy and the site. The proxy acts as a relay that reads everything as it passes through.

[!NOTE] A Question of Vocabulary We often talk about SSL Bumping (the historical term used by the Squid proxy), TLS interception (the technically accurate term today), or HTTPS inspection. In all cases, it's a Man-In-The-Middle (MITM) attack, but one carried out in a controlled and voluntary manner by the network administrator.

Why Inspect Encrypted Traffic?

TLS interception addresses real needs, mainly in the professional world:

1. Network security: Detecting malware downloaded via HTTPS or blocking access to malicious sites.
2. Data Loss Prevention (DLP): Making sure confidential information doesn't leave the company.
3. Filtering and compliance: Blocking certain content (social networks, inappropriate sites) according to company or institution policy.
4. Debugging: Analyzing API requests or diagnosing complex application issues.

Of course, this total visibility implies great responsibility, since the proxy has access to passwords, session cookies, and personal data.

Part 2: How Does It Work Technically?

To insert itself into an HTTPS connection without the browser blocking access, the proxy has to pull off a cryptographic sleight of hand.

Step 1: The Proxy Becomes a Certificate Authority (CA)

For SSL Bumping to work, the proxy must be able to generate certificates on the fly for any website. To do this, the administrator configures the proxy with its own internal Certificate Authority (CA).

Step 2: On-the-Fly Certificate Generation

When you try to access https://www.example.com:

1. The proxy intercepts your request.
2. It connects to the real example.com server and retrieves its legitimate certificate.
3. It instantly generates a fake certificate for example.com, signed by its own internal CA.
4. It presents this fake certificate to your browser.

[!TIP] Why Doesn't the Browser Block the Connection? Normally, faced with a fake certificate, your browser displays a big security alert. For the interception to be transparent, the proxy's CA certificate must be deployed and trusted on your machine (often via group policies in a corporate setting, or manually). This is why you can't do SSL Bumping discreetly on a stranger's network.

Step 3: Analysis in Plain Text

Once the two TLS tunnels are established (Client ↔ Proxy and Proxy ↔ Server), the proxy sees the HTTP requests passing through in plain text. It has access to the full URLs, headers, POST parameters, and response bodies. It can then apply its filtering or antivirus scanning rules.

Part 3: Hands-On Practice with Squid

To really understand the mechanism, nothing beats hands-on practice. I've prepared a test environment based on Squid, a widely used open-source proxy that handles SSL Bumping perfectly: squid-ssl-bumping-lab.

Lab Architecture

Quick Deployment

1. Clone the repository:

   git clone https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab
   cd squid-ssl-bumping-lab
   

2. Generate the lab's Certificate Authority:

   mkdir -p ssl
   openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 \
     -keyout ssl/squid-ca-key.pem \
     -out ssl/squid-ca-cert.pem \
     -subj "/CN=Squid CA/O=Mon Lab/C=FR"
   

3. Start the environment:

   docker-compose up --build -d
   

4. Configure your client:

   • Set the HTTP/HTTPS proxy to localhost:3128.
   • Import the ssl/squid-ca-cert.pem file into the trusted certificate authorities of your browser or your system.

[!WARNING] Security Warning This lab is intended for educational use. Never use this CA outside of this test environment, and remember to remove it from your system once you're done experimenting.

Observing the Interception

Once the configuration is complete, browse a few HTTPS sites and check Squid's logs:

docker-compose exec squid tail -f /var/log/squid/access.log

You'll notice that Squid logs the full URLs of the sites visited, proving that it does decrypt the traffic. If you click on the padlock in your browser, you'll see that the site's certificate is now issued by "Squid CA".

Part 4: Detection and Alternatives

How to Know If You're Being Intercepted?

If you're on a corporate network, it's very likely that your traffic is being inspected. To check:

1. Click on the padlock icon in your browser.
2. Display the certificate details.
3. Check the "Issuer" field. If it's the name of your company or a network device (like Fortinet, Palo Alto, Zscaler) instead of a recognized public authority (Let's Encrypt, DigiCert...), your traffic is being intercepted.

Some applications use Certificate Pinning: they hardcode the legitimate server's certificate fingerprint. If a proxy tries to present a fake certificate, the application will simply refuse to connect, making interception impossible.

The Alternative: SNI Filtering

SSL Bumping is heavy to manage and raises privacy concerns. A common alternative is filtering based on SNI (Server Name Indication).

When initializing the TLS connection, the client indicates in plain text, in the initial request, the domain name it wants to reach. The proxy can read this information without needing to decrypt the rest of the traffic. This allows blocking access to certain domains in a much less intrusive way, even though visibility into the full URL and page content is lost.

Part 5: Legal Issues and Best Practices

TLS interception is not a technical decision to be taken lightly. It involves access to potentially sensitive data (personal credentials, banking data, health information).

In a corporate setting, implementing SSL Bumping must be accompanied by strict rules:

• Transparency: Users must be informed that their professional traffic is being analyzed (generally via the IT charter).
• Exceptions (Bypass): It's essential to configure the proxy to not intercept certain categories of sites, particularly banking and healthcare services, in order to respect employees' privacy.
• CA Security: The private key of the internal certificate authority must be protected drastically. If it's compromised, an attacker could generate valid fake certificates across the entire IT fleet.

Conclusion

The padlock in your browser indicates that the connection is encrypted, but it doesn't guarantee that there's no one between you and the final server. SSL Bumping clearly illustrates the ongoing trade-off between a network's overall security and individual privacy.

It's a powerful and often indispensable technique in the corporate world, but one that requires rigorous and ethical implementation. Feel free to use the provided lab to experiment for yourself and better understand the underlying mechanisms of our daily connections.

---

Useful resources:

• 🧪 The Squid SSL Bumping lab
• 📖 Official Squid documentation on SSL Bump
• 🔐 OWASP recommendations on TLS inspection