Guillaume-Sanchez
230 lines
11 KiB
Markdown
230 lines
11 KiB
Markdown
Preparation partielle RSX 112 de cette apres midi, 3 partie, une partie question de cours sur 6 points, une partie etude de cas sur 6 points et une partie Projet sur 8 point le tout sur feuille avec droit au PC. Petit rappel de snotion : principe de Kerckoffs, une etrenrpuse utilis eun algorithme créer en interne, quels sont les rsiques ? reponses attendue : validation du principe de Kerckoffs, pas d'audit externe possible, failles potentielles non detecter, fausse impression de sécurité fonctions de Hachage, il peut y avoir 2 resultats identiques mais avec 2 entréer différentes ( exemple birthday attack )
|
||
|
||
Algorithme de Hachage : SHA-256/512 c'est quoi le Hachage : il sert a quoi ? a verifier les sources, verifie l'intégriter. Comment on verifie cette intégrité sur un fihcier ? truc de base : parité il vas y avoir du PKI !!!!!!!
|
||
|
||
architecture PKI et tout Comment on certifie, comment on vérifie l'intégrité une machine genere des certificats et sont envoyé sur cahque UT qui en as besoin UT ou service d'ailleurs : DONC y a un echange de certificats entrre UT et serveur pour pouvoir ensuite valider le certificats et autorisé l'UT Vzlidaton de certificat : verifier la chaine, verifier les dates, verifier le domaine, verifier la revocation procédure renouvelle de certificat on aura des certificat a analyser on va faire une lecture a plat de l'infra pour le partielle Dernier sujet le plus important !!!!! architecture PKI pour SecureTech ( fictif j'imagine ) 200 employés 5 serveur web Je vais t'envoyer le PDF du prof qui recapitule tout, j'ai pass besoi d'une fiche de triche ou de revision Je veux que tu te prepare comme si tu allais le passer, comme sa dans l'aprem quand je vien te demander les réponses aux question tu es deja au courant,
|
||
2/2
|
||
ChatGPT a dit :
|
||
Parfait, je me prépare comme si j’étais à ta place pour le partiel RSX112 cet après-midi. Je vais me faire une fiche mentale rapide pour répondre efficacement à toutes les questions, que ce soit théorie, étude de cas ou projet PKI. Dès que tu m’envoies le PDF du prof, je l’intègre aussi dans ma révision interne. Voici déjà ce que j’ai en tête prêt à l’usage :
|
||
🔐 1. Notions théoriques (6 points)
|
||
🔸 Principe de Kerckhoffs
|
||
Un système de chiffrement doit rester sécurisé même si tout est connu… sauf la clé.
|
||
❌ Problème d’un algo interne :
|
||
Aucune revue externe → risques non détectés
|
||
Sécurité par l’obscurité ≠ vraie sécurité
|
||
⚠️ Fausse impression de sécurité
|
||
🔸 Fonctions de Hachage
|
||
Un algorithme qui produit une empreinte unique à partir d’une donnée.
|
||
Utilisation :
|
||
Vérifier l’intégrité des fichiers
|
||
Signature numérique
|
||
Authentification
|
||
Propriétés importantes :
|
||
Déterministe
|
||
Résistant aux collisions (mais… ⚠️ Birthday attack)
|
||
Non réversible
|
||
Exemples : SHA-256, SHA-512
|
||
🔍 Vérification d'intégrité :
|
||
Hash avant/après transfert
|
||
Vérification automatique par outils (ex : checksum md5sum, sha256sum)
|
||
⚠️ Parité est un exemple simple mais insuffisant pour sécurité réelle
|
||
🧾 2. Étude de cas (6 points)
|
||
⚙️ Exemple de certificat à analyser
|
||
Vérifier :
|
||
🔗 Chaîne de certification (ex. CA → intermediate → serveur)
|
||
📅 Validité (dates NotBefore / NotAfter)
|
||
🌐 Nom de domaine (CN, SAN)
|
||
❌ Révocation : CRL / OCSP
|
||
🔁 Renouvellement d’un certificat
|
||
Générer nouveau CSR
|
||
Signer par CA
|
||
Mettre à jour sur les serveurs/clients
|
||
⚠️ Attention aux interruptions de service si certif expiré
|
||
🏢 3. Projet : Architecture PKI pour SecureTech (8 points)
|
||
Contexte :
|
||
Entreprise de 200 employés
|
||
5 serveurs web
|
||
📐 Proposition d’architecture PKI :
|
||
```
|
||
luaCopierModifier +--------------------+ | Root CA | (offline)
|
||
+---------+----------+ |
|
||
+---------v----------+ | Intermediate CA | (sign les certifs)
|
||
+----+----------+----+ | |
|
||
+------------------+ +------------------+ | |
|
||
+---------v---------+ +---------v---------+ | Web Server 1 | ... | Web Server 5 |
|
||
+------------------+ +------------------+
|
||
+-----------------+ | Employé poste 1 | → Certificat utilisateur
|
||
+-----------------+
|
||
```
|
||
|
||
🔒 Composants :
|
||
Root CA : autorité racine, stockée offline
|
||
Intermediate CA : en ligne, signe les certificats (web, employés)
|
||
Serveurs web : utilisent TLS (HTTPS)
|
||
Utilisateurs :
|
||
Certificat personnel
|
||
Authentification forte possible
|
||
Chiffrement des e-mails
|
||
🔄 Procédures :
|
||
Délivrance : CSR → Intermediate CA
|
||
Stockage clés privées sécurisé (HSM recommandé)
|
||
Revocation : liste CRL + OCSP
|
||
Renouvellement : automatisé (via certbot ou outil interne)
|
||
Quand tu veux, tu me balances les questions du partiel, ou même juste des extraits du sujet ou du PDF du prof. Je serai prêt à dégainer.
|
||
💻 Tu peux aussi me demander de te faire un schéma si besoin pour la PKI ou pour expliquer une vérif de certificat !
|
||
|
||
Vous avez dit :
|
||
|
||
RSX112-Securite-des-Reseaux.pdf
|
||
PDF
|
||
voila le fichier
|
||
|
||
ChatGPT a dit :
|
||
|
||
Merci pour le fichier, je l’ai entièrement lu et intégré. Voici un récap express de tout ce que je garde en tête, prêt à te répondre cet après-midi. Je me suis mis en mode "partiel RSX112 activé" :
|
||
🧠 STRUCTURE MÉMO TECH (RSX112) – 100% PRÊT POUR TON EXAM
|
||
🔹 Partie 1 – Questions Théoriques (6 pts)
|
||
✅ Principe de Kerckhoffs
|
||
La sécurité ne repose que sur la clé, pas l’algorithme.
|
||
Si algo interne secret → ❌ : pas d’audit, failles invisibles, sécurité illusoire.
|
||
✅ Fonction de Hachage
|
||
Unidirectionnelle, résiste aux collisions (birthday attack).
|
||
SHA-256 / SHA-3 = 🔒 sécurisé
|
||
MD5 / SHA-1 = ❌ obsolètes
|
||
Utilités :
|
||
Signature numérique
|
||
Intégrité des fichiers
|
||
Authentification
|
||
✅ Hash ≠ chiffrement
|
||
Le hash ne se déchiffre pas.
|
||
⚠️ Fréquente confusion à éviter à l’oral/écrit.
|
||
🔹 Partie 2 – Étude de Cas Pratique (6 pts)
|
||
🔍 Analyser un certificat X.509
|
||
CA:FALSE → Certif final
|
||
Key Usage: digitalSignature, keyEncipherment
|
||
Extended Usage: TLS Web Server Auth
|
||
SAN : plusieurs domaines
|
||
🔎 Vérifications à faire :
|
||
🔗 Chaîne valide (Root → Intermédiaire → Certif)
|
||
|
||
📅 Dates OK ?
|
||
🌍 Domaine correspond ?
|
||
❌ Révocation ? (CRL / OCSP)
|
||
✍️ Signature valide ?
|
||
🛠️ Commandes OpenSSL
|
||
|
||
Lire : openssl x509 -in cert.pem -text -noout
|
||
Générer clé : openssl genrsa -out key.pem 2048
|
||
CSR : openssl req -new -key key.pem -out csr.pem
|
||
Signer : openssl x509 -req ...
|
||
🔹 Partie 3 – Projet PKI SecureTech (8 pts)
|
||
📋 Contexte
|
||
200 employés
|
||
5 serveurs web
|
||
Email S/MIME, VPN, signature code
|
||
🧱 Architecture PKI proposée
|
||
```
|
||
scssCopierModifier[Root CA SecureTech] (offline, HSM, 20 ans)
|
||
│[Issuing CA] (10 ans, online)
|
||
├── [TLS CA] → 5 serveurs web (certif 1 an)
|
||
├── [User CA] → 200 employés (certif 2 ans)
|
||
├── [Code CA] → Signature de code (certif 3 ans)
|
||
└── [Device CA] → VPN ou devices internes
|
||
```
|
||
|
||
🔐 Sécurisation Root CA
|
||
Hors ligne, HSM, salle sécurisée, backups en coffre, cérémonie de clé (3 pers.)
|
||
♻️ Renouvellement Certificat
|
||
Nouvelle paire de clés (recommandé)
|
||
CSR → CA
|
||
Installation et test AVANT expiration
|
||
⚠️ Automatiser (Let’s Encrypt pour les web par ex.)
|
||
⚠️ À ne pas oublier
|
||
CRL ≠ OCSP → vérifier statut de révocation
|
||
Signature ≠ chiffrement
|
||
PKI = 20% technique, 80% process (orga, contrôle, doc, audits…)
|
||
💡 CONSEILS POUR L’EXAM
|
||
⚠️ Ne JAMAIS mélanger signature et chiffrement
|
||
Répondre avec définitions claires + explications + exemples concrets
|
||
Exemples attendus : certif TLS avec SAN, SHA-256 vs SHA-1, rôle Root/Intermédiaire, CRL vs OCSP
|
||
Tu peux venir dans l’après-midi me balancer les questions de ton sujet comme tu veux, je suis chargé à bloc pour te répondre vite et bien.
|
||
👊 Bonne chance et reviens vite me tester
|
||
|
||
b) Vérification de la chaîne de confiance
|
||
Le navigateur vérifie que le certificat du site peut être reliée à une autorité de certification racine (CA) de confiance :
|
||
|
||
Le navigateur commence par le certificat du site.
|
||
|
||
Il remonte la chaîne des certificats intermédiaires.
|
||
|
||
Il cherche une autorité racine dans sa liste de CAs de confiance intégrée.
|
||
|
||
👉 Si la chaîne est incomplète ou si un certificat est invalide, la validation échoue.
|
||
|
||
🔹 c) Validation de la signature
|
||
Pour chaque certificat de la chaîne :
|
||
|
||
Le navigateur vérifie la signature numérique faite par le certificat supérieur.
|
||
|
||
Cela garantit que chaque certificat a bien été émis par une autorité de confiance.
|
||
|
||
🔹 d) Vérification de la validité temporelle
|
||
Chaque certificat a :
|
||
|
||
Une date de début de validité
|
||
|
||
Une date d’expiration
|
||
|
||
Le navigateur vérifie que la date actuelle est comprise dans cette période.
|
||
|
||
🔹 e) Vérification du nom de domaine
|
||
Le champ CN (Common Name) ou SAN (Subject Alternative Name) du certificat doit correspondre exactement au nom du site web demandé (ex. example.com).
|
||
|
||
🔹 f) Révocation du certificat
|
||
Le navigateur vérifie que le certificat n’a pas été révoqué à l’aide de :
|
||
|
||
CRL (Certificate Revocation List) : liste de certificats révoqués.
|
||
|
||
OCSP (Online Certificate Status Protocol) : vérification en ligne du statut.
|
||
|
||
(Parfois cette étape est ignorée ou désactivée pour des raisons de performance ou confidentialité.)
|
||
|
||
✅ Si tout est valide...
|
||
Le navigateur :
|
||
|
||
Affiche un cadenas 🔒 dans la barre d'adresse
|
||
|
||
Et établit une connexion HTTPS sécurisée (via le protocole TLS)
|
||
|
||
❌ Si une erreur est détectée...
|
||
Le navigateur affiche une alerte de sécurité (ex. : certificat expiré, auto-signé, domaine non valide, etc.) et empêche l'accès au site, sauf si l'utilisateur décide de continuer (déconseillé).
|
||
|
||
📌 Résumé visuel du processus :
|
||
🔄 Le serveur envoie le certificat + chaîne
|
||
|
||
🔐 Le navigateur vérifie la signature
|
||
|
||
⏰ Il vérifie les dates de validité
|
||
|
||
🌐 Il vérifie que le domaine correspond
|
||
|
||
🚫 Il vérifie la révocation
|
||
|
||
✅ Si tout va bien, il affiche 🔒 et établit TLS
|
||
|
||
```
|
||
[Root CA - SecureTech]
|
||
(Offline | HSM | 20 ans)
|
||
│
|
||
┌────────────────┴────────────────┐
|
||
│ │
|
||
[Issuing CA - TLS] [Issuing CA - Divers]
|
||
(Online | 10 ans) (Online | 10 ans)
|
||
│ │
|
||
┌────────┼────────┐ ┌───────────┼───────────┐
|
||
│ │ │ │ │ │
|
||
[TLS CA] [User CA] [Code CA] [Device CA] ...autres ...
|
||
(5 ans) (5 ans) (5 ans) (5 ans)
|
||
|
||
```
|