Eigentlich ist das recht einfach zu beantworten: möglichst hohe Sicherheit bei akzeptierbarer Performance und Kompatibilität.
Beim Aufbau einer TLS-Verbindung muss man folgende Bereiche unterscheiden: Schlüsselaustausch, Authentifikation, Verschlüsselung und die Authentizität. Der Client startet ein TLS Session mit dem «Client Hello» und bietet eine Cipher Suite Auswahl an, der Server wählte eine aus und der Client bestätigt diese.
Transport Layer Security (TLS 1.2 im Unterschied zu TLS 1.3)
Ein genereller Unterschied ist noch TLS 1.3 und TLS1.2, ältere Versionen sollte man eh ausschliessen.
Bei TLS 1.3 gibt es einen neuen Aufbau der Cipher Suites, da Key Agreement und Server Authentication entkoppelt wurden.
Nach RFC 8446 (TLS 1.3)
Client Server Key ^ ClientHello
Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* --------> ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] + Indicates noteworthy extensions sent in the previously noted message. * Indicates optional or situation-dependent messages/extensions that are not always sent. {} Indicates messages protected using keys derived from a [sender]_handshake_traffic_secret. [] Indicates messages protected using keys derived from [sender]_application_traffic_secret_N.
Der Key Exchange findet nicht mehr im Client Hello und Server Hello statt, sondern in der
Cryptographic Negotiation. Hier werden nur noch die symmetrischen Algorithmen ausgehandelt.
Im Vergleich zum RFC 5246 (TLS 1.2)
Client Server ClientHello client version (protocol version) random number cipher suite list Compression method [Session ID] --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
Perfect Forward Secrecy (DSA im Unterschied zu RSA)
Mit Perfect Forward Secrecy, sicherlich eins der wichtigeren Kriterien, damit nicht aufgezeichnete Daten im Nachhinein noch geknackt werden können, ist auch die langfristige Sicherheit gewährleistet. Das heisst die Verschlüsselung des Session Keys ist nicht nur vom Private Key abhängig und wird regelmässig aktuell. Dazu müssten wir mal wieder in die Mathematik abtauchen.
Vielleicht ein kleines vereinfachtes Beispiel anhand von Diffie-Hellman-Merkle:
Da rechnen wir:
p=47, g ist 5 und das i, als Index, durchläuft alle natürlichen Zahlen ab Null. Alice wählt irgendein i und berechnet a, das Bob erhält, das geht fix. Wenn Bob a=41 bekommt, welches i hat dann Alice verwendet? Wer das schnell für Zahlen mit rund 350 Dezimalstellen oder 2048 Bit herausbekommt, der hat das DLP – diskrete Logarithmus Problem geknackt und stellt damit Diffie-Hellman-Merkle, Elgamal, DSA (standartisierter El-Gamal), ECC in Frage.
Zur Anschaulichkeit mal die gesamte zyklishe Gruppe.
Die Anordnung des a ist hier scheinbar zufällig und deshalb kann man nicht so einfach von a auf das verwendete i schliessen. Darauf basiert die Sicherheit bei den genannten Verfahren im Vergleich zu RSA. Dort ist es die Primfaktorenzerlegung.
Wer die p,q herausfindet, die n ergaben, knackt RSA. Gern hier noch mal nachlesen.
Elliptische Kurven
Bei elliptischen Kurven ist es auch ein DLP was gelöst werden muss, um ECC mathematisch zu brechen. Die Berechnung der Elemente der zyklischen Gruppe ist noch etwas komplizierter. Die Punkte (Tupel) liegen dann auf einer dieser Kurven und daher der Name.
Das letzte «E» beim ECDHE oder DHE ist auch zu bevorzugen, da es zufällige Schlüssel garantiert. Diese sollten heute grösser 256 Bit bei elliptischen Kurven und 2048 Bit bei RSA sein. Zu der Anzahl der Bits hatte ich mich ja schon im letzten Jahr ausgelassen: Key length versus life time.
Nun kann man sich über elliptische Kurven und RSA streiten, aber ECC benötigt kürzere Schlüssel und wird, da es performanter ist, gern bei den mobilen Geräten verwendet.
Der Aufbau der Cypher Suiten
Nochmal zum generellen Aufbau: Auf der Website www.ciphersuite.info/cs/ findet man gute Auflistungen, alternative Namen und Erläuterungen.
Aufbau TLS 1.3
TLS_AES_256_GCM_SHA384
Wie oben beschrieben hier und Message Authentication.
Aufbau TLS 1.2
Example: TLS_ECDHE_ECDSA_AES_256_GCM_SHA256
Protocol:
Transport Layer Security (TLS)
Key Exchange:
Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)
Authentication:
Elliptic Curve Digital Signature Algorithm (ECDSA)
Encryption:
Advanced Encryption Standard with 256bit Key in Galois/Counter Mode (AES 256 GCM)
Hash:
Secure Hash Algorithm 256 (SHA256)
Schlüsselvereinbahrung
ECDHE – Asymmetrischer Key Exchange nach dem Diffie-Hellman Protocol basierend auf ECC, um die Session Key Sicherheit zu gewährleisten, Elliptic Curve Diffie Hellman Ephemeral.
Ephemeral unterstreicht hier die Flüchtigkeit der temporären Keys.
Quelle: Wikipedia, https://en.wikipedia.org/wiki/Curve25519, abgerufen am 31.03.2021
Authentication
ECDSA (Signing)
Asymmetrische Authentifizierung des Servers. Der Digital Signature Algorithm ist die standartisierte Variante des Elgamal für Signaturen auch hier basierend auf dem DLP der elliptischen Kurven.
Encryption of Data
AES_256_GCM
Symmetric Encryption der Message Blocks nach AES.
GCM gewährleistet, das nicht Daten-Blöcke ausgetauscht werden können und so die Informationen manipuliert werden.
wikipedia.org/wiki/Galois/Counter_Mode
Message Authentication
Mit den Hash Verfahren wird dann die Authentizität der einzelnen Nachricht bestätigt und die Integrität der Nachricht, aber nicht non-reputation, da hier meist symmetrische Verfahren die Grundlage sind.
Z.B. bei TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 sehen wir jetzt schnell, dass es ein TLS1.2 Cipher mit dem gleichen Key Exchange aber RSA für die Authentifizierung des Servers verwendet wird. Das wird wohl am meisten bei Zertifikaten mit RSA Public Key der Fall sein. SHA384 hat dann mehr Bits aber ist immer noch SHA2.
In der Praxis
Lange Rede kurzer Sinn: Wir machen es so sicher wie möglich, ohne dass wir notwendige Benutzergruppen ausschliessen oder zu grosse Hürden aufbauen. Frei nach Ed Snowden «Encryption works, …», wenn richtig implementiert, deshalb ist die richtige Wahl der Cipher Suites so wichtig. Nicht nur https und TLS – sondern richtig:
-
- DHE mit dem E für Ephemeral – kurzzeitige flüchtige Keys
- AES mit 128 oder 256 Bit – aktuell noch OK, Blowfish, Two-Fish auch OK
- SHA-2 (SHA-256, SHA384 oder SHA-512), sicher kein SHA-1 oder MD5 mehr
- Gern auch schon TLS 1.3 und SHA-3 wenn irgendwie verfügbar
- Bei ECC würde ich auch nicht mehr unter P-256 starten, bei P-521 würde ich gut testen
Sehr hilfreich für die Beurteilung ist immer eine dritte unabhängige Meinung. Das erledigt
ssllabs.com/ssltest für uns.
Wertvoll in den SSLLabs-Reports sind hier nicht nur die Hinweise, welche Cipher Suiten verwendet werden sollen und welche nicht, sondern auch das Agent Probing im Abschnitt Handshake Simulation.
Der Beitrag Cipher Suites – welche sollte man wählen und welche meiden? erschien zuerst auf Tec-Bite.