it-swarm-eu.dev

Welcher Schlüsselaustauschmechanismus sollte in TLS verwendet werden?

Es gibt viele wichtige Austauschmechanismen, die in TLS verwendet werden können. Unter ihnen sind RSA, ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, ECDHE_RSA und andere. Welche davon sind kryptografisch sicherer und können zur Sicherung der Verbindung mit der Website verwendet werden?

31
Andrei Botalov

Sie dürfen einen Schlüsselaustausch (als Teil einer Verschlüsselungssuite) nur verwenden, wenn der Serverschlüsseltyp und das Zertifikat übereinstimmen. Um dies im Detail zu sehen, werfen wir einen Blick auf die in der TLS 1.2-Spezifikation definierten Cipher Suites. Jede Verschlüsselungssuite definiert den Schlüsselaustauschalgorithmus sowie die anschließend verwendeten Algorithmen für die symmetrische Verschlüsselung und Integritätsprüfung. Wir konzentrieren uns hier auf den Schlüsselaustausch.

  • RSA: Der Schlüsselaustausch erfolgt durch Verschlüsselung einen zufälligen Wert (vom Client ausgewählt) mit dem öffentlichen Serverschlüssel. Dies setzt voraus, dass der öffentliche Serverschlüssel ein RSA-Schlüssel ist, und dass das Serverzertifikat die Verschlüsselung nicht verbietet (hauptsächlich über die Zertifikatserweiterung "Key Usage"): Wenn diese Erweiterung vorhanden ist, muss sie enthalten das Flag "keyAgreement").

  • DH_RSA: Der Schlüsselaustausch ist ein statischer Diffie-Hellman: Der öffentliche Serverschlüssel muss ein Diffie-Hellman-Schlüssel sein. Darüber hinaus muss dieses Zertifikat von einer Zertifizierungsstelle ausgestellt worden sein, die selbst einen RSA-Schlüssel verwendet hat (der CA-Schlüssel ist der Schlüssel, der zum Signieren des Serverzertifikats verwendet wurde).

  • DH_DSS: wie DH_RSA, außer dass die Zertifizierungsstelle einen DSA-Schlüssel verwendet hat.

  • DHE_RSA: Der Schlüsselaustausch ist ein kurzlebiger Diffie-Hellman: Der Server generiert dynamisch einen öffentlichen DH-Schlüssel und sendet ihn an den Client. der Server auch Zeichen was er sendet. Für DHE_RSA muss der öffentliche Serverschlüssel vom Typ RSA sein und sein Zertifikat muss für Signaturen geeignet sein (die Erweiterung für die Schlüsselverwendung muss, falls vorhanden, das Flag digitalSignature enthalten).

  • DHE_DSS: wie DHE_RSA, außer dass der Serverschlüssel den Typ DSA hat.

  • DH_anon: Es gibt kein Serverzertifikat. Der Server verwendet einen Diffie-Hellman-Schlüssel, den er möglicherweise dynamisch generiert hat. Die "anon" -Cipher-Suites sind anfällig für Identitätswechsel-Angriffe (einschließlich, aber nicht beschränkt auf "Man in the Middle" ), da ihnen jede Art von Serverauthentifizierung fehlt. Im Allgemeinen dürfen Sie keine "anon" -Verschlüsselungssuite verwenden.

Schlüsselaustauschalgorithmen, die Kryptographie mit elliptischen Kurven verwenden, sind in einem anderen RFC angegeben und schlagen Folgendes vor:

  • ECDH_ECDSA: Wie DH_DSA, jedoch mit elliptischen Kurven: Der öffentliche Serverschlüssel muss ein ECDH-Schlüssel in einem Zertifikat sein, das von einer Zertifizierungsstelle ausgestellt wurde, die selbst einen öffentlichen ECDSA-Schlüssel verwendet hat.

  • ECDH_RSA: Wie ECDH_ECDSA, jedoch hat die ausstellende Zertifizierungsstelle einen RSA-Schlüssel.

  • ECDHE_ECDSA: Der Server sendet einen dynamisch generierten EC Diffie-Hellman-Schlüssel und signiert ihn mit einem eigenen Schlüssel, der den Typ ECDSA haben muss. Dies entspricht DHE_DSS, jedoch mit elliptischen Kurven sowohl für den Diffie-Hellman-Teil als auch für den Signaturteil.

  • ECDHE_RSA: Wie ECDHE_ECDSA, aber der öffentliche Serverschlüssel ist ein RSA-Schlüssel, der zum Signieren des Diffie-Hellman-Schlüssels mit kurzlebiger elliptischer Kurve verwendet wird.

  • ECDH_anon: eine "anon" -Verschlüsselungssuite mit dynamischer elliptischer Kurve Diffie-Hellman.


Also, was sollen Sie für eine Website wählen? Ihre Hauptbeschränkungen sind:

  • Sie möchten eine Verschlüsselungssuite, die von den meisten Clients unterstützt wird. In der Praxis schließt dies eine Kryptographie mit elliptischen Kurven aus (elliptische Kurven sind mächtig cool, werden aber im Feld noch nicht gut unterstützt - bedenken Sie, dass laut gs.statcounter ab September 2011 40% der Kunden Systeme verwenden immer noch Windows XP und fast 5% verwenden IE 7.0).

  • Sie möchten eine Verschlüsselungssuite, die mit Ihrem Serverschlüsseltyp und Zertifikat kompatibel ist. Dies hängt wiederum davon ab, was die Zertifizierungsstelle akzeptiert (die Zertifizierungsstelle, die Ihnen das Zertifikat verkauft hat). In 99,9% der Fälle bedeutet dies RSA. Jeder macht RSA. Diffie-Hellman-Schlüssel in Zertifikaten und DSA-Signaturen wurden früher von NIST (der US-Bundesbehörde, die sich mit solchen Angelegenheiten befasst) beworben, weil es ein Patent auf RSA gab. Dieses Patent lief jedoch im Jahr 2000 aus. Diffie-Hellman (als Teil von Zertifikaten) wird durch ANSI X9.42 spezifiziert, einen Standard, der nicht kostenlos ist (daher zögern OpenSource-Freizeitentwickler, ihn zu implementieren). und auch nicht so klar. Daher verwendet niemand Diffie-Hellman wirklich in Zertifikaten. DSA wird weiter unterstützt (sein definierender Standard ist kostenlos und gut lesbar), aber im Vergleich zu RSA nicht so anekdotisch.

  • Sie möchten keine "anon" -Suite verwenden, da dies gegen aktive Angreifer unsicher ist und die meisten Client-Browser die "anon" -Suiten standardmäßig deaktiviert haben.

Sie haben also grundsätzlich die Wahl zwischen "RSA" und "DHE_RSA". Letzteres kann einen etwas höheren Rechenaufwand verursachen, obwohl Sie mindestens einige hundert neue Verbindungen pro Sekunde benötigen würden, um tatsächlich einen Unterschied zu erkennen (ich bestehe auf dem "neuen": da TLS einen abgekürzten Handshake enthält, der auf dem aufbauen kann Schlüsselaustausch einer vorherigen Verbindung, der eigentliche Schlüsselaustausch mit asymmetrischer Kryptographie erfolgt nur einmal pro neuem Client-Browser in letzter Minute). In der Praxis gibt es also keinen messbaren Unterschied in der CPU-Auslastung zwischen RSA und DHE_RSA.

DHE_RSA bietet etwas, das als Perfect Forward Secrecy bekannt ist, einen pompösen Namen für die folgende Eigenschaft: Wenn Ihr Server gründlich gehackt wird, bis der Angreifer eine Kopie des privaten Schlüssels des Servers erhält, wird er dies auch tun in der Lage sein, Vergangenheit TLS-Sitzungen (die er aufgezeichnet hat) zu entschlüsseln, wenn diese Sitzungen RSA verwendeten, während er dies nicht tun kann, wenn diese Sitzungen DHE_RSA verwendeten. Wenn der Angreifer in der Praxis Ihren privaten Schlüssel stehlen könnte, könnte er wahrscheinlich die 10000 Kreditkartennummern in Ihrer Site-Datenbank lesen. Es gibt also kaum einen Grund, warum er sich überhaupt die Mühe machen sollte, frühere Sitzungen aufzuzeichnen und zu entschlüsseln, da dies nur ein Dutzend zusätzliche ergeben würde Zahlen oder so. PFS ist mathematisch elegant, aber überzeichnet. Wenn es immer noch ein schickes Akronym ist und im Rahmen einer gut durchdachten PR-Kampagne einen großen Eindruck auf die Schwachen hinterlassen kann.


Zusammenfassung: benutze DHE_RSA.

62
Thomas Pornin