Damien/Notebook
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Add bilingual French/English support with Hugo multilingual config

Browse Source 
Configure Hugo multilingual mode (fr default, en secondary) with
Hextra's language-switch menu entry, and translate all existing
content pages to English using Hugo's per-file language suffix
convention (.en.md alongside .fr.md).
This commit is contained in:
Damien
2026-07-18 09:48:18 +02:00
parent a4cffd8916
commit f49c0f45dd
20 changed files with 2706 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
content/documentation/securité/_index.en.md Normal file
View File

@@ -0,0 +1,14 @@
---
title: "Security"
sidebar:
open: true
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< cards >}}
{{< card link="/en/documentation/securité/cadenas_vert/ssl/" title="SSL: Decoding the Green Padlock" subtitle="How HTTPS (SSL/TLS) works" icon="banknotes" >}}
{{< card link="/en/documentation/securité/ssl_bumping/ssl_bumping/" title="SSL Bumping" subtitle="How to analyze SSL traffic" icon="clever" >}}
{{< /cards >}}

194
content/documentation/securité/cadenas_vert/ssl.en.md Normal file
View File

@@ -0,0 +1,194 @@
---
title: "SSL: Decoding the Green Padlock"
date: 2025-05-26T20:00:00+02:00
weight: 2
cascade:
type: docs
---
## Introduction: The Padlock, Your Trust Indicator 🕵️‍♂️✨
You've seen it thousands of times, haven't you? That little **green padlock** (or sometimes gray, depending on your browser and the site) that shows up next to a website's address in your navigation bar. You click on it, you look at it, you think "cool, it's secure," and you move on.
![Certificat](certificat.png)
But... do you really know what it means? 🤔 All the **mechanics that kick in** just so this little symbol appears? It's much more than a simple icon! It's the visible part of an iceberg. \
**So, what's our mission today? 🚀**
We're going to roll up our sleeves and analyze what happens "under the hood"! Promise: we'll explain **clearly, simply, and without indigestible jargon** what actually happens when this padlock appears. We'll dissect together how it helps us know whether we can trust a site and why it's absolutely **ESSENTIAL** for our "security".
Get ready, because you'll see that behind this little padlock hides a complex dance of certificates, secret keys, and handshakes... And by the end, you'll never look at this little symbol the same way again.
## Part 1: The SSL Certificate 💳
So, this famous SSL certificate, what exactly is it? Hang on tight, because it's the first piece of the puzzle!
### What is it? 🤔
Imagine the SSL certificate (or TLS, we'll get to that!) as the **official digital ID card of a website**. When you present it to the police 👮, it proves who you are. \
Well, for a website, it's the same thing!
Its role? To prove that the site you're visiting really is what it claims to be, and not an impostor 🥸. \
It's the first guarantee that you're not being fooled by a well-disguised phishing site.
> [!NOTE] **A Small Linguistic Note 🤓: SSL or TLS?**
>
> We often hear about "SSL certificate". In reality, SSL (Secure Sockets Layer) is the ancestor of the current protocol, which is called **TLS (Transport Layer Security)**. \
> But since "SSL" remained popular (a bit like calling any tissue a "Kleenex"), it's still widely used. \
> In this article, we'll juggle between "SSL certificate" and "TLS certificate", but know that we're really talking about the modern, secure technology!
### Who Issues It? The Certificate Authority (CA) 🏛️
But who makes and distributes these ID cards? These are the **Certificate Authorities (CA)**. \
Think of them as **"town halls"**.
Before giving you an ID card, your town hall checks who you are, right? Well, CAs do the same for websites! They make sure of the requester's identity before issuing this precious pass. Names like **Let's Encrypt**, **Sectigo**, or **DigiCert** ring a bell? These are examples of these trusted organizations.
And how does your browser (Chrome, Firefox, Safari...) know it can trust a CA? It's simple: it has a **pre-installed list of recognized and trusted CAs**. A bit like having the list of official town halls in the country! If the certificate is signed by a CA on this list, the browser says "OK, I know this one, I trust it".
> [!TIP] **Not All Padlocks Hide the Same Investigation 🕵️‍♀️**
> There are different "levels of scrutiny" before a CA issues a certificate. We talk about:
>
> * **DV (Domain Validation):** The most basic. The CA just checks that the requester really controls the domain name (like, "do you have the keys to `arnodo.fr`?"). It's fast and often free (thanks Let's Encrypt!).
> * **OV (Organization Validation):** Here, we step it up a notch. The CA verifies the legal existence of the organization requesting the certificate (company name, address...).
> * **EV (Extended Validation):** The top of the top in verification! The CA conducts a thorough investigation into the company's identity. In the past, this often resulted in the company name being displayed in green next to the padlock. Today, browsers tend to simplify this display, but the rigor of the verification remains.
> The little padlock will be there for all these types, but additional information about the organization may be visible by clicking on it for OV/EV certificates.
### What Does It Contain? 📜
Concretely, what do we find in this famous digital ID card? The essential information is:
* **The domain name concerned:** For example, `notebook.arnodo.fr`. This is crucial to make sure you're in the right place.
* **The name of the owning organization:** Especially visible and verified for OV and EV certificates. This gives you an idea of who's behind the site.
* **The server's public key:** 🔑 This is an ultra-important piece of code! We'll see its role in Part 2, but remember it's here, snugly stored in the certificate. It's a bit like the address of our mailbox.
* **The CA's digital signature:** This is the official stamp of the "town hall" (the CA) that proves the certificate is authentic and hasn't been modified or forged since it was issued.
* **The validity dates:** Like your driver's license or your passport, a certificate has a start date and an end date. An expired certificate is a big NO 🚩 for your browser!
### How Does Your Browser Verify It? ⏱️💨
All that's great, but how does your browser manage to verify all this in the blink of an eye (often in just a few milliseconds!) when you land on a site? It's a well-oiled little dance, a sort of express "check-up":
1. **Checking the CA's signature:** The browser looks at the signature affixed to the certificate. Thanks to its list of trusted CAs (and their own "public keys", which it knows), it can make sure the signature is authentic and that the certificate really comes from a recognized authority. It's like checking the seal on an official document.
2. **Not expired, please!:** It checks that the certificate hasn't expired yet (and that it's even already valid, if there's a start date in the future). An expired certificate is like showing a passport that's no longer valid: straight to the exit!
3. **Not on the blacklist (revocation):** The browser makes sure the certificate hasn't been revoked. "Revoked?" Yes, that means canceled before its expiration date. This can happen if, for example, the site got hacked and its private key (the server's secret, more on that soon) was compromised. The CA then publishes lists of canceled certificates (called CRL or via OCSP) that browsers consult.
4. **Right site, right certificate:** It checks that the domain name indicated in the certificate (for example `www.yourfavoritesite.com`) matches EXACTLY the site you're trying to reach. No cheating or identity fraud!
🏁 **The Verdict:**
* **If everything's OK 👍:** The little green padlock (or gray, depending on the browser) proudly displays itself! The connection is deemed safe, and you can browse, buy, or enter your information with a (relatively) peaceful mind.
* **If something's off 👎:** Your browser will sound the alarm! 🚨 You'll see a very visible warning message (something like "Your connection is not private", "Security alert", etc.).
> [!WARNING] **Red Alert!**
> A friendly tip: **NEVER ignore these warnings**, especially if you were planning to enter sensitive information (credentials, bank details...).
> It's often a sign that something shady is going on!
And that's it for the ID card! But this is only the beginning. Now that we know the site really is what it claims to be, how do we make sure our exchanges with it stay secret? That's where the magic of keys comes in... and that's the topic of our next part!
## Part 2: The Dance of the Keys 💃🔑
Alright, now we know the site really is what it claims to be thanks to its ID card (the SSL/TLS certificate, remember?). That's great, but it's not enough! If our exchanges with this site travel in plain text over the internet, any nosy person (or hacker 🏴‍☠️) could read them. Not great if you're sending your credit card number or your most secret passwords!
That's where the second phase of the magic kicks in: **data encryption**. And for that, we're going to witness a real "dance of the keys"!
### Introduction to the Magic: Asymmetric Cryptography
For our data to become illegible gibberish to others, we use a brilliant concept called **asymmetric cryptography**. What's that? It's the idea of having not one, but **two digital keys** that work together, like an inseparable duo:
1. **A Public Key:** 🌍 Imagine it as a **mailbox with a slot open to everyone**. It's shared openly with the whole world (it's even included in the site's SSL certificate, the one we saw in Part 1!). Anyone can use it to drop off a message (encrypted, of course).
2. **A Private Key:** 🤫 This one is the **server's treasure**. It's kept preciously and must NEVER be disclosed. It's the **ONLY key capable of opening the mailbox** and reading the messages that were encrypted with the corresponding public key.
In short: what's encrypted (locked) with the public key can ONLY be decrypted (unlocked) by the corresponding private key. And vice versa (although for our "handshake", it's mostly the first direction that interests us). Clever, isn't it?
### The Simplified SSL/TLS "Handshake"
Now that we have our keys, how do your browser and the server agree to talk secretly? Thanks to an initial negotiation, a sort of coded "handshake" called the **SSL/TLS Handshake**. Here are the steps, simplified so as not to give you a headache:
1. **Your Browser 💻:** "Hi Server! I'd like us to talk securely. Can you show me your ID card (your SSL/TLS certificate), please?"
2. **The Server 🖥️:** "No problem, friend! Here's my certificate. You'll find my famous **public key** (our `mailbox`) in it."
3. **Your Browser 💻:** (It examines the certificate from every angle, as we saw in Part 1: CA signature, expiration date, domain name, not revoked... In short, the full check-up!)
4. **If the certificate is valid and trustworthy ✅:**
* Your browser thinks: "OK, this guy is legit! Now, we need to find a secret code just for the two of us for the rest of the conversation."
* It then creates a small temporary secret piece of information, a sort of unique password for this session: this is the **session key**. (This is what's called a *symmetric* key, different from our public/private pair, because it's faster for encrypting large volumes of data).
* To send this session key to the server without anyone being able to see it, your browser will use the **server's public key** (the one it found in the certificate) to encrypt it. There, the session key is placed in a "secure envelope" that only the server will be able to open!
* It sends this encrypted session key to the server.
5. **The Server 🖥️:** It receives the secure envelope. How to open it? Easy! It uses its **private key** (the one it jealously keeps secret) to decrypt the session key sent by your browser. And since it's the only one with this private key... it's the only one who can read the session key!
6. **Mission Accomplished! 🎉** Magic! Your browser and the server now have **exactly the same secret session key**. No one else on the network knows it.
From this moment on, **all the data exchanged** between your browser and the server for the rest of your visit (the pages you load, the forms you submit, etc.) will be **encrypted and decrypted with this session key**. It's much faster to use this symmetric key for ongoing exchanges than to keep using the public/private key system (which is a bit heavier for large amounts of data).
The communication is now secure, encrypted end-to-end! 🔒 You can relax, your secrets are (normally) well kept!
## Part 3: Why Is All This Essential For You? 🛡️🌍
OK, we've seen the site's ID card (the certificate) and the secret dance of keys to encrypt our conversations (the SSL/TLS handshake). \
But concretely, why go through all this trouble?
### For You, as a User
When you browse a site proudly displaying this padlock (and thus using HTTPS), you benefit from several vital protections:
1. **Confidentiality 🤫: Your Secrets Well Kept!**
This is the most obvious benefit. Thanks to encryption (that famous session key we established), your sensitive information becomes undecipherable gibberish for anyone trying to spy on your connection.
* **Passwords?** Encrypted.
* **Credit card numbers during a purchase?** Encrypted.
* **Private messages on a forum or social network?** Encrypted.
Even if a hacker 🏴‍☠️ managed to intercept the data traveling between your computer and the site, they would only see a mush of incomprehensible characters. Your information stays private, away from prying eyes.
2. **Integrity ✅: What You See Is What You Should See!**
The HTTPS protocol also guarantees that the data you receive from the site (and what you send) has **not been modified or corrupted along the way** by a malicious third party.
3. **Authentication 🆔: You're Really Talking to the Right Counter!**
Thanks to the SSL/TLS certificate, you have much better assurance that you're communicating **with the legitimate site and not with a fraudulent clone**.
### For Website Owners 👑
If you have a website, setting up HTTPS is no longer a "nice-to-have", it has become a "must-have". Here's why:
1. **Building Trust (and Increasing Conversions!) 😊➡️💰**
The padlock immediately reassures your visitors. They see that you take their security seriously. This is absolutely crucial for e-commerce (who would want to enter their bank details on an unsecured site?), online banking services, or any site collecting the slightest bit of personal data. An unsecured site can scare visitors away before they've even explored your content, directly impacting your credibility and, potentially, your sales or your goals.
2. **Improving Search Engine Optimization (SEO) 📈: Google Loves Secure Sites!**
For several years now, Google and other search engines have **actively favored HTTPS sites** in their search results. Switching your site to HTTPS can therefore give you a little boost in the rankings. Conversely, not doing so could penalize you.
3. **Protecting Your Users (and Your Reputation!) 🛡️**
By securing exchanges, you protect your users against the theft of their personal data. Avoiding a data leak or identity theft that would originate from a security flaw on your site also means protecting your own reputation. Bad press on this subject can be devastating.
4. **Regulatory Compliance ⚖️: Sometimes, It's the Law!**
For certain activities and in certain regions (think GDPR in Europe, for example), securing the personal data collected and processed is a **legal obligation**. Failing to comply can result in heavy penalties. HTTPS is one of the fundamental building blocks of this compliance.
In short, this little padlock is a sign of respect toward your users, a mark of seriousness for your business, and a protection for everyone. Not bad for such a small icon, right? 😉
## Conclusion 🛡️✨
So, this little green (or gray) padlock we've dissected from every angle, it's ultimately much more than a simple graphic detail, isn't it? As we've seen, it's the **visible part of an ingenious and complex system** working hard behind the scenes.
To sum up our journey in a few words:
* It starts with a **digital ID card** (the SSL/TLS certificate) that assures us the site really is what it claims to be, issued by a trusted "web town hall" (the Certificate Authority).
* Then, there's a **cryptographic "dance of the keys"** (the public key to encrypt a secret, the private key to decrypt it) that allows your browser and the server to agree on a unique secret code (the session key).
* And all this, for what? To guarantee the **Confidentiality** (your data stays secret), the **Integrity** (it's not modified along the way), and the **Authentication** (you're really talking to the right site) of your exchanges on the web.
But be careful, the magic of TLS doesn't stop at your web browser's door! If the padlock is its best-known ambassador, this technology is actually the **silent guardian of many other aspects of our digital lives**:
* **Your emails 📧:** When you see protocols like SMTPS, IMAPS, or POP3S, it's TLS securing the sending and receiving of your messages.
* **Your mobile apps 📱:** Many of them use TLS to communicate securely with their servers, protecting the data they exchange.
* **VPNs (Virtual Private Networks) 🌐:** Some VPN protocols rely on TLS to create encrypted tunnels and secure your overall internet connection.
* **Instant messaging 💬:** Applications use similar mechanisms or directly TLS to encrypt your conversations.
* **And much more!** (Database connections, secured APIs, etc.)
In short, this padlock is the most visible manifestation of this **personal digital bodyguard** 🕵️‍♂️, but the TLS technology itself works in many other corners to protect your information.
**So, the final word?**
Get into the habit of **always checking for the presence of this padlock** (and hence "HTTPS" in the address) before entering any sensitive information or downloading anything on a website. Don't hesitate to **click on it for more information** if you have any doubt. And above all, be **extremely vigilant about security warning messages** that your browser might display. They're there for a good reason!
> [!NOTE]Key and Certificate File Formats
>
> You'll often encounter different file formats for keys and certificates. Here are the most common ones:
>
> * `.pem` (Privacy Enhanced Mail): This is a very widespread format that can contain server certificates, intermediate certificates, private keys, or even all of these at once. Its content is Base64-encoded, which makes it readable as text (you'll see lines like `-----BEGIN CERTIFICATE-----`).
> * `.crt` or `.cer` (Certificate): These files generally contain a certificate, most often the server's. They can be Base64-encoded (like `.pem`) or in binary DER format.
> * `.key` (Key): This file contains a key, and in the SSL/TLS context, it's almost always the server's private key. It's crucial and must be kept secret. It's often in PEM format.
> * `.csr` (Certificate Signing Request): This is not a certificate, but a certificate request. It's the file you generate and send to a Certificate Authority (CA). It contains your public key and the information you want to appear in your certificate.
> * `.p12` or `.pfx` (PKCS#12): This is a package format that can contain certificates (public), intermediate certificates, and the private key (password-protected) in a single binary file. It's often used to import/export certificates and keys on Windows or macOS.
>
> Understanding these extensions will help you better manage files when configuring SSL/TLS on a server.

158
content/documentation/securité/ssl_bumping/ssl_bumping.en.md Normal file
View File

@@ -0,0 +1,158 @@
---
title: "SSL Bumping: How to Analyze SSL Traffic"
date: 2025-06-22T20:00:00+02:00
weight: 3
cascade:
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](https://gitea.arnodo.fr/Damien/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:
![SSL Bumping Expliqué](images/ssl_bumping_explique.fr.svg#center)
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`:
![Génération des faux certificats](images/generation_des_faux_certificats.fr.svg)
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](https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab).
### Lab Architecture
![Architecture du lab SSL](images/architecture_du_lab_ssl.fr.svg)
### Quick Deployment
1. **Clone the repository**:
```bash
git clone https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab
cd squid-ssl-bumping-lab
```
2. **Generate the lab's Certificate Authority**:
```bash
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**:
```bash
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:
```bash
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](https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab)
- 📖 [Official Squid documentation on SSL Bump](http://www.squid-cache.org/Doc/config/ssl_bump/)
- 🔐 [OWASP recommendations on TLS inspection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)