Sichere Kommunikation im Netz mit Zertifikaten: Albtraum oder etablierte Technik? Dr. Simon Hoff,

Transkript

1 Sichere Kommunikation im Netz mit Zertifikaten: Albtraum oder etablierte Technik? Dr. Simon Hoff,

2 Inhalt Funktionsweise und Anwendungen von Zertifikaten Kernelement Publik Key Infrastructure (PKI) Fallstricke von der Implementierung und Konfiguration über das Schlüsselmanagement bis zur Vertrauenskette Verfahren zur Erkennung missbräuchlich ausgestellter Zertifikate 1

3 Funktionsweise und Anwendungen von Zertifikaten Zertifikate sind signierte, öffentliche Identitätsinformationen Standardisierung durch ITU X.509 Sicherer Identitätsnachweis (Authentisierung) Person, IT-System, Software, Sichere Kommunikation Verschlüsselung, Signatur 2

4 Inhalte eines Zertifikate nach X.509 Zertifikat des Nutzers bzw. Geräts Signatur Version Seriennummer Signaturalgorithmus Aussteller (Certification Authority, CA) Validität (Gültigkeitsdauer) Zertifikatsinhaber Schlüsselinformationen Public-Key-Algorithmus des Inhabers Öffentlicher Schlüssel eines asymmetrischen Schlüsselpaars des Zertifikatsinhabers Erweiterungen Erweiterungs-ID Flag (kritisch / unkritisch) Wert Signaturalgorithmus Signatur Kennung der CA Kennung des Nutzers bzw. Geräts Gültigkeit des Zertifikats Public Key des Nutzers bzw. Geräts One-Way Hash-Funktion kryptographische Prüfsumme Verschlüsselung privater Schlüssel der CA Signatur 3

5 Kernelement: Nutzung asymmetrischer Verschlüsselung Asymmetrisches Schlüsselpaar: Öffentlicher und privater Schlüssel, die sich invers zueinander verhalten Hintereinander Anwenden beider Schlüssel ergibt Klartext Klartext Chiffre Klartext A Öffentlicher Schlüssel Privater Schlüssel B Klartext Chiffre Klartext Privater Schlüssel Öffentlicher Schlüssel 4

6 Kernelement: Nutzung asymmetrischer Verschlüsselung Verschlüsselung Signatur A verschlüsselt mit dem öffentlichen Schlüssel aus dem Zertifikat von B. Nur Inhaber des privaten Schlüssels (d.h. B) kann die Nachricht entschlüsseln. A verschlüsselt einen Hash über den Klartext mit seinem privaten Schlüssel. Mit dem öffentlichen Schlüssel kann die Signatur (Authentizität und Integrität) von B geprüft werden. Authentisierung A schickt Zufallszahl Z an B. B verschlüsselt Z mit seinem privatem Schlüssel und schickt Resultat R an A zurück. A wendet öffentlichen Schlüssel aus dem Zertifikat von B auf R an. A B Erzeugen einer Zufallszahl Z Z Verschlüsseln von Z mit privatem Schlüssel zu R Entschlüsseln von R mit öffentlichem Schlüssel von B Authentisierung von B, wenn Z=R Wenn das Ergebnis wieder Z ist, ist dies der Nachweis, dass B den zum öffentlichen Schlüssel gehörenden privaten Schlüssel besitzt. R 5

7 Kernelement: Nutzung asymmetrischer Verschlüsselung Die Echtheit eines Zertifikats kann durch Clients oder Server geprüft werden, wenn diese ein Zertifikat der ausstellenden CA besitzen. Entschlüsselung der Signatur mit öffentlichem Schlüssel der CA Berechnen der Prüfsumme mittels Hash-Funktion über die Daten im Zertifikat Vergleich von entschlüsselter Prüfsumme und eigener Prüfsummenberechnung 6

8 Verwaltung von Zertifikaten in einer Public Key Infrastructure Bestandteile einer Public Key Infrastructure (PKI) Certification Authority (CA) Diejenige Instanz innerhalb einer PKI, welche digitale Zertifikate erstellt, ausstellt, sperrt und verwaltet. Registration Authority (RA) Optionale Instanz, bei der Zertifikate beantragt werden können. Diese authentisiert den Antragsteller und prüft die Richtigkeit der Daten im gewünschten Zertifikat, das dann durch die Zertifizierungsstelle signiert wird. Zertifikats-Sperrliste (Certificate Revocation List, CRL) Liste mit widerrufenen Zertifikaten, die regelmäßig aktualisiert werden muss. Diese Liste enthält einen Zeitstempel des Updates und wird von der CA signiert. Kernelement ist das Schlüsselmanagement Sicheres Verwahren der privaten Schlüssel Verwaltung der öffentlichen Schlüssel / Zertifikate (durch CA) Automatische Verteilung / Erneuerung von Zertifikaten (z.b. via SCEP) Eine CA muss vertrauenswürdig sein und das Vertrauen der beteiligten Parteien genießen. Vertrauensketten 7

9 Zertifizierungsstellen (CAs) Hierarchische Struktur der CAs Wurzelzertifizierungsstelle (Root-CA) Sub-Zertifizierungsstelle (Sub-CA) CAs stellen Zertifikate aus, die einen öffentlichen Schlüssel signieren eine Sub-CA berechtigen stellvertretend Zertifikate zu signieren CAs verwalten die CRLs Vertrauensbeziehungen zwischen CAs Basis: Vertrauenswürdige Root-CAs Sub-CAs, die eine vertrauenswürdige übergeordnete CA haben, wird vertraut Historisch gewachsen Sehr komplex und unübersichtlich Self signed Zertifikat Sub-CA X-1-2 Sub-CA X-1 Sub-CA X-1-1 Root-CA X Sub-CA X-2 Zertifikat Cross signed Sub-CA X-3 Zertifikat Root-CA Y 8

10 Zertifikaten zur sicheren Kommunikation seit Jahren etabliert Vielfältige Verwendung von Zertifikaten: Web-Anwendungen und Web-Services SSL-VPN, IPSec VPN Network Access Control (NAC) in LAN und WLAN Authentisierung bei Machine-to-Machine-Kommunikation -Verschlüsselung S/MIME Neuer Personalausweis (Qualifiziertes Zertifikat, gilt als Unterschrift Ersatz im Internet) In Sicherheitskonzepten wird seit Jahren oft eine zertifikatsbasierte Authentisierung favorisiert Dann sollte sich die Technik doch inzwischen als ausgesprochen sicher, beherrschbar und betreibbar erwiesen haben?! 9

11 Inhalt Funktionsweise und Anwendungen von Zertifikaten Kernelement Publik Key Infrastructure (PKI) Fallstricke von der Implementierung und Konfiguration über das Schlüsselmanagement bis zur Vertrauenskette Verfahren zur Erkennung missbräuchlich ausgestellter Zertifikate 10

12 Potentielle Fallstricke Unsichere Schlüsselerzeugung / unsicherer Transport des privaten Schlüssels Unsichere Verschlüsselungs- und Hash-Algorithmen Unzureichende bzw. fehlerhafte Implementierungen Unsichere bzw. fehlerhafte Konfigurationen Unsichere Aufbewahrung des privaten Schlüssels Unzureichender Betrieb einer PKI (CRL-Problematik) Unzureichende Sicherheit bei einer CA Unsichere Vertrauenskette / bösartige CAs... 11

13 Beispiel: Unzureichende Implementierung einer zertifikatsbasierten Authentisierung Authentisierung von Clients mit IEEE 802.1X unter Verwendung von EAP-TLS Voraussetzung: Automatisierte Verteilung / Erneuerung von Client-Zertifikaten Was bei PCs mit Microsoft Windows schon lange unproblematisch ist, kann bei IP- Telefonen, Druckern / Multifunktionsgeräten, Thin Clients und anderen Spezialgeräten ein Albtraum sein Keine oder unzureichende automatisierte Verteilung / Erneuerung von Zertifikaten Typische Workarounds Ein Zertifikat (inkl. privater Schlüssel) für alle betroffenen Endgeräte Langlebige Zertifikate 12

14 Beispiel: Probleme bei Prüfung der Vertrauenskette Client-Authentisierung mit EAP-TLS Internationales und gesellschaftsübergreifendes Roaming der Clients Problem: Client sendet nur sein Zertifikat und nicht die komplette Kette, dem Server ist die Austeller-CA jedoch nicht bekannt Wenn jetzt kein URL für das Zertifikat der Aussteller-CA angegeben ist bzw. dies nicht aufgelöst werden kann, gibt es ein Problem... Workaround: Manuelle Installation der Sub-CA-Zertifikate 13

15 Beispiel: Unsichere Aufbewahrung des privaten Schlüssels Zertifikatsbasierte Authentisierung ist nur solange sicher, wie der private Schlüssel, der zum öffentlichen Schlüssel im Zertifikat gehört, auch geheim bleibt. Beispiel: Wie sicher ist ein auf einem PC unter MS Windows gespeicherter privater Schlüssel? Dank einer erst ab Windows 8.1 und Windows Server 2012 abgemilderten Schwachstelle ist es einem Nutzer mit Admin-Rechten möglich, den privaten Schlüssel eines Zertifikats zu exportieren. Auch wenn das Zertifikat non-exportable ist Gilt insbesondere für Windows 7 In der Praxis bewährtes Tool: mimikatz Siehe: Nebenbei: mimikatz war beim Bundestags-Hack 2015 dabei! Maßnahmen: Festplattenverschlüsselung Richtlinien an den Nutzer für den Umgang mit Zertifikaten Auf entsprechende Windows-Version migrieren 14

16 Potentielle Fallstricke Unsichere Schlüsselerzeugung / unsicherer Transport des privaten Schlüssels Unsichere Verschlüsselungs- und Hash-Algorithmen Unzureichende bzw. fehlerhafte Implementierungen Unsichere bzw. fehlerhafte Konfigurationen Unsichere Aufbewahrung des privaten Schlüssels Unzureichender Betrieb einer PKI Unzureichende Sicherheit bei einer CA Unsichere Vertrauenskette / bösartige CAs... 15

17 Zertifikate widerrufen: Leichter gesagt als getan Gründe noch nicht abgelaufene Zertifikate zu sperren oder zu widerrufen: Zertifizierungsstelle wurde kompromittiert Privater Schlüssel nicht mehr geheim Verlust des privaten Schlüssels Verschlüsselungs- oder Hashalgorithmus nicht mehr sicher Falscher Zertifikatsinhalt, z.b. bei Namensänderungen oder Umzügen Person / Objekt, für die / das das Zertifikat ausgestellt wurde, ist nicht mehr vertrauenswürdig... Grundsätzliche Technik Zertifikate als gesperrt zu markieren: Zentralisierte Datenbanken mit gesperrten Zertifikaten (die erst nach Zertifikatsablauf bereinigt werden können) Mehr oder weniger trickreiche Mechanismen zur Abfrage von Sperrinformationen Certificate Revocation Lists (CRLs) Online Certificate Status Protocol (OCSP) und OCSP Stapling 16

18 Certificate Revocation Lists (CRLs) Struktur einer CRL gemäß X.509 Version Erzeuger der CRL Algorithmus für die Signatur Updatezeitpunkt der Ausstellung der CRL Updatezeitpunkt der Ausstellung der nächsten CRL Liste der zurückgezogenen Zertifikate (Seriennummer und Zeitpunkt des Widerrufs) Erweiterungen Signatur CRLs werden von den Systemen, die z.b. eine Authentisierung durchführen, in regelmäßigen Abständen von einer CA geladen Probleme mit CRLs Je größer das Zeitintervall zwischen den Abrufen einer CRL desto größer ist im Mittel die Dauer, bis ein gesperrtes Zertifikat auch tatsächlich nicht mehr genutzt werden kann. Als Negativliste sind CRLs für eine Massensperrung schlecht geeignet. 17

19 Online Certificate Status Protocol (OCSP) Ermöglicht Clients den Status von Zertifikaten gemäß dem Standard X.509 bei der Zertifizierungsstelle / Validierungsdienst abzufragen. RFC 6960 Kann ein Zertifikat nicht validiert werden (z.b. OSCP-Server nicht erreichbar / Sperrlisten nicht verfügbar) hat ein Client grundsätzlich zwei Möglichkeiten: Verbindung beenden akzeptieren eines eventuell manipuliertes oder ungültiges Zertifikats. Unterstützung von OCSP: Mozilla Firefox Microsoft Internet Explorer Keine Unterstützung von OCSP: Google Chrome Problem: Erhält ein Browser auf die OCSP-Anfrage nicht schnell genug eine Antwort, so ignoriert der Browser den Zustand und akzeptiert das Zertifikat. 18

20 OCSP Stapling Idee: Anders als beim bekannten OCSP fragt nicht der Nutzer bei der Zertifizierungsstelle an, sondern der Server (Zertifikatsinhaber) selbst. RFC 6066 Der Server fragt regelmäßig bei der Zertifizierungsstelle nach der Gültigkeit des Zertifikats. Die Zertifizierungsstelle sendet einen von ihr signierten Status, den der Server mit an den Client sendet. Client Zertifikat und Gültigkeitsnachweis inkl. Zeitstempel Regelmäßige Frage nach Gültigkeit Webserver Signierter Status der Gültigkeit inkl. Zeitstempel OCSP-Responder Gültig Nicht errei ch bar Ungültig Abwese nd Problem: OCSP Stapling unterstützt nur die Auslieferung jeweils einer OCSP- Antwort. Bei Ketten mit Zwischenzertifikaten nicht ausreichend Offline 19

21 Authentisierungsmethoden des Auftraggebers gegenüber der CA SSL-Zertifikat und Domäne bilden eine Einheit. Domain-Validierung (DV) Zertifizierungsstelle prüft, ob der Auftraggeber auch Inhaber der Domäne ist. Dazu wird z.b. eine versendet, die bestätigt werden muss. Identitäts- oder Unternehmensvalidierung (OV) Prüfung wie bei DV. Darüber hinaus muss sich der Auftraggeber gegenüber der Zertifizierungsstelle verifizieren, z.b. über die Anschrift. Die Anschrift ist dann Bestandteil des Zertifikats. Erweiterte Validierung (EV) Im Webbrowser wird EV entsprechend angezeigt (z.b. wird die Adressleiste grün hinterlegt). Prüfung der Identität des Auftraggebers erfolgt nach strengen Standards, abhängig von Zertifizierungsstelle. 20

22 Validierung der Zertifikatsinhaber Zertifizierungsstellen prüfen die Identität ggf. nicht ausreichend. Domain Validation ist gebräuchliches Prüfverfahren. 2015: Nutzer reservierte sich die Adresse und bestellte darüber bei Comodo ein SSL-Zertifikat für den Inhaber Microsoft. Durch Domain Validation wurde er rechtmäßig als Inhaber validiert. Quelle: Quelle: 21

23 Potentielle Fallstricke Unsichere Schlüsselerzeugung / unsicherer Transport des privaten Schlüssels Unsichere Verschlüsselungs- und Hash-Algorithmen Unzureichende bzw. fehlerhafte Implementierungen Unsichere bzw. fehlerhafte Konfigurationen Unsichere Aufbewahrung des privaten Schlüssels Unzureichender Betrieb einer PKI Unzureichende Sicherheit bei einer CA Unsichere Vertrauenskette / bösartige CAs... 22

24 Im Dschungel der CAs: Missbräuchlich ausgestellte Zertifikate CAs können grundsätzlich beliebige Zertifikate ausstellen. Entscheidend ist die Frage, ob ein System einer CA traut. Einen Mechanismus, der prüft, ob eine CA überhaupt berechtigt ist ein Zertifikat auszustellen, gibt es nicht. Dies ist besonders kritisch, da die Anzahl der CAs inzwischen kaum noch überschaubar ist. Zertifizierungsstellen und besonders Root-CAs müssen ihre Infrastrukturen besonders schützen. Einbruch in eine Root-CA / Sub-CA kann ebenso zu missbräuchlich ausgestellten Zertifikaten führen ( Zertifikatsdiebstahl ). Konsequenzen Bruch der Vertrauenskette Aufbau eines vermeintlich vertrauenswürdigen Systems Server mit Schadsoftware Unberechtigter VPN-Zugang Angreifer können als Man in the Middle (MitM) den SSL-Verkehr mitlesen / verändern. 23

25 Missbräuchlich ausgestellte Zertifikate: Beispiele 2011: Nach einem Einbruch stellte die CA Comodo falsche Zertifikate aus, für z.b. Google, Yahoo, Skype Spur führte laut Comodo in den Iran 2011: Niederländische Root-CA DigiNotar wurde gehackt und stellte fälschlicherweise GMail und Facebook Zertifikate aus. Dies ermöglichte z.b. eine Überwachung von Dissidenten im Iran. Zertifikate konnten erst zeitlich verzögert gesperrt werden. Wurden verbreitet in der niederländischen Verwaltung eingesetzt 2012: Die amerikanische CA Trustwave stellte für Firmen fälschlich Zertifikate aus, mit denen die Unternehmen den TLS-gesicherten Internetverkehr der Mitarbeiter mitlesen konnten. 2014: National Informatics Centre (NIC) stellte missbräuchlich Google Zertifikate aus Root-CA ist die staatliche Zertifizierungsstelle Indiens (India CCA) 2015: Chinesische Zertifizierungsstelle CNNIC signierte gefälschte Zertifikate Über Zwischenzertifizierungsstelle MCS Holdings Z.B. für Google Domänen Über diese CA wurden auch Outlook Nutzer über MitM-Techniken angriffen. Alle gängigen Browser unterstützten die Zertifikate der CA CNNIC. Einzelner-Hacker-uebernimmt-Verantwortung-fuer- Zertifikats-Klau-bei-Comodo html

26 Inhalt Funktionsweise und Anwendungen von Zertifikaten Kernelement Publik Key Infrastructure (PKI) Fallstricke von der Implementierung und Konfiguration über das Schlüsselmanagement bis zur Vertrauenskette Verfahren zur Erkennung missbräuchlich ausgestellter Zertifikate 25

27 Warum das Konzept der Vertrauenskette dringend renoviert werden musste Zusammenfassung: Schwachstellen der Vertrauenskette Jeder kann CA sein, jede CA kann Sub CAs Zertifikate ausstellen. CAs können prinzipiell für alles und jeden Zertifikate ausstellen. Vertrauensketten sind sehr unübersichtlich. Nicht selten nur schwache Authentisierung der Zertifikatsinhaber durch die CA. Manche CAs stellen wissentlich falsche Zertifikate aus Manche CAs schützen ihre Infrastruktur nicht ausrechend (und werden gehackt). Klassische Maßnahmen: Liste der vertrauenswürdigen Stammzertifizierungsstellen aufräumen Sensibilisierung der Nutzer... Es gibt inzwischen aber auch Verfahren, mit denen die Berechtigungen von CAs geprüft und missbräuchlich ausgestellte Zertifikate besser erkannt werden können Certificate Pinning Certificate Transparency DANE 26

28 Certificate Pinning HTTP-Header erweitern um Informationen (Pins) über die für die HTTPS-Verbindung zu einer Domäne zulässigen öffentlichen Schlüssel PKP Extension für HTTP, RFC 7469 PKP-Header: pin-sha256 max-age includesubdomains report-uri Verknüpfung zwischen Domänennamen und öffentlichen Schlüsseln IP-Adresse der Domäne wird nicht betrachtet Trust-On-First-Use (TOFU) Domäne kann dann nur noch mit gespeichertem Pin und einem zugehörigen Zertifikat erfolgreich aufgerufen werden HTTP Strict Transport Security (HSTS) empfohlen Statisches Pinning: Statische Pins im Browser (statt TOFU) Komplexere Serverkonfiguration & False Positives bei Konfigurationsfehler Browser (3) Überprüfung des Serverzertifikats und der Verschlüsselungsparameter (7) Prüfen ob aktueller Pin im Cache wenn ja: Abgleich mit öffentlichem Schlüssel (10) Prüfung des Headers und Speichern des Headers Internet (1) Client hello (2) Server hello inkl. Zertifikat (4) Übertr. generierter Client-Key (5) Client finished (6) Server finished (8) HTTPS Request (9) HTTPS Response m. PKP-Header Server TLS-Handshake 27

29 Certificate Transparency (CT) Projekt von Google Funktionsweise: CAs sollten alle ausgestellten Zertifikate auf zentrale Log-Listen schreiben Nutzer von CT können prüfen, ob Zertifikate gelistet sind und ebenfalls Zertifikate auf Log-Listen schreiben CT Log-Listen sind Öffentlich einsehbar Einträge können nicht gelöscht werden. Unverfälschbar Liefert zunächst die Möglichkeit einen Missbrauch zu entdecken oder ein Zertifikat, das nicht gelistet ist, als suspekt einzustufen Verhindert jedoch den Missbrauch nicht unmittelbar Quelle: 28

30 Certificate Transparency (CT) Automatisiertes Überwachungssystem möglich, das z.b. für eine CA feststellt, wer für eine Domäne außer der CA sonst noch Zertifikate ausstellt 2015: Symantec Mitarbeiter stellten wissentlich falsche Zertifikate aus. Offenbar zu Testzwecken Festgestellt durch Certificate Transparency Googles Browser Chrome verlangt bei Extended-Validation-Zertifikaten Unterstützung von Certificate Transparency Quelle: 29

31 Ist DANE eine Alternative? DNS-based Authentication of Named Entities (DANE) RFC 6698 X.509-Zertifikate werden mit DNS-Einträgen verknüpft und über DNS-Security- Extension (DNSSec) gesichert. TLSA Record: Zertifikat oder Fingerprint eines Zertifikats oder Client DNSSec (1) DNS Request DNS Server öffentlicher Schlüssel eines Zertifikats (2) DNS Response (inkl. TLSA Record) Im Vergleich zu Certificate Pinning höheres Sicherheitsniveau Voraussetzung für DANE: vorhandene DNSSec-Infrastruktur (5) Überprüfung des Serverzertifikats und der Verschlüsselungsparameter (3) Anfrage zum Verbindungsaufbau (4) Zertifikat / Authentisierung des Servers (6) TLS-Handshake (7) Authentisierte und verschlüsselte Kommunikation 30

32 Fazit Eine zertifikatsbasierte Absicherung der Kommunikation in der IT ist (und bleibt) in hohem Maß komplex und fehlerträchtig in Design, Implementierung und Betrieb. Wir haben nur keine technologische Alternative. Sicherheitsvorfälle in den letzten Jahren haben eindrücklich gezeigt: Eine Renovierung der Prüfung von Zertifikaten gegen unberechtigte und missbräuchliche Er- und Ausstellung sowie Nutzung von Zertifikaten ist zwingend erforderlich. Certificate Pinning gestattet eine deutliche Reduktion der Angriffsfläche ist aktuell wenig verbreitet, Verbreitung nimmt aber sichtbar zu (Opera, Chrome, Firefox) Komplexität und Fehleranfälligkeit der Serverkonfiguration Certificate Transparency ist eine Grundlage zur Missbrauchserkennung liefert aber kein unmittelbares Instrument gegen den Missbrauch. Certificate Transparency über den Einsatz in Chrome massiv gepusht. Über DANE kann im Vergleich zu Certificate Pinning ein höheres Sicherheitsniveau geschaffen werden, setzt aber DNSSec voraus und ist aktuell noch kaum anzutreffen. 31

33 Gemeinsame Ziele verbinden ComConsult Beratung und Planung GmbH Pascalstraße 27, Aachen, Deutschland Telefon: Fax: Web: ComConsult Beratung und Planung GmbH, 8. April 2016

34 Anhang: Interessante Publikationen zum Aufbau einer PKI BSI TR-03145: Secure CA operation, Part 1 - Generic requirements for Trust Centers instantiating as Certification Authority (CA) in a Public-Key Infrastructure (PKI) with security level 'high', Version 1.0, 2014 ITU-T Standard X.509: Information technology Open Systems Interconnection The Directory: Public-key and attribute certificate frameworks, Oktober 2012 CA/Browser Forum: Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates ETSI EN : Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements, V1.1.1, Februar 2016 ETSI EN : Electronic Signatures and Infrastructures (ESI);Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified certificates, V2.1.1, Februar 2016 ETSI EN : Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 3: Policy requirements for Certification Authorities issuing public key certificates, V1.1.1, Januar

35 Anhang: Unterstützung von PKP durch Browser Feature Chrome Firefox Internet Edge Opera Safari Explorer Basis PKP Ab Version 46 Ab Version 35 Nein Nein Ja Nein Report Only Ab Version 46 Nein - - Ja - Report URI Ab Version 46 Nein - - Ja - Certificate Transparency Ab Version 33 Nein Nein Nein Ja Nein Statische Pins Ab Version 13 Ab Version 32 Nein Ja Ja Nein PKP Level Level 1 Konfigurierbar - - Level 1-34