SSL sicher konfigurieren – The Magic of Secure Channel Configuration


Wir möchten die kürzlich bekannt gewordene DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) Attacke zum Anlass nehmen, ein wenig Licht in den Dschungel der Empfehlungen bezüglich SSL, TLS und Cipher Suites zu bringen.

Eine kurze Geschichte der SSL bzw. TLS Schwachstellen (ab dem Jahr 2011)

October 2011: BEAST. “…Two researchers recently discovered a known vulnerability that existed in CBC based ciphers, but was considered theoretically impractical, until then. This vulnerability exists in all CBC based ciphers used in SSL V3/TLS 1.0”

https://blogs.msdn.microsoft.com/kaushal/2011/10/03/taming-the-beast-browser-exploit-against-ssltls/

https://blogs.msdn.microsoft.com/kaushal/2012/01/20/fixing-the-beast/

Details zu CBC finden Sie im Abschnitt “Fachsimpeleien”

 

November 2013: “…Microsoft is recommending that customers enable TLS 1.2 in their services and take steps to retire and deprecate RC4 as used in their TLS implementations. Microsoft recommends TLS 1.2 with AES-GCM as a more secure alternative which will provide similar performance…”

https://blogs.technet.microsoft.com/srd/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4/

Details zu GMC finden Sie im Abschnitt “Fachsimpeleien”.

 

October 2014: “…POODLE exploits design flaws of SSL 3.0…”

https://technet.microsoft.com/library/security/3009008.aspx

https://blogs.msdn.microsoft.com/kaushal/2014/10/22/poodle-vulnerability-padding-oracle-on-downgraded-legacy-encryption/

 

May 2015: „Logjam…The vulnerability could allow information disclosure when Secure Channel (Schannel) allows the use of a weak Diffie-Hellman ephemeral (DHE) key length of 512 bits in an encrypted TLS session. Allowing 512-bit DHE keys makes DHE key exchanges weak and vulnerable to various attacks. A server needs to support 512-bit DHE key lengths for an attack to be successful; the minimum allowable DHE key length in default configurations of Windows servers is 1024 bits….“

https://technet.microsoft.com/en-us/library/security/ms15-055.aspx?f=255&MSPPError=-2147217396

 

Und schließlich wurde im März 2016 die sogenannte DROWN Attacke publik. Diese Schwachstelle basiert darauf, dass der Angreifer zunächst viele hundert Verbindungen zwischen dem Opfer und dem Web Server aufzeichnen muss. Diese Verbindungen können selbst auf TLS 1.2 basieren, solange die weit verbreitete RSA Methode zum Schlüsselaustausch verwendet wird. Anschließend verbindet sich der Angreifer über SSL 2.0 mit dem Web Server und schickt spezielle Handshake Nachrichten wobei die verschlüsselte Nachricht des Opfers modifiziert wird. Aus der Art der Antwort des Servers kann der Angreifer erkennen ob seine gefälschte Nachricht vom Server akzeptiert wird, wodurch der Angreifer Rückschlüsse auf den privaten Schlüssel des Web Servers tätigen kann. Die Anzahl der dafür notwendigen Versuche beläuft sich lt. den Entdeckern des Angriffs auf 40.000 Verbindungen mit 250 Tests um eine von 900 TLS Verbindungen entschlüsseln zu können.

Fachsimpeleien

Um die Schwachstellen im Detail verstehen zu können, lässt es sich nicht vermeiden sich ein wenig mit den Protokollen SSL und TLS zu beschäftigen. Einen sehr ausführlichen Artikel hierzu finden Sie auf https://technet.microsoft.com/de-de/library/cc783349%28WS.10%29.aspx?f=255&MSPPError=-2147217396

Zum Thema SSL bzw. TLS Handshake: https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/

Aufgrund der verfügbaren detaillierten Information möchten wir uns hier auf eine kurze Zusammenfassung der wichtigsten Punkte beschränken:

TLS (Transport Layer Security) ist der Nachfolger von SSL (Secure Socket Layer), auch wenn in vielen Fällen beide Protokolle fälschlicherweise gleichgesetzt bzw. als Synonym füreinander verwendet werden. Weite Verbreitung finden die folgenden Versionen: SSL 2.0, SSL 3.0, TLS 1.0 (SSL 3.1), TLS 1.1 (SSL 3.2) sowie TLS 1.2 (SSL 3.3). Wobei für sämtliche Versionen mit Ausnahme von TLS 1.2 unter gewissen Bedingungen Schwachstellen bekannt sind.

Diese „gewissen Bedingungen“ beziehen sich auf die zwischen Client und Web Server vereinbarten Cipher Suites. Im Zuge eines SSL/TLS Verbindungsaufbaus gibt es nämlich ein paar mehr Details auszuhandeln als alleine die zum Einsatz kommende Protokollversion. Eine Cipher Suite beinhaltet eine Kombination aus Schlüsselaustauschverfahren (Key Exchange), Verschlüsselungsalgorithmus und Verfahren zur Sicherstellung der Datenintegrität (MAC). Und für jeden der genannten Punkte steht eine Vielzahl an Optionen zur Verfügung. Der Client schickt dazu einfach eine Liste der von ihm unterstützten Cipher Suites and den Web Server und woraufhin dieser eine auswählt, die von ihm selbst ebenfalls unterstützt wird.

Cipher Suites sehen z.B. wie folgt aus: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256

Wobei…

  • ECDH_RSA – für Elliptic Curve Diffie-Helmann, also den Mechanismus für den Austausch des symmetrischen Schlüssels steht und der RSA Algorithmus für die Authentifizierung des Systems und den Schutz der ECDH Kommunikation zum Einsatz kommt.
  • AES 128 CBC – den symmetrischen Algorithmus für das Verschlüsseln der großen Datenmengen darstellt, wobei CBC für Cipher-Block Chaining steht und eine Betriebsart ist in der Blockchiffren betrieben werden können – genaue Erklärung siehe CBC!SHA 256 – steht für den Hashalgorithmus, dessen Ergebnisse (auch „Digests“ genannt) schließlich – in diesem Fall – mit RSA signiert werden.
  • SHA 256 – im Zusammenhang mit einem HMAC (siehe unten) verwendet wird

CBC (Cipher Block Chaining) beschreibt eine Methode der Blockchiffren, bei der die Verschlüsselung in Blöcken von gleicher Grösse erfolgt. Hierbei wird der jeweilige Ergebnisblock (Cipherblock) als Inputvector für die Verschlüsselung des nächsten Blocks verwendet, d.h. der Klartext wird mit dem Initilization Vector (IV) im ersten Block und dem verschlüsselten Text des vorhergehenden Blocks XOR’d (Exclusive OR), bevor die Verschlüsselung stattfindet. Der IV soll jede Nachricht eindeutig machen und hier entsteht auch das Problem. Aufgrund der Tatsache, dass der verschlüsselte Text des vorhergehenden Blocks als IV verwendet wird, geht die Eindeutigkeit des IV verloren und die Möglichkeit für sog. „Known Plaintext“ Angriffe entsteht.

HMAC (Key-Hashed Message Authentication Code) definiert eine spezielle Form eines MAC (Message Authentication Code), welcher eine kryptografische Hash Funktion (z.B. SHA256) in Kombination mit einem geheimen Schlüssel, einsetzt.

Für die Erklärung von XOR greife ich auf Wikipedia zurück: „Die zu verschlüsselnde Nachricht (Klartext) wird dazu zuerst als Bitfolge kodiert. Eine zweite zufällige Bitfolge, die genauso lang wie die Nachricht ist, wird als Schlüssel verwendet. Der Geheimtext entsteht, indem das erste Bit der Nachricht mit dem ersten Bit des Schlüssels XOR-verknüpft wird, das zweite Bit mit dem Zweiten und so weiter. Führt man anschließend die gleiche XOR-Verknüpfung mit dem Geheimtext und dem Schlüssel aus, so erhält man wieder die ursprüngliche Nachricht.“ Quelle: https://de.wikipedia.org/wiki/XOR-Gatter

5001.clip_image001_58A2C10B

Abbildung: Verschlüsselung im CBC Mode, Quelle: https://blogs.msdn.microsoft.com/kaushal/2011/10/03/taming-the-beast-browser-exploit-against-ssltls/

Die Alternative zu CBC stellt GCM (Galois/Counter Mode) dar. GMC beschreibt eine Methode der Blockchiffren, für die Verwendung von symmetrischen Verschlüsselungen. Eine der signifikanten Eigenschaften ist der authentifizierte Verschlüsselungsmode. Hierbei wird neben „Vertraulichkeit“ auch „Integrität“ und „Authentizität“ sichergestellt. Ein weiterer Unterschied zum schon erwähnten Cipher Block Chaining ist die Verwendung des Counter Modes (CTR) innerhalb von GCM. Hierbei wird ein initialer Counter (128bit) mit einem NONCE Wert verknüpft. Der Counter wird für jeden Block um Eins erhöht und der NONCE Wert neu gebildet. Der so generierte Ergebnisblock wird nicht wieder als Input verwendet. Aufgrund der Performance dieser Methode eignet sich GCM zur Echzeitverschlüsselung von Netzwerkverkehr.

GCM

Quelle: https://de.wikipedia.org/wiki/Galois/Counter_Mode

Konfiguration in Windows

SSL bzw. TLS werden in Windows von einer zentralen Betriebssystemkomponente namens Secure Channel (Schannel) zur Verfügung gestellt und von zahlreichen Komponenten wie z.B. IE bzw. Edge, IIS aber auch dem 802.1x Supplicant genützt. Details zur Architektur von Schannel finden Sie in diesem Artikel: https://technet.microsoft.com/en-us/library/dn786429.aspx?f=255&MSPPError=-2147217396

Konkret geht es um folgenden Registry Keys:

HKLM\SYSTEM\CurrentControSet\Control\Security Providers\Schannel\Protocols

Hier bietet das Betriebssystem die Möglichkeit die unterstützen SSL bzw. TLS Protokolle zu definieren. Bitte beachten Sie, dass es Sache der Anwendung ist ob die hier gesetzten Parameter berücksichtigt werden und dass die Keys standardmäßig nicht vorhanden sind, d.h. alle Protokolle ab SSL 2.0 standardmäßig unterstützt werden. Unterhalb des Keys für ein Protokoll kann es wiederum Keys für Client und Server geben. Der Key „Server“ wirkt auf Server-Anwendungen (z.B. IIS), während der Key „Client“ Auswirkungen auf Client-Anwendungen hat. Edge berücksichtigt diese Einstellungen, der IE – als Dinosaurier unter den Anwendungen – geht jedoch seinen eigenen Weg (die Konfiguration erfolgt stattdessen in Tools à Internet Options à Advanced à Security).

HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL0010002

HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL0010002

Diese beiden Registry Keys definieren die Reihenfolge in der die Cipher Suites bei der SSL Negotiation ausgewählt werden sollen. Der obere Registry Key definiert hierbei die lokale Registry Einstellung, der untere die GPO Lokation (Administrative Templates\Network\SSL Configuration Settings).

Die folgende Liste der unterstützten Cipher Suites gilt daher betriebssystem-weit bzw. für alle Komponenten, die Schannel eben nutzen: https://msdn.microsoft.com/en-us/library/windows/desktop/aa374757 sowie die Ergänzungen für Windows 8.1 bzw. Server 2012 R2 (v=vs.85).aspx https://support.microsoft.com/en-us/kb/2929781

Die Firma Nartac hat ein Tool veröffentlicht, welches die Konfiguration mit Hilfe einer GUI ermöglicht: https://www.nartac.com/Products/IISCrypto/

Empfehlungen aus Perspektive der Sicherheit, Kompatibilität und Performance

Spätestens seit der Veröffentlichung der BEAST Attacke im Jahr 2011 wird die Verwendung von AES-GCM statt AES-CBC empfohlen. Von der Unterstützung sämtlicher SSL Versionen wird ohnehin dringend abgeraten, ja sogar TLS 1.0 und TLS 1.1 ist von einigen der Attacken betroffen. Bleibt also nur TLS 1.2. Auch die Verschlüsselungsalgorithmen RC4 und DES bzw. 3DES gelten längst nicht mehr als sicher. Schließlich kommen noch spezielle Technologien wie Perfect Forward Secrecy (PFS) oder HTTP Strict Transportation Security (HSTS) hinzu, denen wir einen eigenen Artikel widmen werden.

Soweit die Theorie, in der Praxis kommen jedoch die Aspekte Kompatibilität und Performance hinzu. Welcher Betreiber einer Website möchte riskieren, dass potentielle Kunden seine Seite nicht mehr besuchen können weil sich Client und Server auf keine Cipher Suite einigen können? Umgekehrt möchte wohl auch kaum ein Administrator einer Umgebung Beschwerden der Benutzer provozieren, wenn diese nicht mehr ungehindert im Internet auf verschlüsselte Webseiten zugreifen können. Ähnliches gilt wohl auch für die Hersteller der Browser und Web Server Software: wer möchte sich denn schon nachsagen lassen ein nicht mit allen verschlüsselten Webseiten kompatibles Produkt herauszubringen? Bedenken Sie auch, dass die Konfiguration der Protokolle und Cipher Suites nicht nur Auswirkungen auf IIS und den Browser hat, sondern auf sämtliche Schannel Applikationen wie z.B. den 802.1x Supplicant.

Auch der Aspekt der Last auf Seiten des Servers sollte nicht unbeachtet bleiben: so hat z.B. die Länge des asymmetrischen Schlüssels im Zertifikat des Web Servers bei oben erwähnter Cipher Suite Einfluss auf die Geschwindigkeit des ECDH Schlüsselaustausches und somit auf die zu erwartende Rechenlast des Servers.

Einen sehr empfehlenswerten Artikel hat auch das Microsoft Exchange Team veröffentlicht: http://blogs.technet.com/b/exchange/archive/2015/07/27/exchange-tls-amp-ssl-best-practices.aspx

Fazit

Eine generelle Empfehlung für sämtliche Anwendungsbereiche geben zu können, ist leider unmöglich. In jedem Fall sollte danach gestrebt werden sämtliche SSL Versionen sowie TLS 1.0 zu deaktivieren. Von Verschlüsselungsalgorithmen wie RC4 und DES bzw. 3DES ist ebenso abzuraten.

Am Ende des Tages bleibt Security jedoch ein Prozess bei dem es darum geht, das verbleibende Risiko zu optimieren.

 

Comments (2)
  1. Gunnar sagt:

    Sowohl unter Fachsimpeleien als auch im Abschnitt Performance wird irreführenderweise davon gesprochen, dass “die Pakete” mittels RSA signiert werden würden. Als Leser könnte man nun annehmen, dass damit der TLS-Traffic gemeint wäre. Das ist nicht der Fall. Wenn RSA wie im gewählten Beispiel TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 zum Einsatz kommt, dann nicht für das Signieren der Pakete, sondern nur für die Authentifizierung der Gegenstelle während des TLS-Handshakes. Wenn für die Sicherung der Integrität SHA256 wie im gewählten Beispiel zur Anwendung kommt, so wird hierfür im Falle von CBC ein SHA256-HMAC und nicht SHA256-RSA wie man irreführenderweise annehmen könnte verwendet, im Falle von GCM wird die Integrität und Authentizität ohnehin mittels AEAD gewährleistet.

    1. Vielen Dank für den Hinweis! Da habe ich in meinem Eifer die Komplexität von TLS einfach darzustellen, zu sehr “vereinfacht”. Ich habe die entsprechenden Stellen überarbeitet.

Comments are closed.