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

Merge pull request 'chore/rewrite_ssl_bumping' (#23) from chore/rewrite_ssl_bumping into main

Browse Source 
Reviewed-on: #23
This commit was merged in pull request #23.
This commit is contained in:
Damien Arnodo
2026-06-07 10:36:00 +00:00
parent abb69fac66 7e6fe61de6
commit 0c6ae2d90e
4 changed files with 79 additions and 248 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.gitea/workflows/deploy.yml
View File

@@ -23,7 +23,7 @@ jobs:
- name: Install Hugo
run: |
wget https://github.com/gohugoio/hugo/releases/download/v0.152.2/hugo_extended_withdeploy_0.152.2_linux-amd64.deb -O /tmp/hugo.deb
wget https://github.com/gohugoio/hugo/releases/download/v0.162.1/hugo_extended_withdeploy_0.162.1_linux-amd64.deb -O /tmp/hugo.deb
dpkg -i /tmp/hugo.deb
- name: Checkout code

321
content/documentation/securité/ssl_bumping/ssl_bumping.md
View File

@@ -6,322 +6,153 @@ cascade:
type: docs
---
## Introduction : Quand le Cadenas Vert Devient Transparent 🔓🔍
## Introduction : Que se passe-t-il derrière le cadenas ?
Vous vous souvenez de notre fameux [**cadenas vert**](/documentation/securité/cadenas_vert/ssl/) dont on a parlé dans l'article précédent ? Cette petite icône qui nous rassure, qui nous dit "tout va bien, vos secrets sont en sécurité" ? Eh bien aujourd'hui, on va voir comment certains acteurs arrivent à **regarder à travers** ce cadenas ! 😱
L'icône du cadenas dans la barre d'adresse de votre navigateur est censée garantir que vos échanges sont chiffrés et illisibles par un tiers. Pourtant, dans de nombreux réseaux d'entreprise ou environnements scolaires, ce trafic est bel et bien analysé. Comment est-ce possible sans casser le chiffrement ?
Mais rassurez-vous, on ne va pas devenir des pirates ! On va explorer une technique légitime (mais controversée) appelée **SSL Bumping** ou **SSL/TLS Interception**. C'est un peu comme avoir des lunettes à rayons X pour voir ce qui se cache derrière le chiffrement HTTPS.
C'est là qu'intervient le **SSL Bumping** (ou interception TLS). Loin d'être une simple technique de piratage, c'est un mécanisme couramment utilisé et légitime pour inspecter le trafic HTTPS.
**Pourquoi c'est important ?** 🤔 Parce que cette technique est utilisée partout : dans les entreprises pour sécuriser leurs réseaux, dans les écoles pour filtrer le contenu, et même parfois... par des acteurs moins bien intentionnés. Comprendre comment ça fonctionne, c'est comprendre à la fois comment se protéger et comment protéger les autres.
Comprendre le SSL Bumping, c'est comprendre les limites du chiffrement de bout en bout dans certains contextes, et savoir comment les entreprises sécurisent (ou surveillent) leurs réseaux. Dans cet article, nous allons décortiquer le fonctionnement de cette technique et voir comment la mettre en place via un lab pratique : [squid-ssl-bumping-lab](https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab).
Prêts pour une plongée dans les coulisses du HTTPS ? On va décortiquer ensemble cette technique fascinante, et je vous montrerai même comment la mettre en pratique avec un lab que j'ai préparé : [squid-ssl-bumping-lab](https://github.com/darnodo/squid-ssl-bumping-lab) 🧪
## Partie 1 : Le concept de l'interception TLS
## Partie 1 : Le SSL Bumping, C'est Quoi au Juste ? 🎭
### Un "Man-in-the-Middle" assumé
### Le Principe : L'Homme du Milieu... Mais Gentil ! 👤
Le principe du HTTPS est comparable à l'envoi d'un courrier dans un coffre-fort dont seuls l'expéditeur et le destinataire ont la clé. Si un équipement réseau (comme un proxy d'entreprise) a besoin d'analyser le contenu pour bloquer un malware ou empêcher une fuite de données, il se retrouve face à un mur : le trafic est chiffré.
Imaginez cette scène : vous voulez envoyer une lettre secrète à votre ami(e). Normalement, vous la mettez dans une enveloppe scellée (le chiffrement HTTPS) et hop, direction la boîte aux lettres. Personne ne peut la lire en chemin, n'est-ce pas ?
Maintenant, imaginez que le facteur (disons, le proxy de votre entreprise) ait besoin de vérifier que vous n'envoyez pas de plans secrets de l'entreprise à la concurrence. Comment fait-il ? Il ne peut pas lire à travers l'enveloppe !
C'est là qu'intervient le **SSL Bumping** :
Le **SSL Bumping** contourne ce problème en s'insérant au milieu de la communication :
![SSL Bumping Expliqué](images/ssl_bumping_explique.fr.svg#center)
Le proxy va :
1. **Intercepter** votre connexion HTTPS
2. **Déchiffrer** votre trafic (comme ouvrir l'enveloppe)
3. **Analyser** le contenu
4. **Re-chiffrer** et transmettre au serveur final
1. **Intercepter** la connexion HTTPS du client.
2. **Déchiffrer** le trafic pour l'analyser.
3. **Re-chiffrer** les données avant de les envoyer au serveur final.
En gros, au lieu d'avoir **une** connexion sécurisée de bout en bout, vous en avez **deux** : une entre vous et le proxy, une autre entre le proxy et le serveur final. Le proxy peut voir tout ce qui passe !
Au lieu d'avoir une seule connexion sécurisée entre votre navigateur et le site web, il y en a deux : une entre vous et le proxy, et une autre entre le proxy et le site. Le proxy agit comme un relais qui lit tout au passage.
> [!NOTE] **Terminologie : SSL Bumping, HTTPS Interception, MITM... Késako ? 🤓**
>
> Ces termes désignent tous la même chose :
> - **SSL Bumping** : Le terme historique utilisé par Squid (un proxy populaire)
> - **TLS Interception** : La version moderne (on utilise TLS, pas SSL)
> - **HTTPS Inspection** : Le terme "corporate-friendly"
> - **MITM (Man-In-The-Middle)** : Le terme technique général
>
> Dans cet article, j'utiliserai principalement "SSL Bumping" par habitude, mais c'est bien de TLS qu'on parle !
> [!NOTE] **Question de vocabulaire**
> On parle souvent de **SSL Bumping** (le terme historique utilisé par le proxy Squid), d'**interception TLS** (le terme techniquement exact aujourd'hui), ou d'**inspection HTTPS**. Dans tous les cas, il s'agit d'une attaque de type *Man-In-The-Middle* (MITM), mais réalisée de manière contrôlée et volontaire par l'administrateur du réseau.
### Pourquoi Faire Ça ? Les Cas d'Usage Légitimes 🏢
### Pourquoi inspecter le trafic chiffré ?
Avant de crier au scandale, sachez que le SSL Bumping a des utilisations parfaitement légitimes :
L'interception TLS répond à des besoins réels, principalement dans le monde professionnel :
1. **Sécurité d'Entreprise 🛡️**
- Détecter les malwares qui se cachent dans le trafic HTTPS
- Empêcher les fuites de données sensibles
- Bloquer l'accès à des sites malveillants
1. **Sécurité réseau** : Détecter les malwares téléchargés via HTTPS ou bloquer l'accès à des sites malveillants.
2. **Prévention des fuites de données (DLP)** : S'assurer que des informations confidentielles ne sortent pas de l'entreprise.
3. **Filtrage et conformité** : Bloquer certains contenus (réseaux sociaux, sites inappropriés) selon la politique de l'entreprise ou de l'établissement.
4. **Débogage** : Analyser les requêtes API ou diagnostiquer des problèmes applicatifs complexes.
2. **Conformité et Contrôle 📋**
- Respecter les réglementations (certains secteurs doivent tout archiver)
- Filtrer le contenu inapproprié dans les écoles
- Optimiser la bande passante en cachant le contenu
Bien sûr, cette visibilité totale implique une grande responsabilité, car le proxy a accès aux mots de passe, aux cookies de session et aux données personnelles.
3. **Débogage et Développement 🐛**
- Analyser les API de vos applications
- Debugger les problèmes de connexion
- Tester la sécurité de vos services
## Partie 2 : Comment ça marche techniquement ?
> [!WARNING] **Attention : Avec de Grands Pouvoirs... 🚨**
>
> Le SSL Bumping est une technique **très puissante** qui peut être utilisée à mauvais escient :
> - Espionnage des employés
> - Vol d'identifiants et de données personnelles
> - Violation de la vie privée
>
> Son utilisation doit **toujours** être transparente, légale et éthique !
Pour s'insérer dans une connexion HTTPS sans que le navigateur ne bloque l'accès, le proxy doit réaliser un tour de passe-passe cryptographique.
## Partie 2 : Comment Ça Marche Techniquement ? 🔧⚙️
### Étape 1 : Le proxy devient une Autorité de Certification (CA)
Bon, assez de théorie ! Rentrons dans le vif du sujet. Comment un proxy arrive-t-il à se faire passer pour le serveur légitime sans que votre navigateur ne crie au loup ? C'est toute une chorégraphie !
Pour que le SSL Bumping fonctionne, le proxy doit être capable de générer des certificats à la volée pour n'importe quel site web. Pour cela, l'administrateur configure le proxy avec sa propre Autorité de Certification (CA) interne.
### Étape 1 : La Fausse Identité 🎭
### Étape 2 : La génération des certificats à la volée
Pour que le SSL Bumping fonctionne, le proxy doit pouvoir **créer de faux certificats** à la volée. Comment ? Il devient sa propre Autorité de Certification (CA) !
Lorsque vous tentez d'accéder à `https://www.example.com` :
Le proxy génère :
1. **Sa propre CA** avec une paire de clés (publique/privée)
2. **Un faux certificat** pour chaque site que vous visitez
3. Ce faux certificat est signé par sa CA "maison"
![Génération des faux certificats](images/generation_des_faux_certificats.fr.svg)
### Étape 2 : Le Tour de Passe-Passe 🎩✨
1. Le proxy intercepte votre requête.
2. Il se connecte au vrai serveur `example.com` et récupère son certificat légitime.
3. Il génère instantanément un **faux certificat** pour `example.com`, signé par sa propre CA interne.
4. Il présente ce faux certificat à votre navigateur.
Voici la danse complète quand vous visitez `https://www.example.com` :
> [!TIP] **Pourquoi le navigateur ne bloque-t-il pas la connexion ?**
> Normalement, face à un faux certificat, votre navigateur affiche une grosse alerte de sécurité. Pour que l'interception soit transparente, le certificat de la CA du proxy doit être **déployé et approuvé** sur votre machine (souvent via les stratégies de groupe en entreprise, ou manuellement). C'est pour cela que l'on ne peut pas faire du SSL Bumping discrètement sur le réseau d'un inconnu.
![SSL Bumping Expliqué](images/generation_des_faux_certificats.fr.svg)
### Étape 3 : L'analyse en clair
Le proxy joue un double jeu :
- Côté serveur : Il se fait passer pour un client normal
- Côté client : Il se fait passer pour le serveur !
Une fois les deux tunnels TLS établis (Client ↔ Proxy et Proxy ↔ Serveur), le proxy voit passer les requêtes HTTP en clair. Il a accès aux URL complètes, aux en-têtes, aux paramètres POST et au corps des réponses. Il peut alors appliquer ses règles de filtrage ou d'analyse antivirale.
> [!TIP] **Mais Attendez... Mon Navigateur N'est Pas Stupide ! 🤨**
>
> Exactement ! Normalement, votre navigateur devrait hurler "CERTIFICAT INVALIDE !"
> Pour que ça fonctionne, il faut que le certificat de la CA du proxy soit **installé comme CA de confiance** sur votre machine.
>
> C'est pourquoi :
> - Les entreprises installent leur CA sur tous les postes
> - Les antivirus vous demandent d'installer leur certificat
> - Vous devez faire super attention aux CA que vous installez !
## Partie 3 : Mise en pratique avec Squid
### Étape 3 : L'Analyse du Trafic 🔍
Pour bien comprendre le mécanisme, rien ne vaut la pratique. J'ai préparé un environnement de test basé sur Squid, un proxy open-source très utilisé qui gère parfaitement le SSL Bumping : [squid-ssl-bumping-lab](https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab).
Une fois le tunnel établi, le proxy peut voir **tout** :
### Architecture du lab
- Les URL complètes (pas juste le domaine)
- Les données POST (formulaires, mots de passe...)
- Les cookies et tokens d'authentification
- Le contenu des pages
- Les fichiers téléchargés
![Architecture du lab SSL](images/architecture_du_lab_ssl.fr.svg)
Il peut alors :
- **Logger** tout pour analyse ultérieure
- **Bloquer** certains contenus
- **Modifier** les requêtes/réponses (dangereux !)
- **Scanner** pour des malwares
### Déploiement rapide
## Partie 3 : Mise en Pratique avec Squid 🦑
Assez parlé, passons à la pratique ! J'ai créé un lab complet pour que vous puissiez tester le SSL Bumping dans un environnement contrôlé : [squid-ssl-bumping-lab](https://github.com/darnodo/squid-ssl-bumping-lab).
### Qu'est-ce que Squid ? 🦑
Squid est un proxy cache très populaire qui supporte le SSL Bumping. C'est l'outil parfait pour notre expérimentation !
### Architecture du Lab 🏗️
![SSL Bumping Expliqué](images/architecture_du_lab_ssl.fr.svg)
### Installation Rapide 🚀
1. **Clonez le repository** :
1. **Clonez le dépôt** :
```bash
git clone https://github.com/darnodo/squid-ssl-bumping-lab
git clone https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab
cd squid-ssl-bumping-lab
```
2. **Générez votre CA** (ou utilisez une existante) :
2. **Générez l'Autorité de Certification du lab** :
```bash
# Créer le dossier ssl/
mkdir -p ssl
# Générer une CA auto-signée
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. **Lancez le lab** :
3. **Lancez l'environnement** :
```bash
# Sans export de logs
docker-compose up --build -d
# Ou avec Fluent Bit pour exporter les logs
docker-compose --profile logging up --build -d
```
4. **Configurez votre navigateur** :
- Proxy HTTP/HTTPS : `localhost:3128`
- Importez `ssl/squid-ca-cert.pem` comme CA de confiance
4. **Configurez votre client** :
- Définissez le proxy HTTP/HTTPS sur `localhost:3128`.
- Importez le fichier `ssl/squid-ca-cert.pem` dans les autorités de certification de confiance de votre navigateur ou de votre système.
> [!WARNING] **Lab Only ! Ne Faites Jamais Ça en Production ! 🚫**
>
> Ce lab est **uniquement** pour l'apprentissage !
> - N'utilisez JAMAIS cette CA en dehors du lab
> - Ne faites pas de SSL Bumping sans autorisation explicite
> - Supprimez la CA de votre système après les tests
> [!WARNING] **Avertissement de sécurité**
> Ce lab est destiné à un usage éducatif. N'utilisez jamais cette CA en dehors de cet environnement de test et pensez à la supprimer de votre système une fois vos essais terminés.
### Ce Que Vous Verrez 👀
### Observer l'interception
Une fois configuré, visitez n'importe quel site HTTPS et regardez les logs :
Une fois la configuration terminée, naviguez sur quelques sites en HTTPS et consultez les logs de Squid :
```bash
# Voir les logs en temps réel
docker-compose exec squid tail -f /var/log/squid/access.log
```
Vous verrez quelque chose comme :
```
1719151234.567 342 192.168.1.100 TCP_MISS/200 15234 GET https://www.example.com/api/data - HIER_DIRECT/93.184.216.34
```
Vous constaterez que Squid enregistre les URL complètes des sites visités, prouvant qu'il déchiffre bien le trafic. Si vous cliquez sur le cadenas dans votre navigateur, vous verrez que le certificat du site est désormais émis par "Squid CA".
Magie ! Vous voyez l'URL **complète** même en HTTPS ! 🎉
## Partie 4 : Détection et alternatives
### Analyser les Certificats 🔍
### Comment savoir si l'on est intercepté ?
Pour voir le faux certificat en action :
1. Visitez un site HTTPS via le proxy
2. Cliquez sur le cadenas dans votre navigateur
3. Regardez les détails du certificat
4. Surprise ! Il est signé par "Squid CA" et non par la vraie CA !
Si vous êtes sur un réseau d'entreprise, il est très probable que votre trafic soit inspecté. Pour le vérifier :
1. Cliquez sur l'icône du cadenas dans votre navigateur.
2. Affichez les détails du certificat.
3. Vérifiez le champ "Émetteur" (Issuer). S'il s'agit du nom de votre entreprise ou d'un équipement réseau (comme Fortinet, Palo Alto, Zscaler) au lieu d'une autorité publique reconnue (Let's Encrypt, DigiCert...), votre trafic est intercepté.
## Partie 4 : Se Protéger du SSL Bumping 🛡️
Certaines applications utilisent le **Certificate Pinning** : elles intègrent en dur l'empreinte du certificat légitime du serveur. Si un proxy tente de présenter un faux certificat, l'application refusera simplement de se connecter, rendant l'interception impossible.
Maintenant qu'on sait comment ça marche, comment s'en protéger ? Ou du moins, comment le détecter ?
### L'alternative : le filtrage SNI
### Pour les Utilisateurs : Les Signaux d'Alerte 🚨
Le SSL Bumping est lourd à gérer et pose des questions de confidentialité. Une alternative courante est le filtrage basé sur le **SNI (Server Name Indication)**.
1. **Vérifiez les Certificats** 📜
- Cliquez sur le cadenas et examinez le certificat
- L'émetteur devrait être une CA connue (Let's Encrypt, DigiCert...)
- Méfiez-vous des CA d'entreprise ou inconnues
Lors de l'initialisation de la connexion TLS, le client indique le nom de domaine qu'il souhaite joindre en clair dans la requête initiale. Le proxy peut lire cette information sans avoir besoin de déchiffrer la suite du trafic. Cela permet de bloquer l'accès à certains domaines de manière beaucoup moins intrusive, même si l'on perd la visibilité sur l'URL complète et le contenu de la page.
2. **Certificate Pinning** 📌
- Certaines applis vérifient que le certificat est EXACTEMENT celui attendu
- Si c'est différent = refus de connexion
- Les apps bancaires utilisent souvent cette technique
## Partie 5 : Enjeux légaux et bonnes pratiques
> [!TIP] **Le Test Ultime : Comparez les Empreintes ! 🔬**
>
> 1. Notez l'empreinte (fingerprint) SHA-256 du certificat depuis votre réseau
> 2. Comparez avec l'empreinte depuis un autre réseau (4G mobile par exemple)
> 3. Si elles sont différentes = SSL Bumping probable !
L'interception TLS n'est pas une décision technique à prendre à la légère. Elle implique d'avoir accès à des données potentiellement sensibles (identifiants personnels, données bancaires, informations de santé).
### Pour les Entreprises : Les Bonnes Pratiques 💼
En entreprise, la mise en place du SSL Bumping doit s'accompagner de règles strictes :
- **Transparence** : Les utilisateurs doivent être informés que leur trafic professionnel est analysé (généralement via la charte informatique).
- **Exceptions (Bypass)** : Il est indispensable de configurer le proxy pour ne pas intercepter certaines catégories de sites, notamment les banques et les services de santé, afin de respecter la vie privée des collaborateurs.
- **Sécurité de la CA** : La clé privée de l'autorité de certification interne doit être protégée de manière drastique. Si elle est compromise, un attaquant pourrait générer de faux certificats valides sur tout le parc informatique.
Si vous DEVEZ utiliser le SSL Bumping :
## Conclusion
1. **Transparence Totale** 📢
- Informez clairement les utilisateurs
- Affichez une politique claire d'utilisation
- Respectez la législation locale
Le cadenas dans votre navigateur indique que la connexion est chiffrée, mais il ne garantit pas qu'il n'y a personne entre vous et le serveur final. Le SSL Bumping illustre bien le compromis permanent entre la sécurité globale d'un réseau et la confidentialité individuelle.
2. **Sécurité Maximale** 🔒
- Protégez la clé privée de votre CA comme un trésor
- Utilisez un HSM (Hardware Security Module) si possible
- Limitez la durée de vie des certificats
3. **Exceptions Nécessaires** ⛔
- Ne bumpez JAMAIS les sites bancaires
- Excluez les sites de santé
- Respectez la vie privée (messageries, etc.)
### L'Alternative : Le SNI Filtering 🎯
Plutôt que de déchiffrer, pourquoi ne pas simplement filtrer par nom de domaine ?
```
Client ──"Je veux example.com" (en clair)──> Proxy ──> Décision
↑
SNI Header
(Server Name Indication)
```
Le SNI permet de voir le domaine sans déchiffrer. C'est moins intrusif mais aussi moins précis (on ne voit que le domaine, pas l'URL complète).
## Partie 5 : L'Éthique et la Légalité ⚖️
### Les Questions Éthiques 🤔
Le SSL Bumping soulève des questions profondes :
1. **Vie Privée vs Sécurité** 🔐 vs 👁️
- Où placer le curseur ?
- La sécurité justifie-t-elle tout ?
- Quid du consentement éclairé ?
2. **Confiance Brisée** 💔
- HTTPS promettait du "bout en bout"
- Le SSL Bumping brise cette promesse
- Impact sur la confiance numérique globale
3. **Pente Glissante** 🎿
- Commencer par la sécurité...
- Finir par la surveillance ?
- Qui surveille les surveillants ?
### Le Cadre Légal 📜
Le SSL Bumping n'est pas illégal en soi, MAIS :
- **Consentement** : Les utilisateurs doivent être informés
- **Proportionnalité** : L'usage doit être justifié
- **Protection des données** : RGPD et autres réglementations s'appliquent
- **Contexte** : Entreprise ≠ Café public ≠ Domicile
> [!WARNING] **Rappel Important : La Légalité Varie ! 🌍**
>
> Les lois diffèrent selon les pays et les contextes :
> - En entreprise : Généralement OK avec information
> - Dans le public : Très réglementé voire interdit
> - À la maison : Complexe (enfants, invités...)
>
> Consultez toujours un juriste avant déploiement !
## Conclusion : Le Cadenas Vert a-t-il Encore un Sens ? 🔒❓
Alors, après tout ça, que penser de notre petit cadenas vert ? Est-il devenu obsolète ? Pas du tout !
Le SSL Bumping nous rappelle que :
1. **La Sécurité est Relative** 🎭
- Aucune technologie n'est infaillible
- Le contexte est crucial
- La vigilance reste de mise
2. **La Technologie est Neutre** ⚖️
- SSL Bumping peut protéger ou espionner
- L'intention fait la différence
- L'éthique guide l'usage
3. **L'Éducation est Essentielle** 📚
- Comprendre pour mieux se protéger
- Démystifier pour mieux décider
- Partager pour progresser ensemble
Le cadenas vert reste un excellent indicateur de sécurité. Mais comme toute technologie, il a ses limites. Le SSL Bumping nous montre qu'entre vous et le serveur, il peut y avoir des intermédiaires... parfois légitimes, parfois moins.
**Mon conseil ?** Restez curieux, restez vigilants, et n'hésitez pas à expérimenter (dans un lab, bien sûr !). La sécurité informatique est un domaine fascinant où l'attaque et la défense s'enrichissent mutuellement.
C'est une technique puissante et souvent indispensable en entreprise, mais qui exige une mise en œuvre rigoureuse et éthique. N'hésitez pas à utiliser le lab fourni pour expérimenter par vous-même et mieux comprendre les mécanismes sous-jacents de nos connexions quotidiennes.
---
**Ressources pour aller plus loin :**
- 🧪 [Mon Lab SSL Bumping](https://github.com/darnodo/squid-ssl-bumping-lab)
- 📖 [Documentation Squid SSL Bump](http://www.squid-cache.org/Doc/config/ssl_bump/)
- 🔐 [OWASP sur l'Inspection TLS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)
*Stay safe, stay curious!* 🚀🔒
**Ressources utiles :**
- 🧪 [Le lab Squid SSL Bumping](https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab)
- 📖 [Documentation officielle Squid sur le SSL Bump](http://www.squid-cache.org/Doc/config/ssl_bump/)
- 🔐 [Recommandations de l'OWASP sur l'inspection TLS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)

2
hugo.yaml
View File

@@ -3,7 +3,7 @@ title: 🧑‍💻 Notebook
theme: hextra
defaultContentLanguage: fr
languageCode: fr
locale: fr
menu:
main:

2
themes/hextra

Submodule themes/hextra updated: 3551a56b8c...fb994d6b1c