Zum Hauptinhalt springen

Anhang D. Implementierungshinweise (Implementation Notes)

Dieser Anhang bietet praktische Ratschläge und Best Practices für die Implementierung von TLS 1.2.

D.1. Zufallszahlengenerierung und Seeding (Random Number Generation and Seeding)​

Die Sicherheit von TLS hängt stark von der Qualität der Zufallszahlengenerierung ab. Implementierungen MÜSSEN kryptographisch sichere Pseudozufallszahlengeneratoren (CSPRNG) verwenden.

D.1.1. Anforderungen an die Zufallszahlengenerierung​

  • Entropiequelle: Kryptographische Qualität der vom Betriebssystem bereitgestellten Entropiequellen verwenden (wie /dev/urandom auf Unix-Systemen)
  • Seeding: Sicherstellen, dass der PRNG vor der Verwendung ordnungsgemäß geseeded ist
  • Reseeding: Regelmäßiges Reseeding zur Aufrechterhaltung des Entropiepools
  • Schwache Quellen vermeiden: Vorhersagbare Werte wie Zeitstempel, Prozess-IDs nicht als einzige Entropiequelle verwenden

D.1.2. Implementierungsempfehlungen​

/* Schlechte Praxis - Nicht tun */
srand(time(NULL));
random_value = rand();

/* Gute Praxis - Systembereitgestellten CSPRNG verwenden */
#ifdef _WIN32
    CryptGenRandom(...);  /* Windows */
#else
    /* Unix/Linux */
    int fd = open("/dev/urandom", O_RDONLY);
    read(fd, random_buffer, length);
    close(fd);
#endif

D.2. Zertifikate und Authentifizierung (Certificates and Authentication)​

D.2.1. Zertifikatsüberprüfung​

Implementierungen MÜSSEN die Zertifikatskette ordnungsgemäß überprüfen:

  1. Zertifikatskettenüberprüfung:

    • Die Signatur jedes Zertifikats überprüfen
    • Sicherstellen, dass die Zertifikatskette eine vertrauenswürdige Wurzel-CA erreicht
    • Die Gültigkeitsdauer der Zertifikate überprüfen

  2. Hostname-Überprüfung:

    • Den Common Name (CN) oder Subject Alternative Name (SAN) im Zertifikat überprüfen
    • Wildcard-Zertifikate unterstützen (wie *.example.com)

  3. Widerrufsüberprüfung:

    • Implementierungen SOLLTEN den Zertifikatswiderrufsstatus überprüfen
    • CRL (Certificate Revocation List) und/oder OCSP (Online Certificate Status Protocol) unterstützen

D.2.2. Zertifikatsauswahl​

Server sollten:

  • Mehrere Zertifikate unterstützen (RSA, ECDSA usw.)
  • Das beste Zertifikat basierend auf Client-Fähigkeiten auswählen
  • Leistung und Sicherheit ausbalancieren

D.3. Cipher Suites​

D.3.1. Cipher-Suite-Auswahl​

Implementierungen SOLLTEN:

  • Starke Cipher Suites standardmäßig aktivieren
  • Cipher Suites mit bekannten Schwächen deaktivieren (RC4, DES, Export-Grade-Verschlüsselung)
  • Cipher-Suite-Liste nach Priorität sortieren

D.3.2. Empfohlene Konfiguration​

Prioritätsreihenfolge (von hoch nach niedrig):

  1. AEAD-Cipher-Suites (GCM-Modus)
  2. Suites, die Forward Secrecy bieten (DHE/ECDHE)
  3. AES-256 über AES-128
  4. SHA-256 oder stärkerer MAC
  5. CBC-Modus vermeiden (wenn möglich)

Beispielkonfiguration:

1. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
2. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
3. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
4. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
5. TLS_RSA_WITH_AES_256_CBC_SHA256
6. TLS_RSA_WITH_AES_128_CBC_SHA256

D.4. Implementierungsfallen (Implementation Pitfalls)​

D.4.1. Timing-Angriffe​

Problem: Timing-Unterschiede beim Passwortvergleich und der Padding-Validierung können Informationen preisgeben.

Lösung: Konstant-Zeit-Vergleich verwenden:

/* Unsicherer Vergleich */
int compare(const unsigned char *a, const unsigned char *b, size_t len) {
    for (size_t i = 0; i < len; i++) {
        if (a[i] != b[i])
            return 0;  /* Vorzeitiger Abbruch - gibt Timing-Informationen preis */
    }
    return 1;
}

/* Konstant-Zeit-Vergleich */
int constant_time_compare(const unsigned char *a, const unsigned char *b, 
                         size_t len) {
    unsigned char result = 0;
    for (size_t i = 0; i < len; i++) {
        result |= a[i] ^ b[i];
    }
    return result == 0;
}

D.4.2. Padding-Oracle-Angriffe​

Problem: Padding-Validierungsfehler im CBC-Modus können ausgenutzt werden.

Lösung:

  • Konstant-Zeit-Padding-Validierung verwenden
  • Denselben Fehler für alle Entschlüsselungsfehler zurückgeben
  • AEAD-Modus (GCM) in Betracht ziehen, um dieses Problem zu vermeiden

D.4.3. Versions-Rollback-Angriffe​

Problem: Angreifer können versuchen, die Verwendung schwächerer Protokollversionen zu erzwingen.

Lösung:

  • Die ausgehandelte Version in der Finished-Nachricht einschließen
  • Konsistenz der Versionsfelder überprüfen
  • SCSV (Signaling Cipher Suite Value) Schutz implementieren

D.4.4. Renegotiation-Angriffe​

Problem: Neuverhandlung kann verwendet werden, um Befehle einzuschleusen oder andere Angriffe durchzuführen.

Lösung:

  • RFC 5746 (Renegotiation Indication Extension) implementieren
  • Neuverhandlung während sensibler Operationen deaktivieren
  • Client-Zertifikatsänderungen ordnungsgemäß behandeln

D.4.5. Kompressionsangriffe (CRIME)​

Problem: TLS-Kompression kann geheime Informationen preisgeben.

Lösung:

  • TLS-Level-Kompression deaktivieren
  • Wenn Kompression benötigt wird, auf Anwendungsschicht implementieren
  • Kompression von Daten mit Geheimnissen vermeiden

D.4.6. Pufferverwaltung​

Problem: Unsachgemäße Pufferverwaltung kann zu Überläufen oder Informationslecks führen.

Lösung:

  • Längenfelder immer überprüfen
  • Sichere Speicherfunktionen verwenden (wie memcpy_s)
  • Sensible Daten nach dem Freigeben nullen
/* Sensible Daten löschen */
void secure_zero(void *ptr, size_t len) {
    volatile unsigned char *p = ptr;
    while (len--)
        *p++ = 0;
}

/* Schlüssel nach Verwendung löschen */
unsigned char key[32];
/* ... Schlüssel verwenden ... */
secure_zero(key, sizeof(key));

D.4.7. Fehlerbehandlung​

Problem: Detaillierte Fehlermeldungen können Implementierungsdetails preisgeben.

Lösung:

  • Generische Fehler an externe Entitäten zurückgeben
  • Detaillierte Fehler sollten nur intern protokolliert werden
  • Timing-Informationen nicht preisgeben

D.5. Leistungsoptimierung​

D.5.1. Sitzungswiederaufnahme​

  • Session-Caching oder Session-Tickets implementieren
  • Anzahl vollständiger Handshakes reduzieren
  • Sicherheit und Leistung ausbalancieren

D.5.2. Bulk-Operationen​

  • Verschlüsselungs-/Entschlüsselungsoperationen stapelweise verarbeiten
  • Hardware-Beschleunigung verwenden (AES-NI, PCLMULQDQ usw.)
  • Asynchrone I/O in Betracht ziehen

D.5.3. Verbindungspooling​

  • TLS-Verbindungen wiederverwenden
  • Connection-Pool-Verwaltung implementieren
  • Angemessene Timeout-Werte festlegen

Hinweis: Für vollständige Implementierungsempfehlungen und detaillierte Erklärungen siehe den vollständigen Text von RFC 5246 Anhang D.

Letztes Update am