# Algorithmes asymétriques
RSA          : le plus répandu historiquement, clés >= 2048 bits (idéalement 3072/4096)
ECC (Elliptic Curve) : équivalent de sécurité avec des clés bien plus courtes (ex: P-256, Curve25519)
Ed25519      : signature basée sur courbe elliptique, rapide et sûre, standard moderne

# Génération d'une paire de clés Ed25519 et signature d'un message
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey
from cryptography.hazmat.primitives import serialization

private_key = Ed25519PrivateKey.generate()
public_key = private_key.public_key()

message = b"licence-technologik-v1;user=42;exp=2026-12-31"
signature = private_key.sign(message)

# Vérification côté client/serveur distant, avec seulement la clé PUBLIQUE
try:
    public_key.verify(signature, message)
    print("signature valide, message authentique")
except Exception:
    print("signature invalide, message altéré ou forgé")

# Chiffrement hybride : RSA/ECC pour échanger une clé de session, puis AES pour les données
# (l'asymétrique est trop lent pour chiffrer de gros volumes directement)
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes

private_key = rsa.generate_private_key(public_exponent=65537, key_size=3072)
public_key = private_key.public_key()

session_key = os.urandom(32)  # clé AES-256 générée aléatoirement

encrypted_session_key = public_key.encrypt(
    session_key,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None),
)
# encrypted_session_key est envoyé au destinataire, seule sa clé privée peut le déchiffrer
# les données volumineuses sont ensuite chiffrées avec session_key en AES-GCM (voir leçon précédente)

# Handshake TLS 1.3 simplifié
1. ClientHello  : le client propose les suites cryptographiques supportées + son paramètre de clé éphémère
2. ServerHello  : le serveur choisit la suite, envoie son certificat + sa clé éphémère
3. Le client vérifie le certificat (chaîne de confiance jusqu'à une autorité de certification racine)
4. Les deux parties dérivent une clé de session partagée (Diffie-Hellman éphémère -> forward secrecy)
5. Toute la suite de la communication est chiffrée avec cette clé de session (AES-GCM ou ChaCha20-Poly1305)

# TLS 1.3 vs 1.2 : handshake réduit à 1 aller-retour (0-RTT possible), suites faibles supprimées

# Générer un certificat auto-signé pour un environnement de lab/dev (JAMAIS en production publique)
openssl req -x509 -newkey rsa:4096 -keyout lab-key.pem -out lab-cert.pem -days 365 -nodes   -subj "/CN=lab.technologik.local"

# Inspecter un certificat existant (chaîne, validité, algorithme de signature)
openssl x509 -in lab-cert.pem -noout -text | head -30

# Tester la configuration TLS d'un serveur (suites supportées, versions de protocole)
nmap --script ssl-enum-ciphers -p 443 lab.technologik.local
openssl s_client -connect lab.technologik.local:443 -tls1_2

# Configuration nginx durcie pour TLS (à adapter selon les recommandations Mozilla SSL Config Generator)
server {
    listen 443 ssl http2;
    server_name technologik.local;

    ssl_certificate     /etc/ssl/certs/technologik.crt;
    ssl_certificate_key /etc/ssl/private/technologik.key;

    ssl_protocols TLSv1.2 TLSv1.3;               # désactive SSLv3, TLS 1.0/1.1 obsolètes
    ssl_ciphers HIGH:!aNULL:!MD5:!3DES;
    ssl_prefer_server_ciphers off;                 # TLS 1.3 gère mieux le choix côté client
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1h;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

# Erreurs fréquentes en production
- Certificat expiré non renouvelé -> automatiser avec Let's Encrypt / certbot (renouvellement cron)
- Chaîne de certificats incomplète (certificat intermédiaire manquant) -> "SSL handshake failed" côté client
- Mixed content : page HTTPS chargeant des ressources HTTP -> navigateur bloque ou avertit
- Ne pas activer HSTS -> laisse une fenêtre pour le downgrade HTTP->HTTPS (SSL stripping)