Aller au contenu principal

4. Considérations de sécurité (Security Considerations)

TCP Fast Open introduit un mécanisme de transmission de données pendant la poignée de main, ce qui crée de nouveaux défis en matière de sécurité. Ce chapitre analyse en détail ces menaces et les mesures de protection correspondantes.

4.1. Vue d'ensemble des menaces d'attaque (Attack Threats Overview)​

Principales catégories de menaces​

  1. Attaques par amplification (Amplification Attacks)
  2. Attaques par épuisement des ressources (Resource Exhaustion Attacks)
  3. Attaques par rejeu (Replay Attacks)
  4. Fuite de confidentialité (Privacy Leakage)

Modèle de menace​

Hypothèses sur les capacités de l'attaquant :
├─ Peut usurper des adresses IP sources (IP spoofing)
├─ Peut intercepter et rejouer des paquets réseau
├─ Peut initier un grand nombre de connexions simultanées
└─ Peut observer les schémas de trafic réseau

Objectifs de protection :
├─ Ne pas être plus vulnérable que le TCP standard
├─ Limiter l'effet d'amplification des attaques
├─ Protéger les ressources du serveur
└─ Protéger la vie privée des utilisateurs

4.2. Attaques par amplification (Amplification Attacks)​

Principe de l'attaque​

L'attaquant utilise les réponses du serveur pour amplifier le trafic d'attaque :

Scénario d'attaque :
1. L'attaquant usurpe l'adresse IP de la victime
2. Envoie un petit paquet SYN (+ cookie TFO + requête)
3. Le serveur envoie une grande réponse à la victime
4. Facteur d'amplification = taille de la réponse / taille de la requête

Exemple :
Requête : 60 octets SYN + 100 octets requête HTTP = 160 octets
Réponse : 60 octets SYN-ACK + 10 Ko de données = 10 060 octets
Facteur d'amplification : 63x

Mesures de protection​

1. Limitation de la taille des données SYN

Le serveur DOIT :

  • Limiter la longueur des données SYN acceptées (recommandé ≤ MSS, environ 1460 octets)
  • Rejeter les paquets SYN avec des données trop longues

2. Limitation de la taille de la réponse SYN-ACK

Le serveur DEVRAIT :

  • Limiter la taille des données de réponse avant que la connexion soit complètement établie (réception de l'ACK)
  • Limite recommandée : ≤ 4 × longueur des données SYN

Exemple d'implémentation :

MAX_SYN_DATA = 1460  # MSS
MAX_SYNACK_DATA_BEFORE_ACK = 4 * MAX_SYN_DATA  # Limite 4x

def handle_tfo_syn(syn_packet):
    if len(syn_packet.data) > MAX_SYN_DATA:
        # Refuser le Fast Open, revenir à la poignée de main standard
        return send_standard_synack()
    
    # Traitement de la requête
    response = process_request(syn_packet.data)
    
    # Limiter la taille de la réponse (avant ACK)
    if len(response) > MAX_SYNACK_DATA_BEFORE_ACK:
        response = response[:MAX_SYNACK_DATA_BEFORE_ACK]
        # Les données restantes sont envoyées après l'ACK
    
    return send_synack_with_data(response)

3. Vérification du cookie

Une vérification stricte du cookie peut prévenir l'usurpation d'IP :

  • Le cookie DOIT être lié à l'adresse IP du client
  • Les requêtes avec un cookie invalide ne déclenchent pas de réponse de données

4. Limitation de débit

Politique côté serveur :
├─ Limite de débit des connexions Fast Open par IP
├─ Limite globale du nombre de connexions Fast Open
├─ Détection de schémas anormaux (par exemple, même cookie utilisé plusieurs fois)
└─ Désactivation temporaire du Fast Open pour les IP suspectes

4.3. Attaques par épuisement des ressources (Resource Exhaustion)​

Variante d'attaque SYN Flood​

TFO peut être utilisé pour des attaques SYN Flood améliorées :

SYN Flood traditionnel :
Attaquant → grand nombre de SYN → serveur (épuise la file des demi-connexions)

SYN Flood avec TFO :
Attaquant → grand nombre de SYN + cookie + données → serveur
   ↓
Le serveur doit :
   ├─ Vérifier le cookie (CPU)
   ├─ Traiter les données (CPU + mémoire)
   └─ Peut déclencher la logique applicative (plus de ressources)

Mesures de protection​

1. Limitation de l'état SYN-RECEIVED

Le serveur DOIT :

  • Limiter le nombre de connexions dans l'état SYN-RECEIVED
  • Définir des limites plus strictes pour les connexions TFO

Recommandations d'implémentation :

#define MAX_SYN_RECEIVED_NORMAL  1024
#define MAX_SYN_RECEIVED_TFO     512   // Limite TFO plus basse

int syn_received_count_normal = 0;
int syn_received_count_tfo = 0;

int accept_syn(packet, is_tfo) {
    if (is_tfo) {
        if (syn_received_count_tfo >= MAX_SYN_RECEIVED_TFO)
            return REJECT;
        syn_received_count_tfo++;
    } else {
        if (syn_received_count_normal >= MAX_SYN_RECEIVED_NORMAL)
            return REJECT;
        syn_received_count_normal++;
    }
    // ... continuer le traitement
}

2. Isolation de la couche applicative

Le serveur DEVRAIT :

  • Retarder la livraison des données SYN à la couche applicative jusqu'à réception de l'ACK
  • Ou effectuer uniquement un traitement léger dans l'état SYN-RECEIVED

3. Contrôle du coût de calcul des cookies

Optimisation de la vérification des cookies :
├─ Utiliser des algorithmes de chiffrement efficaces (par exemple accélération matérielle AES-NI)
├─ Implémenter un cache de cookies (cache à court terme des résultats de vérification)
├─ Rejeter rapidement les cookies manifestement invalides
└─ Surveiller l'utilisation du CPU, ajuster dynamiquement la stratégie

4. Intégration avec les SYN Cookies

Le serveur PEUT combiner l'utilisation des TCP SYN Cookies :

  • SYN Cookies : protection sans état contre les SYN Flood
  • Cookies TFO : optimisation des performances avec état
Stratégie de protection :
if (under_attack) {
    // En cas de forte charge, désactiver TFO, activer les SYN Cookies
    disable_tfo();
    enable_syn_cookies();
} else {
    // En fonctionnement normal, activer les deux
    enable_tfo();
    enable_syn_cookies();  // En secours
}

4.4. Attaques par rejeu (Replay Attacks)​

Scénario d'attaque​

L'attaquant intercepte et rejoue des paquets SYN TFO :

Scénario 1 : écoute réseau
Attaquant (écoute) ─┐
                    ↓
Client ────SYN + cookie + "GET /transfer?amount=100"───→ Serveur
                    ↑
Attaquant (rejeu) ──┘  → Exécution répétée de l'opération de transfert !

Mesures de protection​

1. Exigence d'idempotence

La couche applicative DOIT :

  • N'envoyer que des opérations idempotentes dans le SYN TFO
  • Exemples :
    • ✓ Autorisé : requêtes GET, opérations en lecture seule
    • ✗ Interdit : opérations avec effets secondaires comme POST, PUT, DELETE

Guide pour le client :

def can_use_tfo(request):
    # Utiliser TFO uniquement pour les requêtes idempotentes
    if request.method in ['GET', 'HEAD', 'OPTIONS']:
        return True
    if request.method == 'POST' and request.is_idempotent:
        return True  # Application explicitement marquée comme idempotente
    return False

def send_request(request):
    if can_use_tfo(request) and has_cookie(server):
        send_with_tfo(request)
    else:
        send_with_standard_tcp(request)

2. Protection par numéros de séquence TCP

Le mécanisme TCP lui-même fournit une protection de base :

  • Le serveur suit les numéros de séquence reçus
  • Les données avec des numéros de séquence dupliqués sont rejetées
  • Limitation : valable uniquement pendant la durée de la connexion

3. Déduplication au niveau applicatif

L'application serveur DEVRAIT :

  • Implémenter un mécanisme de déduplication des requêtes (par exemple, ID de requête)
  • Utiliser une validation supplémentaire pour les opérations sensibles (par exemple, jeton CSRF)

4. Validité temporelle du cookie

  • Après expiration du cookie, les anciennes attaques par rejeu deviennent inefficaces
  • Une courte durée de validité du cookie réduit la fenêtre de rejeu

4.5. Considérations de confidentialité (Privacy Considerations)​

Menace : Le cookie TFO peut être utilisé comme identifiant de suivi persistant de l'utilisateur :

Risque de confidentialité :
L'IP du client change → le cookie reste valide
   ↓
Le serveur peut corréler des connexions provenant d'IP différentes
   ↓
Association et suivi potentiels de l'identité de l'utilisateur

Mesures de protection​

1. Liaison du cookie à l'IP

Le cookie DOIT être lié à l'adresse IP :

  • Après changement d'IP, le cookie devient invalide
  • Un nouveau cookie doit être demandé

Compromis :

  • ✓ Renforce la protection de la vie privée
  • ✗ Les scénarios de dérive d'IP sur les réseaux mobiles nécessitent des mises à jour fréquentes du cookie

2. Durée de vie limitée du cookie

  • Durée de validité recommandée : de quelques heures à 1 jour
  • Rotation périodique des cookies
  • Effacer les cookies lorsque l'utilisateur efface ses données de navigation

3. Le cookie ne contient pas d'informations utilisateur

Le cookie NE DOIT PAS :

  • Contenir un ID utilisateur ou un ID de session
  • Contenir des informations permettant d'identifier l'utilisateur
  • Être partagé entre différents services

Le cookie DEVRAIT :

  • Servir uniquement à vérifier que le client s'est déjà connecté au serveur
  • Ne transporter aucune information d'état

4. Contrôle utilisateur

Le client DEVRAIT fournir :

  • Une option pour désactiver TFO
  • Une fonctionnalité pour effacer les cookies TFO
  • Désactivation des cookies TFO en mode privé

4.6. Interaction avec d'autres mécanismes de sécurité (Interaction with Other Security Mechanisms)​

Intégration TLS/SSL​

Considérations lors de l'utilisation combinée de TFO et TLS :

Poignée de main TFO + TLS :
Client                              Serveur
   |                                  |
   | SYN + cookie TFO + TLS ClientHello |
   |---------------------------------->|
   |                                  |
   | SYN-ACK + TLS ServerHello       |
   |<----------------------------------|
   |                                  |
   | ACK + TLS ...                    |
   |---------------------------------->|

Avantages :

  • Réduction supplémentaire de la latence (TLS 1.3 + TFO = 0-RTT)
  • TLS fournit une couche de sécurité supplémentaire

Remarque :

  • Les données 0-RTT de TLS exigent également l'idempotence
  • La sécurité de TFO et de TLS doit être considérée simultanément

Pare-feux et NAT​

Problèmes de compatibilité :

Certains équipements intermédiaires peuvent :
├─ Supprimer les options TCP Fast Open
├─ Bloquer les paquets SYN contenant des données
├─ Modifier les champs d'options TCP
└─ Implémenter un suivi d'état strict

Stratégies d'adaptation :
├─ Le client implémente un mécanisme de repli
├─ Détecter si TFO est supporté
├─ Fournir une option de désactivation
└─ Le serveur enregistre les problèmes de compatibilité

Systèmes de protection DoS​

TFO DEVRAIT être coordonné avec les systèmes de protection DoS existants :

Recommandations d'intégration :
├─ Les équipements de protection DDoS devraient comprendre les options TFO
├─ La limitation de débit devrait tenir compte du trafic TFO
├─ La détection d'anomalies devrait identifier les schémas d'abus TFO
└─ TFO peut être désactivé dynamiquement en cas d'attaque

4.7. Résumé des meilleures pratiques de sécurité (Security Best Practices Summary)​

Côté serveur​

DOIT implémenter :

  • ✓ Cookie lié à l'IP du client
  • ✓ Limitation de la taille des données SYN
  • ✓ Limitation de la taille de la réponse SYN-ACK (avant ACK)
  • ✓ Mécanisme d'expiration des cookies
  • ✓ Limitation de débit

DEVRAIT implémenter :

  • ✓ Rotation périodique de la clé du serveur
  • ✓ Surveillance des schémas d'utilisation TFO
  • ✓ Intégration avec les SYN Cookies
  • ✓ Déduplication des requêtes au niveau applicatif
  • ✓ Ajustement dynamique de la stratégie (selon la charge)

PEUT implémenter :

  • ✓ Détection avancée des menaces
  • ✓ Gestion des versions de cookies
  • ✓ Vérification géographique
  • ✓ Détection d'anomalies par apprentissage automatique

Côté client​

DOIT implémenter :

  • ✓ Utiliser TFO uniquement pour les opérations idempotentes
  • ✓ Stockage sécurisé des cookies
  • ✓ Capacité de repli vers le TCP standard

DEVRAIT implémenter :

  • ✓ Gestion de l'expiration des cookies
  • ✓ Contrôles de confidentialité pour l'utilisateur
  • ✓ Logique de détection des échecs et de nouvelle tentative
  • ✓ Support du mode privé

Couche applicative​

Recommandations :

Vérification d'idempotence :
├─ Requêtes GET/HEAD → autoriser TFO par défaut
├─ POST/PUT/DELETE → interdire TFO par défaut
├─ Logique spécifique à l'application → marquage explicite
└─ Opérations sensibles → toujours interdire TFO

Validation des données :
├─ Ne pas dépendre de la sécurité de TFO
├─ Implémenter l'authentification au niveau applicatif
├─ Utiliser le chiffrement TLS
└─ Signature et vérification des requêtes

Section suivante : 5. Considérations IANA (IANA Considerations) expliquera l'attribution du numéro d'option TCP Fast Open.

Dernière mise à jour le