Zum Hauptinhalt springen

4. Security Considerations (Sicherheitsüberlegungen)

TCP Fast Open führt einen Mechanismus zur Datenübertragung während des Handshakes ein, was neue Sicherheitsherausforderungen mit sich bringt. Dieses Kapitel analysiert diese Bedrohungen und die entsprechenden Schutzmaßnahmen im Detail.

4.1. Übersicht der Angriffsvektoren (Attack Threats Overview)​

Hauptbedrohungskategorien​

  1. Amplifikationsangriffe (Amplification Attacks)
  2. Ressourcenerschöpfungsangriffe (Resource Exhaustion Attacks)
  3. Replay-Angriffe (Replay Attacks)
  4. Datenschutzverletzungen (Privacy Leakage)

Bedrohungsmodell​

Annahmen zu Angreiferfähigkeiten:
├─ Kann Quell-IP-Adressen fälschen (IP-Spoofing)
├─ Kann Netzwerkpakete abfangen und wiedergeben
├─ Kann eine große Anzahl gleichzeitiger Verbindungen initiieren
└─ Kann Netzwerkverkehrsmuster beobachten

Schutzziele:
├─ Nicht anfälliger als Standard-TCP
├─ Amplifikationseffekt von Angriffen begrenzen
├─ Serverressourcen schützen
└─ Benutzerdatenschutz schützen

4.2. Amplifikationsangriffe (Amplification Attacks)​

Angriffsprinzip​

Angreifer nutzen Serverantworten, um Angriffsdatenverkehr zu verstärken:

Angriffsszenario:
1. Angreifer fälscht IP-Adresse des Opfers
2. Sendet kleines SYN-Paket (+ TFO-Cookie + Anfrage)
3. Server sendet große Antwort an das Opfer
4. Verstärkungsfaktor = Antwortgröße / Anfragegröße

Beispiel:
Anfrage: 60 Byte SYN + 100 Byte HTTP-Anfrage = 160 Byte
Antwort: 60 Byte SYN-ACK + 10 KB Daten = 10.060 Byte
Verstärkungsfaktor: 63x

Schutzmaßnahmen​

1. SYN-Datengröße begrenzen

Server MUSS:

  • Akzeptierte SYN-Datenlänge begrenzen (empfohlen: ≤ MSS, ca. 1460 Byte)
  • Überlange SYN-Datenpakete ablehnen

2. SYN-ACK-Antwortgröße begrenzen

Server SOLLTE:

  • Antwortdatengröße begrenzen, bevor die Verbindung vollständig hergestellt ist (ACK empfangen)
  • Empfohlene Begrenzung: ≤ 4 × SYN-Datenlänge

Implementierungsbeispiel:

MAX_SYN_DATA = 1460  # MSS
MAX_SYNACK_DATA_BEFORE_ACK = 4 * MAX_SYN_DATA  # 4x-Begrenzung

def handle_tfo_syn(syn_packet):
    if len(syn_packet.data) > MAX_SYN_DATA:
        # Fast Open ablehnen, auf Standard-Handshake zurückfallen
        return send_standard_synack()
    
    # Anfrage verarbeiten
    response = process_request(syn_packet.data)
    
    # Antwortgröße begrenzen (vor ACK)
    if len(response) > MAX_SYNACK_DATA_BEFORE_ACK:
        response = response[:MAX_SYNACK_DATA_BEFORE_ACK]
        # Restliche Daten nach ACK senden
    
    return send_synack_with_data(response)

3. Cookie-Validierung

Strenge Cookie-Validierung kann IP-Spoofing verhindern:

  • Cookie MUSS an Client-IP-Adresse gebunden sein
  • Anfragen mit ungültigem Cookie lösen keine Datenantwort aus

4. Ratenbegrenzung

Serverseitige Strategie:
├─ Ratenbegrenzung für Fast-Open-Verbindungen pro IP
├─ Globale Begrenzung der Fast-Open-Verbindungsanzahl
├─ Erkennung anomaler Muster (z. B. mehrfache Verwendung desselben Cookies)
└─ Temporäres Deaktivieren von Fast Open für verdächtige IPs

4.3. Ressourcenerschöpfungsangriffe (Resource Exhaustion)​

SYN-Flood-Angriffsvariante​

TFO kann für erweiterte SYN-Flood-Angriffe missbraucht werden:

Traditioneller SYN-Flood:
Angreifer → Viele SYNs → Server (erschöpft Halbverbindungswarteschlange)

TFO-SYN-Flood:
Angreifer → Viele SYNs + Cookie + Daten → Server
   ↓
Server muss:
   ├─ Cookie validieren (CPU)
   ├─ Daten verarbeiten (CPU + Speicher)
   └─ Möglicherweise Anwendungslogik auslösen (mehr Ressourcen)

Schutzmaßnahmen​

1. SYN-RECEIVED-Zustandsbegrenzung

Server MUSS:

  • Anzahl der Verbindungen im SYN-RECEIVED-Zustand begrenzen
  • Strengere Begrenzungen für TFO-Verbindungen festlegen

Implementierungsempfehlung:

#define MAX_SYN_RECEIVED_NORMAL  1024
#define MAX_SYN_RECEIVED_TFO     512   // TFO-Begrenzung niedriger

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++;
    }
    // ... Verarbeitung fortsetzen
}

2. Anwendungsschicht-Isolation

Server SOLLTE:

  • Zustellung von SYN-Daten an die Anwendungsschicht verzögern, bis ACK empfangen wird
  • Oder im SYN-RECEIVED-Zustand nur leichtgewichtige Verarbeitung durchführen

3. Kostenkontrolle der Cookie-Berechnung

Cookie-Validierung optimieren:
├─ Effizienten Verschlüsselungsalgorithmus verwenden (z. B. AES-NI-Hardwarebeschleunigung)
├─ Cookie-Cache implementieren (kurzfristige Caching-Validierungsergebnisse)
├─ Offensichtlich ungültige Cookies schnell ablehnen
└─ CPU-Auslastung überwachen, Strategie dynamisch anpassen

4. Integration mit SYN-Cookies

Server KANN TCP-SYN-Cookies kombiniert einsetzen:

  • SYN-Cookies: Zustandsloser SYN-Flood-Schutz
  • TFO-Cookies: Zustandsbehaftete Leistungsoptimierung
Schutzstrategie:
if (under_attack) {
    // Bei hoher Last TFO deaktivieren, SYN-Cookies aktivieren
    disable_tfo();
    enable_syn_cookies();
} else {
    // Normal: Beide aktivieren
    enable_tfo();
    enable_syn_cookies();  // Als Backup
}

4.4. Replay-Angriffe (Replay Attacks)​

Angriffsszenario​

Angreifer fangen TFO-SYN-Pakete ab und spielen sie erneut ab:

Szenario 1: Netzwerkabhören
Angreifer (Abhören) ─┐
                      ↓
Client ────SYN + Cookie + "GET /transfer?amount=100"───→ Server
                      ↑
Angreifer (Replay) ───┘  → Überweisungsoperation wiederholt ausführen!

Schutzmaßnahmen​

1. Idempotenzanforderung

Anwendungsschicht MUSS:

  • Nur idempotente Operationen in TFO-SYN senden
  • Beispiele:
    • ✓ Erlaubt: GET-Anfragen, Nur-Lese-Operationen
    • ✗ Verboten: POST, PUT, DELETE und andere Operationen mit Nebeneffekten

Client-Leitfaden:

def can_use_tfo(request):
    # TFO nur für idempotente Anfragen verwenden
    if request.method in ['GET', 'HEAD', 'OPTIONS']:
        return True
    if request.method == 'POST' and request.is_idempotent:
        return True  # Anwendung explizit als idempotent markiert
    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. TCP-Sequenznummernschutz

TCP-eigene Mechanismen bieten grundlegenden Schutz:

  • Server verfolgt empfangene Sequenznummern
  • Daten mit doppelten Sequenznummern werden verworfen
  • Einschränkung: Nur während der Verbindungsdauer gültig

3. Anwendungsschicht-Deduplizierung

Server-Anwendung SOLLTE:

  • Anfrage-Deduplizierungsmechanismus implementieren (z. B. Anfrage-ID)
  • Zusätzliche Validierung für sensible Operationen verwenden (z. B. CSRF-Token)

4. Cookie-Zeitgültigkeit

  • Nach Cookie-Ablauf werden alte Replay-Angriffe unwirksam
  • Kurze Cookie-Gültigkeitsdauer reduziert das Replay-Zeitfenster

4.5. Datenschutzüberlegungen (Privacy Considerations)​

Bedrohung: TFO-Cookies könnten als persistente Benutzer-Tracking-Bezeichner verwendet werden:

Datenschutzrisiko:
Client-IP ändert sich → Cookie bleibt gültig
   ↓
Server kann Verbindungen von verschiedenen IPs verknüpfen
   ↓
Potenzielle Benutzeridentitätsverknüpfung und -verfolgung

Schutzmaßnahmen​

1. Cookie an IP gebunden

Cookie MUSS an IP-Adresse gebunden sein:

  • Nach IP-Änderung wird Cookie ungültig
  • Neues Cookie muss angefordert werden

Abwägung:

  • ✓ Verbesserten Datenschutz
  • ✗ Häufige Cookie-Aktualisierungen in Mobilfunknetz-IP-Drift-Szenarien erforderlich

2. Begrenzte Cookie-Lebensdauer

  • Empfohlene Gültigkeitsdauer: Stunden bis 1 Tag
  • Cookies regelmäßig rotieren
  • Cookies löschen, wenn Benutzer Browserdaten löscht

3. Cookie enthält keine Benutzerinformationen

Cookie DARF NICHT:

  • Benutzer-ID oder Sitzungs-ID enthalten
  • Benutzeridentifizierbare Informationen enthalten
  • Über verschiedene Dienste hinweg geteilt werden

Cookie SOLLTE:

  • Nur zur Überprüfung verwendet werden, dass der Client zuvor mit dem Server verbunden war
  • Keine Zustandsinformationen übertragen

4. Benutzerkontrolle

Client SOLLTE bereitstellen:

  • Option zum Deaktivieren von TFO
  • Funktion zum Löschen von TFO-Cookies
  • TFO-Cookies im Datenschutzmodus deaktivieren

4.6. Interaktion mit anderen Sicherheitsmechanismen (Interaction with Other Security Mechanisms)​

TLS/SSL-Integration​

Überlegungen bei kombinierter Verwendung von TFO und TLS:

TFO + TLS-Handshake:
Client                              Server
   |                                  |
   | SYN + TFO Cookie + TLS ClientHello |
   |---------------------------------->|
   |                                  |
   | SYN-ACK + TLS ServerHello       |
   |<----------------------------------|
   |                                  |
   | ACK + TLS ...                    |
   |---------------------------------->|

Vorteile:

  • Weitere Latenzreduzierung (TLS 1.3 + TFO = 0-RTT)
  • TLS bietet zusätzliche Sicherheitsschicht

Hinweis:

  • TLS-0-RTT-Daten erfordern ebenfalls Idempotenz
  • Sicherheit von TFO und TLS muss gleichzeitig berücksichtigt werden

Firewalls und NAT​

Kompatibilitätsprobleme:

Einige Middleboxen können:
├─ TCP-Fast-Open-Optionen entfernen
├─ SYN-Pakete mit Daten blockieren
├─ TCP-Optionsfelder ändern
└─ Strenge Zustandsverfolgung implementieren

Gegenmaßnahmen:
├─ Client implementiert Rückfallmechanismus
├─ TFO-Unterstützung erkennen
├─ Deaktivierungsoption bereitstellen
└─ Server protokolliert Kompatibilitätsprobleme

DoS-Schutzsysteme​

TFO SOLLTE mit bestehenden DoS-Schutzsystemen koordiniert werden:

Integrationsempfehlungen:
├─ DDoS-Schutzgeräte SOLLTEN TFO-Optionen verstehen
├─ Ratenbegrenzung SOLLTE TFO-Datenverkehr berücksichtigen
├─ Anomalieerkennung SOLLTE TFO-Missbrauchsmuster erkennen
└─ TFO kann bei Angriffen dynamisch deaktiviert werden

4.7. Zusammenfassung der Sicherheits-Best-Practices (Security Best Practices Summary)​

Serverseitig​

MUSS implementiert werden:

  • ✓ Cookie an Client-IP binden
  • ✓ SYN-Datengröße begrenzen
  • ✓ SYN-ACK-Antwortgröße begrenzen (vor ACK)
  • ✓ Cookie-Ablaufmechanismus
  • ✓ Ratenbegrenzung

SOLLTE implementiert werden:

  • ✓ Server-Schlüssel regelmäßig rotieren
  • ✓ TFO-Nutzungsmuster überwachen
  • ✓ Mit SYN-Cookies integrieren
  • ✓ Anfrage-Deduplizierung auf Anwendungsschicht
  • ✓ Strategie dynamisch anpassen (basierend auf Last)

KANN implementiert werden:

  • ✓ Erweiterte Bedrohungserkennung
  • ✓ Cookie-Versionsverwaltung
  • ✓ Geolokalisierungsvalidierung
  • ✓ Machine-Learning-Anomalieerkennung

Clientseitig​

MUSS implementiert werden:

  • ✓ TFO nur für idempotente Operationen verwenden
  • ✓ Cookie sicher speichern
  • ✓ Fähigkeit zum Rückfall auf Standard-TCP

SOLLTE implementiert werden:

  • ✓ Cookie-Ablaufverwaltung
  • ✓ Benutzerdatenschutzkontrolle
  • ✓ Fehlererkennungs- und Wiederholungslogik
  • ✓ Datenschutzmodus-Unterstützung

Anwendungsschicht​

Empfehlungen:

Idempotenzprüfung:
├─ GET/HEAD-Anfragen → TFO standardmäßig erlauben
├─ POST/PUT/DELETE → TFO standardmäßig verbieten
├─ Anwendungsspezifische Logik → explizit markieren
└─ Sensible Operationen → TFO immer verbieten

Datenvalidierung:
├─ Nicht auf TFO-Sicherheit verlassen
├─ Anwendungsschicht-Authentifizierung implementieren
├─ TLS-Verschlüsselung verwenden
└─ Anfrage-Signierung und -Validierung

Nächster Abschnitt: 5. IANA Considerations (IANA-Überlegungen) erläutert die Optionsnummernzuweisung für TCP Fast Open.

Letztes Update am