[DE] Aktueller Stand kryptografischer Verfahren für Web-Applikationen

Abstract

Ausgehend von Empfehlungen für kryptografische Verfahren für Web-Applikationen auf Basis technischer Richtlinien des Bundesamt für Sicherheit in der Informationstechnik (BSI) werden diese anhand einer technischen Betrachtungsweise formuliert. Entsprechende Angriffe werden erläutert sowie Gegenmaßnahmen zum Mitigieren oder Abwehren beschrieben. Abschließend werden aus den Ergebnissen Maßnahmen für kryptografische Verfahren definiert, die einen sicheren Einsatz von Web-Applikationen gewährleisten.

Motivation und Gliederung

Durch die fortlaufende Digitalisierung sowie die sukzessive Verlagerung von Software als Web-Applikationen in die Cloud und dem damit verbundenen Hervorbringen einer neuen Angriffsfläche für Angreifer folgt die zunehmende Notwendigkeit zur Nutzung aktueller und sicherer kryptografischer Verfahren. Drei hiermit in Zusammenhang stehende Leitfragen werden im Laufe dieses Artikels ausgeführt und beantwortet.

1. „Welche kryptografischen Verfahren und Protokolle gelten als aktuell und sicher und stehen mit Web-Applikationen unvermeidbar in Zusammenhang?“
2. „Wie können Schwachstellen, die auf kryptografischen Algorithmen basieren und für Web-Applikationen eingesetzt werden identifiziert werden?“
3. „Gibt es bekannte Angriffe auf die vorgestellten kryptografischen Algorithmen und mögliche Mitigationen oder Möglichkeiten diese abzuwehren?“

Rahmenbedingungen

Im Rahmen dieses Artikels kann keine vollumfängliche Vorstellung aller mit Web-Applikationen in Zusammenhang stehenden kryptografischen Algorithmen durchgeführt werden. Folglich wird ein Einblick in die wichtigsten und aktuell als sicher geltenden Protokolle und kryptografischen Verfahren gegeben. Hierfür stellt das BSI die Serie technischer Richtlinien BSI TR-02102 Kryptographische Verfahren: Empfehlungen und Schlüssellängen bereit, aus welchen die für Web-Applikationen relevanten Verfahren extrahiert werden können.

Auch werden die angesprochenen Angriffe nicht im Detail erklärt sondern lediglich eine Übersicht dieser Abwehrmaßnahmen aufgezeigt. Handelt es sich bei einem Angriff um einen auf aktuell als sicher geltende Verfahren, werden zusätzlich Gegenmaßnahmen aufgezeigt.

Protokolle

Zu Beginn wird auf den verschlüsselten Datenaustausch bei Web-Applikationen eingegangen. Hierfür werden das Hypertext Transfer Protocol (HTTP) sowie das Hypertext Transfer Protocol Secure (HTTPS) und die Transport Layer Security (TLS) betrachtet. Weiter werden die Grundlagen der TLS-Versionen 1.2 und 1.3 und die damit in Verbindung stehenden Cipher Suites beschrieben. Abschließend wird eine kurze Übersicht über aktuell als sicher eingestufte Cipher Suites gegeben, die die Grundlage des sicheren verschlüsselten Datenaustausches bilden.

HTTP und HTTPS

Bei einer HTTP-Verbindung erfolgt der Datenaustausch bei Web-Applikationen zwischen Server und Client sowie konträr grundlegend unverschlüsselt. Einem Angreifer ist es also möglich, den gesamten Netzwerkverkehr durch Software wie Wireshark mitzuschneiden und auszulesen. Folglich kann weder die Integrität noch die Vertraulichkeit von Daten sichergestellt werden, da Pakete von Dritten umstandslos verändert werden können. Mit der Nutzung von HTTPS erfolgt der Datenaustausch verschlüsselt. Die Verschlüsselung wird dabei mithilfe von TLS durchgeführt. Bei TLS handelt es sich um den Nachfolger des Secure Socket Layer (SSL), der seit Juni 2015 [2] veraltet ist und dessen Nutzung somit unzulässig ist. Die Funktionsweise von TLS wird im Folgenden beschrieben.

TLS

Seit der Einführung von TLS im Jahr 1999 [1] wurden einige Versionen des Protokolls veröffentlicht sowie unterschiedliche Schwachstellen dieser gefunden. Dies bedeutet, dass die Nutzung von TLS im Allgemeinen nicht die Implementierung eines sicheren kryptografischen Protokolls impliziert. Im März 2021 wurde die Nutzung von TLS 1.0 und TLS 1.1 durch RFC 8996 [7] offiziell als unzulässig definiert. TLS ist aktuell in zwei zulässigen Versionen verfügbar. TLS 1.2, publiziert im August 2008 und definiert in RFC 5246 [11] sowie TLS 1.3, publiziert im August 2018 und definiert in RFC 8446 [10].

Grundlage der verschlüsselten Verbindung sind Cipher Suites. Dabei handelt es sich um einen Satz von Algorithmen zur Durchführung von verschiedenen kryptografischen Funktionen wie beispielsweise dem Verschlüsseln, Entschlüsseln, Hashen oder Erstellen digitaler Signaturen. Hierfür werden folgende vier Algorithmen-Typen durch eine Cipher Suite definiert:

1. Schlüsselaustausch-Algorithmus
2. Authentifizierungs-Algorithmus
3. Verschlüsselungs-Algorithmus
4. Hashfunktion / Message Authentication Code (MAC)-Funktion

Der Schlüsselaustausch-Algorithmus definiert wie die symmetrischen Schlüssel zwischen Server und Client ausgetauscht werden. Beispiele für einen solchen Algorithmus sind Rivest–Shamir–Adleman (RSA), Diffie-Hellman (DH), Elliptic Curve Diffie–Hellman (ECDH) sowie der Elliptic Curve Diffie–Hellman Ephemeral (ECDHE). Der Authentifizierungs-Algorithmus legt fest wie die Server- und Client-Authentifizierung (falls diese erforderlich ist) durchgeführt wird. Beispiele hierfür sind RSA, der Digital Signature Algorithm (DSA) sowie der Elliptic Curve Digital Signature Algorithm (ECDSA). Der Verschlüsselungs-Algorithmus (in englisch auch oftmals als Bulk encryption algorithm bezeichnet) definiert den Algorithmus, mit dem die tatsächlichen Daten, die zwischen Server und Client ausgetauscht werden, verschlüsselt werden. Hierunter zählen Verschlüsselungs-Algorithmen wie der Advanced Encryption Standard (AES), Camellia und ChaCha20. Zuletzt definiert die Hashfunktion beziehungsweise MAC-Funktion den Algorithmus, der die Integrität der verschlüsselten Verbindung sicherstellt. Beispiele hierfür sind aus der Gruppe der Secure Hash Algorithm 2 (SHA-2) die Hashfunktionen SHA-256 und SHA-384 [15].

Die Verwendung von Cipher Suites ist aber nicht auf HTTPS begrenzt, auch andere Protokolle die durch TLS abgesichert werden nutzen diese. Darunter File Transfer Protocol over TLS (FTPS) sowie Simple Mail Transfer Protocol Secure (SMTPS) und Internet Message Access Protocol Secure (IMAPS) für den E-Mail-Verkehr [14].

TLS 1.2

Mit der Einführung von TLS 1.2 wurden 37 Cipher Suites definiert [11]. Diese haben den Aufbau TLS_KeyExch_Auth_WITH_Enc_Hash, wobei die kursiv geschriebenen Abkürzungen Platzhalter für die zuvor beschriebenen Algorithmen sind. Neben den mit der Veröffentlichung definierten Cipher Suites wurden weitere durch entsprechende Request for Comments (RFC) festgelegt. Die Anzahl aller beläuft sich aktuell auf rund 300 Stück. Hierbei ist anzumerken, dass nur ein kleiner Teil davon sicher und vor allem durch die Internet Assigned Numbers Authority (IANA) zur Nutzung empfohlen ist [15]. Neben der IANA publiziert wie bereits eingeleitet auch das BSI in der Reihe technischer Richtlinien TR-02102 Empfehlungen zur Schlüssellänge von kryptografischen Verfahren, welche aber schwächer hinsichtlich ihrer Sicherheit definiert sind. So rät die IANA von Cipher Suites im allgemeinen ab, welche das BSI unter bestimmten Voraussetzungen noch empfiehlt. Ein Beispiel hierfür wäre die Cipher Suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 die nach Empfehlung des BSI bis mindestens in das Jahr 2028, gegebenenfalls länger, unter Berücksichtigung der Verwendung der TLS-Erweiterung „Encrypt-then-MAC“ aufgrund des Cipher Block Chaining (CBC)-Modus weiterhin empfohlen ist [3].

Wie bereits erwähnt beinhalten Cipher Suites verschiedene Typen von Algorithmen. Eine häufig in TLS 1.2 genutzte Cipher Suite ist TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. Dabei bezeichnet ECDHE den Austausch der Schlüssel während des TLS-Handshakes mithilfe des auf einer elliptischen Kurve basierenden ephemeralen Diffie-Hellman-Schlüsselaustausches. Die Nutzung eines „ephemeralen“ Diffie-Hellman-Schlüsselaustausches sorgt durch die Perfect Forward Secrecy (PFS) für weitere Sicherheit hinsichtlich der Sicherstellung der Geheimhaltung auch nach Bekanntwerden des Hauptschlüssels. ECDSA beschreibt den auf einer elliptischen Kurve basierenden digitalen Signaturalgorithmus (Authentifizierungs-Algorithmus) DSA. AES_256_GCM beschreibt die Nutzung von AES mit einem 256 Bit-Schlüssel im Galois Counter Mode (GCM). Der GCM berechnet wie in [9] beschrieben neben der eigentlichen Verschlüsselung auch einen MAC. Was an dieser Stelle dazu führt, dass es sich nicht um eine Verschlüsselung im eigentlichen Sinne handelt sondern um eine authentifizierte Verschlüsselung, die eine Nachrichtenauthentizität sowie eine Nachrichtenintegrität mitsichbringt [9]. Abschließend beschreibt SHA384 die für die Verbindung genutzte Hashfunktion. Die beispielhaft vorgestellte Cipher Suite wird so, ohne Einschränkung von der IANA [15] und dem BSI [3] empfohlen.

TLS 1.3

TLS 1.3 bringt im Vergleich zu TLS 1.2 einige Neuerungen sowie Anpassungen bezüglich der standardmäßigen Sicherheit, die in RFC 8446 beschrieben sind [10]. So enthält die Liste der symmetrischen Verschlüsselungs-Algorithmen nur noch Authenticated Encryption with Associated Data (AEAD)-Algorithmen. Weiter wurden alle statischen RSA- und Diffie-Hellman Cipher Suites abgeschafft sowie die Verpflichtung zur Nutzung der PFS definiert. Daraus resultierend die Entfernung des RSA-Schlüsselaustausches, der diese nicht unterstützt. Auch sind zum Erhöhen der Vertraulichkeit alle Handshake-Verbindungsdaten nach dem ServerHello verschlüsselt. Abschließend wurden auch elliptische Kurven-Algorithmen in die Basis-Definition von TLS 1.3 in RFC 8446 aufgenommen [10].

Wie bereits erwähnt existieren für TLS 1.2 ungefähr 300 verschiedene Cipher Suites, bei welchen für einen Großteil die Nutzung nicht empfohlen wird. Mit der Einführung von TLS 1.3 wurde durch die Definition von lediglich fünf Cipher Suites die Möglichkeit auf die Nutzung schwacher Algorithmen sowie versehentlicher Fehlkonfigurationen durch Administratoren entgegengewirkt. Die folgenden Cipher Suites sind die in RFC 8446 definierten [10].

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

Es fällt auf, dass diese kürzer sind als jene von TLS 1.2. Dies liegt darin begründet, dass sowohl der Schlüsselaustausch-Algorithmus als auch der Authentifizierungs-Algorithmus kein Teil der Cipher Suite mehr sind. Es folgt der Aufbau TLS_AEADCM¹_Hash, wobei die Definition dieser analog zu TLS 1.2 verläuft.

Nachdem die grundlegende kryptografische Funktion sowie die für die Sicherstellung der Vertraulichkeit, Integrität und Authentizität benötigten Protokolle, die den aktuellen Standards entsprechen, vorgestellt wurden, folgen im nächsten Abschnitt Möglichkeiten zum Identifizieren von Schwachstellen. In diesem Kontext wird auf schwache Cipher Suites und folglich unsichere Verbindungen eingegangen sowie eine Übersicht zu Angriffen auf SSL und TLS gegeben.

Identifizierung von Schwachstellen

Bei der Identifizierung von Schwachstellen ist der Open Web Application Security Project (OWASP) Web Security Testing Guide (WSTG) eine der Referenzliteraturen, welche sich wie folgt selbst beschreibt:

„The Web Security Testing Guide (WSTG) Project produces the premier cybersecurity testing resource for web application developers and security professionals.

The WSTG is a comprehensive guide to testing the security of web applications and web services. Created by the collaborative efforts of cybersecurity professionals and dedicated volunteers, the WSTG provides a framework of best practices used by penetration testers and organizations all over the world.“ [8]

Der OWASP WSTG wurde am 03.12.2020 in der Version 4.2 veröffentlicht und stellt für einen Großteil von Web-Applikationen Anleitungen und Hinweise zum Testen dieser bereit. Im Folgenden wird auf die Identifizierung schwacher Cipher Suites, die Prüfung auf strikte HTTPS-Verwendung und das Kontrollieren unsicherer digitaler Zertifikate eingegangen.

Schwache Cipher Suites

Der OWASP WSTG empfielt in WSTG-CRYP-04 bei der Identifizierung schwacher Cipher Suites bei Vorliegendem Quelltext der Anwendung oder einer generierten Liste von unterstützen Cipher Suites die Suche nach unter anderem den folgenden Algorithmen: MD5, RC2, RC4, DES, CBC, und SHA-1 [16]. Die von einem Server zur Verfügung gestellten Cipher Suites lassen sich mit einem Tool wie sslscan auslesen [13].

Eine Verwendung dieser Algorithmen sollte keines Falles stattfinden. Hierbei handelt es sich um teilweise gebrochene Hashfunktionen sowie Verschlüsselungen, für die bereits Angriffe veröffentlicht wurden.

Strikte Verwendung von HTTPS

Neben der Sicherstellung zur Nutzung sicherer Cipher Suites muss natürlich auch auf die strikte Verwendung von HTTPS und die Verwendung aktueller Protokolle wie TLS 1.2 und TLS 1.3 geachtet werden. Die Prüfung auf die permanente Nutzung von HTTPS kann wie in WSTG-CRYP-01 durch den Strict-Transport-Security-Header geprüft werden. Dieser teilt dem Client mit, dass der entsprechende Server nur über HTTPS angesprochen werden möchte. Folglich ist dieser Weg zudem sicherer als die permanente Weiterleitung von HTTP zu HTTPS mithilfe eines 301 Moved Permanently [17].

Unsichere digitale Zertifikate

Letztlich empfiehlt OWASP in seinem WSTG in WSTG-CRYP-01 auch die Prüfung von digitalen Zertifikaten auf eine sichere Parameterwahl. Hierunter fallen die minimale Schlüsselbitlänge von 2048 Bits sowie die Nutzung eines sicheren Signaturalgorithmuses wie beispielsweise SHA-256. Algorithmen wie MD5 und SHA-1 sollten keines Falles genutzt werden [17].

Einem Team von Sicherheitsforschern des CWI Amsterdam und Google Research ist es im Jahr 2017 gelungen, Secure Hash Algorithm (SHA-1) in der Praxis zu brechen. Hierfür wurden zwei unterschiedliche PDF-Dateien erstellt, die auf denselben SHA-1-Hash abbilden. Offiziell als veraltet eingestuft wurde SHA-1 bereits im Jahr 2011 durch das National Institute of Standards and Technology (NIST) aufgrund einiger theoretischer Angriffe auf den Algorithmus [12].

Angriffe auf TLS

Viele Angriffe gegen SSL und TLS waren bei Versionen möglich, die inzwischen als veralteten gekennzeichnet sind. So existiert für SSL 2.0 der DROWN-Angriff, für SSL 3.0 der Padding Oracle On Downgraded Legacy Encryption (POODLE)-Angriff und für TLS 1.0 der Browser Exploit Against SSL/TLS (BEAST)-Angriff [17]. Auch für TLS 1.2 gibt es einen Angriff, der es ermöglicht, mit TLS verschlüsselte HTTP-Verbindungen zu entschlüsseln.

Lucky13

Lucky13 wurde bereits im Jahr 2013 gefunden und ist eine Seitenkanalattacke, die das Zeitverhalten beim Entschlüsseln von TLS-Nachrichten ausnutzt. Nach Angabe der Forscher sind alle Cipher Suites, die eine CBC-Verschlüsselung enthalten, potenziell für diesen Angriff anfällig [6].

Auch das BSI geht in seiner technischen Richtlinie BSI-TR-02102-2 auf Lucky13 ein [3]. Weiter werden Maßnahmen genannt, die einen solchen Angriff abwehren können. Darunter die Nutzung von einer Authenticated Encryption wie beispielsweise AES-GCM oder AES-CCM oder die Nutzung der TLS-Erweiterung „Encrypt-then-MAC“ die in RFC 7366 [4] spezifiziert wurde. Neben diesen Maßnahmen kann auch die Verwendung von TLS 1.3 diesen Angriff abwehren, da es bei dieser TLS-Version keine Cipher Suites gibt, die den CBC-Modus einsetzen.

Weitere Angriffe

Neben Angriffen gegen das Protokoll existieren auch Angriffe gegen die Implementierung des Protokolls in Form von Software.

Mit einer der bekanntesten ist der als CVE-2014-0160 gekennzeichnete Heartbleed Bug, der auf einen Implementierungsfehler in OpenSSL zurückgeht und das Auslesen des Arbeitsspeichers des Servers ermöglicht hat [5].

Fazit und Zukunftsperspektiven

Die durch diesen Artikel aufgezeigten Schwachstellen und Angriffsmöglichkeiten gegen kryptografische Verfahren geben einen guten Einblick in die Komplexität von sicheren Systemen. Bei der Prüfung von TLS 1.2 kann der OWASP WSTG als Referenzliteratur genutzt werden, um Systeme auf aktuelle kryptografische Algorithmen zu prüfen. Es sollten keine veralteten Algorithmen ausgewählt werden und aktuelle Software eingesetzt werden, die veröffentliche Implementierungsfehler bereits geschlossen hat.

TLS 1.3 hat es Entwicklern und Administratoren bereits durch die Limitierung der Cipher Suites auf fünf Stück einfacher gemacht, Konfigurationsfehler zu vermeiden. Abschließend sollte eine Nutzung von TLS 1.3 angestrebt werden.

---

Fußnoten

1. AEAD Cipher Mode ↩︎

---

Literatur

[1] Christopher Allen und Tim Dierks. The TLS Protocol Version 1.0. Request for Comments RFC 2246. Num Pages: 80. Internet Engineering Task Force, Jan. 1999. doi: 10.17487/RFC2246. url: https://datatracker.ietf.org/doc/rfc2246 (besucht am 27. 04. 2022).

[2] Richard Barnes u. a. Deprecating Secure Sockets Layer Version 3.0. Request for Comments RFC 7568. Num Pages: 7. Internet Engineering Task Force, Juni 2015. doi: 10.17487/RFC7568. url: https://datatracker.ietf.org/doc/rfc7568 (besucht am 26. 04. 2022).

[3] BSI TR-02102-2 „Kryptographische Verfahren: Verwendung von Transport Layer Security (TLS)“ Version: 2022-1. Bundesamt für Sicherheit in der Informationstechnik. url: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.html?nn=132646 (besucht am 26. 04. 2022).

[4] Peter Gutmann. Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Request for Comments RFC 7366. Num Pages: 7. Internet Engineering Task Force, Sep. 2014. doi: 10.17487/RFC7366. url: https://datatracker.ietf.org/doc/rfc7366 (besucht am 18. 05. 2022).

[5] Heartbleed Bug. url: https://heartbleed.com/ (besucht am 18. 05. 2022).

[6] Lucky Thirteen: Breaking the TLS and DTLS Record Protocols. http://www.isg.rhul.ac.uk/tls/Lucky13.html (besucht am 27. 04. 2022).

[7] Kathleen Moriarty und Stephen Farrell. Deprecating TLS 1.0 and TLS 1.1. Request for Comments RFC 8996. Num Pages: 18. Internet Engineering Task Force, März 2021. doi: 10.17487/RFC8996. url: https://datatracker.ietf.org/doc/rfc8996 (besucht am 16. 05. 2022).

[8] OWASP Web Security Testing Guide | OWASP Foundation. url: https://owasp.org/www-project-web-security-testing-guide/ (besucht am 26. 04. 2022).

[9] Christof Paar und Jan Pelzl. Kryptografie verständlich. eXamen.press. Berlin, Heidelberg: Springer Berlin Heidelberg, 2016. isbn: 978-3-662-49296-3 978-3-662-49297-0. doi: 10.1007/978-3-662-49297-0. url: http://link.springer.com/10.1007/978-3-662-49297-0 (besucht am 17. 05. 2022).

[10] Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3. Request for Comments RFC 8446. Num Pages: 160. Internet Engineering Task Force, Aug. 2018. doi: 10.17487/RFC8446. url: https://datatracker.ietf.org/doc/rfc8446 (besucht am 26. 04. 2022).

[11] Eric Rescorla und Tim Dierks. The Transport Layer Security (TLS) Protocol Version 1.2. Request for Comments RFC 5246. Num Pages: 104. Internet Engineering Task Force, Aug. 2008. doi: 10.17487/RFC5246. url: https://datatracker.ietf.org/doc/rfc5246 (besucht am 26. 04. 2022).

[12] SHAttered. url: https://shattered.io/ (besucht am 18. 05. 2022).

[13] sslscan | Kali Linux Tools. Kali Linux. url: https://www.kali.org/tools/sslscan/ (besucht am 17. 05. 2022).

[14] TLS – Transport Layer Security. url: https://www.elektronik-kompendium.de/sites/net/1706131.htm (besucht am 17. 05. 2022).

[15] Transport Layer Security (TLS) Parameters. url: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml (besucht am 26. 04. 2022).

[16] WSTG – v4.2 | OWASP Foundation. url: https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/04-Testing_for_Weak_Encryption (besucht am 17. 05. 2022).

[17] WSTG – v4.2 | OWASP Foundation. url: https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security (besucht am 17. 05. 2022).

---

Pius Walter