{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidifbou5emw4jgdsp653hntlspcwcc4ephqedkj65sa36hguup5c4",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmoa35ntoyd2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreifucqshk52to2x3l6pnkqoo47ocypcfq6wptriozlc4hvh2qbwxx4"
    },
    "mimeType": "image/jpeg",
    "size": 103612
  },
  "description": "Cipher Suites wie TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 sehen kryptisch aus, folgen aber einem klaren Schema: Key Exchange, Certificate Verification, Bulk Encryption und Hashing. Grundlagen fuer TLS 1.2 und 1.3.",
  "path": "/2020/04/14/tls-ecdhe-ecdhe-with-aes-256-gcm-sha384-was-bedeutet-das-eigentlich/",
  "publishedAt": "2026-05-25T10:04:40.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "Encryption",
    "Hardening",
    "InfoSec",
    "Networking",
    "PostQuantum",
    "Security",
    "Sysadmin",
    "TLS",
    "Post-Quantum TLS",
    "Einfach melden."
  ],
  "textContent": "Wer sich mit TLS beschäftigt, stolpert früher oder später über Zeichenketten wie `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` oder `TLS_AES_256_GCM_SHA384`. Was da genau drinsteht, ist auf den ersten Blick nicht offensichtlich. Dabei folgt die Benennung einem klaren Schema.\n\n### Die Bestandteile einer Cipher Suite\n\nJede Cipher Suite beschreibt vier Dinge:\n\n  * **Key Exchange** — wie sich Client und Server auf einen gemeinsamen Sitzungsschlüssel einigen.\n  * **Certificate Verification** — wie das Serverzertifikat geprüft wird (Signaturverfahren).\n  * **Bulk Encryption** — die symmetrische Verschlüsselung der eigentlichen Daten.\n  * **Hashing** — die Prüfsummen, die Integrität und Authentizität sicherstellen.\n\n\n\n### TLS 1.2 vs. TLS 1.3\n\nIn TLS 1.2 stehen alle vier Bestandteile im Namen der Cipher Suite. Nehmen wir `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` auseinander:\n\n  * `TLS` — das Protokoll (Transport Layer Security)\n  * `ECDHE` — Key Exchange (Elliptic Curve Diffie-Hellman Ephemeral)\n  * `ECDSA` — Certificate Verification (Elliptic Curve Digital Signature Algorithm)\n  * `AES_256_GCM` — Bulk Encryption (AES mit 256 Bit im Galois/Counter Mode)\n  * `SHA384` — Hashing (SHA-2 mit 384 Bit)\n\n\n\nTLS 1.3 hat das Namensschema verkürzt. Key Exchange und Certificate Verification sind nicht mehr Teil des Cipher-Suite-Namens, weil sie separat verhandelt werden. Darum sieht `TLS_AES_256_GCM_SHA384` so kompakt aus: nur Protokoll, Verschlüsselung und Hash.\n\n### Key Exchange\n\nDer Schlüsselaustausch legt fest, wie Client und Server einen temporären Sitzungsschlüssel aushandeln. Man will hier **Ephemeral** -Verfahren, also temporäre Schlüssel. Warum? Selbst wenn jemand den Traffic mitschneidet und später an den privaten Schlüssel des Servers kommt, kann er die aufgezeichneten Verbindungen nicht entschlüsseln. Der Sitzungsschlüssel existiert nur für die Dauer der Verbindung. Das nennt sich **Perfect Forward Secrecy**.\n\n`DHE` (Diffie-Hellman Ephemeral) funktioniert, sollte aber mindestens 2048 Bit nutzen. Besser ist `ECDHE` (Elliptic Curve DHE), weil es bei gleicher Sicherheit deutlich kleiner und schneller ist. Idealerweise bietet der Server nur ECDHE an. Alles ohne das **E** am Ende (also statisches DH) hat kein Forward Secrecy und gehört abgeschaltet.\n\nIn Zukunft kommt hier noch Post-Quantum dazu. Mit `X25519MLKEM768` lassen sich hybride Verfahren nutzen, die auch gegen Quantencomputer absichern. Wer das auf Nginx einrichten will, findet bei mir eine Anleitung: Post-Quantum TLS.\n\n### Certificate Verification\n\nVerschlüsselung allein hilft nicht, wenn man mit dem falschen Server spricht. Das Serverzertifikat beweist die Identität. Es wird von einer CA signiert, kann per DANE/TLSA im DNSSEC-geschützten DNS verankert sein und sollte nicht trivial fälschbar sein.\n\n`RSA`-Zertifikate sollten mindestens 2048 Bit haben, besser 4096 Bit. Allerdings werden RSA-Schlüssel mit steigender Sicherheit immer größer und langsamer. `ECDSA`-Zertifikate lösen das elegant: Ein ECDSA-Schlüssel mit 256 Bit bietet vergleichbare Sicherheit wie RSA mit 3072 Bit, ist aber deutlich kleiner und schneller zu verifizieren. Als Kurve sollte es mindestens `secp256r1` (P-256) sein. `secp384r1` geht auch, bringt aber aktuell keinen praktischen Vorteil.\n\n### Bulk Encryption\n\nDas ist die eigentliche Datenverschlüsselung. Brauchbare Kombinationen sind:\n\n  * `AES-128-GCM` oder `AES-256-GCM` — Standard, schnell, hardware-beschleunigt auf den meisten CPUs\n  * `ChaCha20-Poly1305` — gute Alternative, besonders auf Geräten ohne AES-NI\n\n\n\nAES mit CBC ist noch akzeptabel, aber GCM ist vorzuziehen. Von 3DES sollte man die Finger lassen. Wenn irgendwo `RC4` oder `DES` auftaucht: abschalten.\n\n### Hashing\n\nDer Hash sichert die Integrität der übertragenen Daten. Minimum ist `SHA-256`, ein guter Mittelweg ist `SHA-384`. SHA-1 sollte man nicht mehr einsetzen. Taucht `MD5` auf, stimmt etwas grundlegend nicht.\n\nFragen, Korrekturen oder Ergänzungen? Einfach melden.",
  "title": "TLS-ECDHE mit AES-256-GCM-SHA384 einfach erklärt"
}