Mehr Sicherheit bei der Zertifikatsausstellung mit Multipath Domain Control Validation

Dieser Blogbeitrag ist Teil der Crypto Week 2019.

Das Vertrauen im Internet basiert auf der Public Key Infrastruktur (PKI). Die PKI ermöglicht es Servern, Webseiten sicher zu bereitzustellen, indem sie digitale Zertifikate ausstellt und damit die Grundlage für eine verschlüsselte und authentische Kommunikation bereitstellt.

Zertifikate ermöglichen die HTTPS-Verschlüsselung, indem sie den öffentlichen Schlüssel im Zertifikat verwenden, um die Serveridentität zu überprüfen. HTTPS ist besonders wichtig für Webseiten, die vertrauliche Daten übertragen, z. B. Bankkontoanmeldedaten oder private Nachrichten. Glücklicherweise kennzeichnen moderne Browser, wie beispielsweise Google Chrome, Webseiten, die nicht mit HTTPS gesichert sind, indem sie sie mit „Nicht sicher“ markieren, sodass die Benutzer ein höheres Sicherheitsbewusstsein hinsichtlich der von ihnen besuchten Websites haben.

Dieser Blogbeitrag stellt ein neues, kostenloses Tool vor, das Cloudflare Zertifizierungsstellen anbietet, damit diese die Zertifikatsausgabe zusätzlich sichern können. Aber bevor wir zu tief eintauchen, lassen Sie ansehen, woher die Zertifikate stammen.

Zertifizierungsstellen (Certificate Authorities – CAs) sind die Institutionen, die für die Ausstellung von Zertifikaten zuständig sind.

Wenn sie ein Zertifikat für eine bestimmte Domain ausstellen, nutzen sie die Domain Control Validation (DCV), um zu überprüfen, ob die Entität, die ein Zertifikat für die Domain anfordert, der rechtmäßige Eigentümer der Domain ist. Für die DCV bieten sich dem Domaininhaber drei Möglichkeiten:

1. er erstellt einen DNS-Ressourceneintrag für eine Domain,

2. er lädt ein Dokument auf den Webserver dieser Domain hoch ODER

3. er beweist, dass er Eigentümer des administrativen E-Mail-Kontos der Domain ist.

Der DCV-Prozess verhindert, dass Widersacher private Schlüssel- und Zertifikatspaare für Domains erhalten, die nicht dem Antragsteller gehören.

Es ist überaus wichtig, Widersacher daran zu hindern, dieses Paar zu erwerben: Wenn ein falsch ausgestelltes Zertifikat und ein privates Schlüsselpaar in die Hände eines Widersachers fallen, könnte dieser sich als Domain des Opfers ausgeben und Einblick in sensiblen HTTPS-Datenverkehr erhalten. Dies untergräbt unser bestehendes Vertrauen in das Internet und gefährdet möglicherweise private Daten in einem gewaltigen Umfang.

Beispielsweise könnte ein Widersacher, der eine Zertifizierungsstelle dazu bringt, ein Zertifikat für gmail.com falsch auszustellen, dann TLS-Handshakes ausführen, während er vorgibt, Google zu sein. Dadurch könnte er Cookies und Anmeldeinformationen herausfiltern und so Zugriff auf das Gmail-Konto des Opfers erhalten. Die Risiken bei einer Fehlausstellung von Zertifikaten sind eindeutig sehr hoch.

Um derartige Angriffe zu verhindern, stellen Zertifizierungsstellen ein Zertifikat erst nach der Durchführung der DCV aus. Eine Möglichkeit zur Validierung des Eigentums an einer Domain besteht in der HTTP-Validierung. Dabei wird eine Textdatei auf einen bestimmten HTTP-Endpunkt auf dem Webserver hochgeladen wird, der gesichert werden soll.  Eine andere DCV-Methode ist die E-Mail-Überprüfung, bei der eine E-Mail mit einem Validierungscode-Link an den administrativen Kontakt für die Domain gesendet wird.

Angenommen, Alice kauft den Domainnamen aliceswonderland.com und möchte ein dediziertes Zertifikat für diese Domain erhalten. Alice entscheidet sich für Let‘s Encrypt als Zertifizierungsstelle. Zunächst muss Alice einen eigenen privaten Schlüssel generieren und eine Zertifikatsignierungsanforderung (Certificate Signing Request – CSR) erstellen. Sie sendet das CSR an Let‘s Encrypt, aber die Zertifizierungsstelle stellt kein Zertifikat für dieses CSR und den privaten Schlüssel aus, bevor sie weiß, dass Alice aliceswonderland.com besitzt. Alice kann dann durch HTTP-Validierung beweisen, dass sie Inhaberin der Domain ist.

Wenn Let‘s Encrypt die DCV über HTTP durchführt, muss Alice eine zufällig benannte Datei auf dem Pfad /.well-known/acme-challenge für ihre Webseite platzieren. Die Zertifizierungsstelle muss die Textdatei abrufen, indem sie eine HTTP- GET -Anfrage an http://aliceswonderland.com/.well-known/acme-challenge/<random_filename> sendet. Damit die DCV erfolgreich ist, muss an diesem Endpunkt ein erwarteter Wert vorhanden sein.

Für die HTTP-Validierung würde Alice eine Datei in http://aliceswonderland.com/.well-known/acme-challenge/YnV0dHNz hochladen,

deren Text Folgendes enthält:

curl http://aliceswonderland.com/.well-known/acme-challenge/YnV0dHNz

GET /.well-known/acme-challenge/YnV0dHNz
Host: aliceswonderland.com

HTTP/1.1 200 OK
Content-Type: application/octet-stream

YnV0dHNz.TEST_CLIENT_KEY

Die Zertifizierungsstelle weist sie an, das Base64-Token YnV0dHNz. TEST_CLIENT_KEY in einem mit dem Konto verknüpften Schlüssel zu verwenden, den nur der Antragsteller für das Zertifikat und die Zertifizierungsstelle kennen. Die Zertifizierungsstelle verwendet diese Feldkombination, um zu überprüfen, ob der Antragsteller tatsächlich Inhaber der Domain ist. Danach kann Alice das Zertifikat für ihre Webseite erhalten!

Eine weitere Möglichkeit, das Eigentum an einer Domain nachzuweisen, besteht darin, den Ressourceneinträgen der Domain einen DNS-TXT-Eintrag hinzuzufügen, der eine Verifizierungszeichenfolge oder ein Token von der Zertifizierungsstelle enthält. Hier ist z. B. eine Domain für ein Unternehmen, das sich gegenüber Google validiert:

$ dig TXT aliceswonderland.com
aliceswonderland.com.	 28 IN TXT "google-site-verification=COanvvo4CIfihirYW6C0jGMUt2zogbE_lC6YBsfvV-U"

Hier entscheidet sich Alice, einen TXT-DNS-Ressourceneintrag mit einem bestimmten Token-Wert zu erstellen. Eine Google-Zertifizierungsstelle kann das Vorhandensein dieses Tokens prüfen und damit validieren, ob Alice tatsächlich die Eigentümerin der Webseite ist.

Die Zertifikatsausstellung ist erforderlich, damit Server sicher mit Clients kommunizieren können. Aus diesem Grund ist es überaus wichtig, dass auch der Prozess der Zertifikatsausstellung sicher ist. Leider ist dies nicht immer der Fall.

Forscher der Princeton University haben kürzlich herausgefunden, dass gängige DCV-Methoden anfällig für Angriffe sind, die von Widersachern auf Netzwerkebene ausgeführt werden. Wenn das Border Gateway Protocol (BGP) der „Postdienst“ des Internets ist, der für die Übermittlung von Daten über die effizientesten Routen verantwortlich ist, dann sind Autonome Systeme (AS) einzelne Postfilialen, die ein von einer einzigen Organisation betriebenes Internetnetzwerk darstellen. Manchmal bieten Widersacher auf Netzwerkebene falschen Routen über das BGP an, um Datenverkehr zu stehlen, insbesondere wenn dieser Datenverkehr etwas Wichtiges enthält, z. B. das Zertifikat einer Domain.

Die Forschungsarbeit Bamboozling Certificate Authorities with BGP hebt fünf Arten von Angriffen hervor, die während des DCV-Prozesses angewendet werden können, um ein Zertifikat für eine Domain zu erhalten, die der Widersacher nicht besitzt. Nach der Implementierung dieser Angriffe konnten die Autoren von den fünf besten Zertifizierungsstellen (auf ethische Weise) Zertifikate für Domains erhalten, die sie nicht besitzen: Let’s Encrypt, Golda, Comodo, Symantec und GlobalSign. Aber wie haben sie das gemacht?

Es gibt zwei Hauptansätze, um den DCV-Prozess mittels BGP-Hijacking anzugreifen:

1. Subpräfix-Angriff (Sub-Prefix Attack)

2. Gleichermaßen-spezifischer-Präfix-Angriff (Equally-Specific-Prefix Attack)

Diese Angriffe sorgen für eine Schwachstelle, wenn ein Widersacher eine Zertifikatsignierungsanforderung für die Domain eines Opfers an eine Zertifizierungsstelle sendet. Wenn die Zertifizierungsstelle die Netzwerkressourcen mithilfe einer HTTP GET-Anfrage überprüft (wie oben erläutert), nutzt der Widersacher Angriffe auf das BGP, um den Datenverkehr zur Domain des Opfers zu kapern und so dafür zu sorgen, dass die Anfrage der Zertifizierungsstelle beim Widersacher landet anstatt beim Eigentümer der Domain. Um zu verstehen, wie diese Angriffe durchgeführt werden, müssen wir zuerst ein wenig Mathematik betreiben.

Jedes Gerät im Internet verwendet eine IP-Adresse (Internetprotokoll-Adresse) als numerische Kennung. IPv6-Adressen enthalten 128 Bit und folgen einer Slash-Notation zur Angabe der Größe des Präfixes. In der Netzwerkadresse 2001:DB8:1000::/48 bezieht sich „/48“ also darauf, wie viele Bit das Netzwerk enthält. Das bedeutet, dass noch 80 Bit übrig sind, die die Host-Adressen enthalten, für insgesamt 10.240 Host-Adressen. Je kleiner die Präfix-Zahl ist, desto mehr Host-Adressen verbleiben im Netzwerk. Lassen Sie uns jetzt mit diesem Wissen zu den Angriffen übergehen!

Angriff 1: Subpräfix-Angriff

Wenn das BGP eine Route bekanntgibt, zieht es der Router immer vor, der spezifischeren Route zu folgen. Wenn also 2001:DB8::/32 und 2001:DB8:1000::/48 bekanntgegeben werden, verwendet der Router letztere, da es sich um das spezifischere Präfix handelt. Dies wird zu einem Problem, wenn ein Widersacher eine BGP-Bekanntgabe an eine bestimmte IP-Adresse vornimmt, während er die IP-Adresse der Domain des Opfers verwendet. Angenommen, die IP-Adresse für unser Opfer leagueofentropy.com lautet 2001:DB8:1000::1 und wird als 2001:DB8::/32 bekanntgegeben. Wenn ein Widersacher das Präfix 2001:DB8:1000::/48 bekanntgibt, erfasst er den Datenverkehr des Opfers durch einen Subpräfix-Hijacking-Angriff.

Bei einem IPv4-Angriff, wie dem Angriff im April 2018, waren das /24- und /23-Bekanntgaben, wobei die spezifischere /24 vom Angreifer bekanntgegeben wurde. In IPv6 könnten dies eine /48- und eine /47-Bekanntgabe sein. In beiden Szenarien sind /24 und /48 die kleinsten Blöcke, die global geroutet werden dürfen. Im folgenden Diagramm ist /47 Texas und /48 das spezifischere Austin in Texas. Die neuen (böswilligen) Routen überschrieben für Teile des Internets die bestehenden Routen. Der Angreifer führte dann einen böswilligen DNS-Server auf den normalen IP-Adressen aus, wobei DNS-Einträge anstelle des vorhandenen Servers auf einen neuen, ebenfalls böswilligen Webserver verwiesen. Dies zog den Traffic an, der innerhalb des Bereichs, in dem die schändlichen Routen verbreitet wurden, für die Domäne des Opfers bestimmt war. Der Grund für den Erfolg dieses Angriffs war, dass ein spezifischeres Präfix von den empfangenden Routern stets bevorzugt wird.

Angriff 2: Gleichermaßen-spezifischer-Präfix-Angriff

Beim letzten Angriff war der Widersacher in der Lage, den Datenverkehr mit einer spezifischeren Bekanntgabe zu kapern. Aber was ist, wenn das Präfix des Opfers /48 lautet und ein Subpräfix-Angriff nicht durchführbar ist? In diesem Fall würde ein Angreifer einen Gleichermaßen-spezifischer-Präfix-Hijack starten, indem er dasselbe Präfix wie das Opfer bekanntgibt. Das führt dazu, dass das Autonome System die bevorzugte Route unter der Bekanntgabe des Opfers und der des Widersachers anhand von Eigenschaften wie Pfadlänge auswählt. Dieser Angriff fängt immer nur einen Teil des Datenverkehrs ab.

Es gibt fortgeschrittenere Angriffe, die in der Forschungsarbeit ausführlicher behandelt werden. Dabei handelt es sich um grundsätzlich ähnliche, aber besser getarnte Angriffe.

Sobald ein Angreifer erfolgreich ein falsches Zertifikat für eine Domain erhalten hat, die er nicht besitzt, kann er einen überzeugenden Angriff ausführen, bei dem er sich als Domain des Opfers ausgibt und in der Lage ist, den TLS-Datenverkehr des Opfers zu entschlüsseln und abzufangen. Die Möglichkeit, den TLS-Datenverkehr zu entschlüsseln, ermöglicht es dem Widersacher, als Monster-in-the-Middle (MITM) den verschlüsselten TLS-Datenverkehr komplett zu kapern und den für die Domain des Opfers bestimmten Internetverkehr an den Widersacher umzuleiten. Zur Tarnung des Angriffs leitet der Widersacher weiterhin Datenverkehr durch die Domain des Opfers, um unentdeckt zu bleiben.

Eine andere Möglichkeit, wie ein Widersacher die Kontrolle über eine Domain erlangen kann, besteht darin, den DNS-Datenverkehr mithilfe einer Quell-IP-Adresse, die zu einem DNS-Nameserver gehört, zu manipulieren. Da jeder die ausgehenden IP-Adressen seiner Pakete ändern kann, kann ein Widersacher die IP-Adresse jedes beliebigen involvierten DNS-Nameservers fälschen und die Identität eines Nameservers annehmen, wenn es einer Zertifizierungsstelle antwortet.

Dieser Angriff ist raffinierter als das bloße Spamming einer Zertifizierungsstelle mit gefälschten DNS-Antworten. Da jede DNS-Abfrage ihre eigenen zufälligen Abfragekennungen und einen Quellport hat, muss eine gefälschte DNS-Antwort mit den Kennungen der DNS-Abfrage übereinstimmen, um überzeugend zu sein. Da diese Abfragekennungen zufällig sind, ist es äußerst schwierig, eine manipulierte Antwort mit den richtigen Kennungen zu erstellen.

Widersacher können User Datagram Protocol-(UDP)-DNS-Pakete so fragmentieren, dass die Identifizierung von DNS-Antwortinformationen (wie die zufällige DNS-Abfragekennung) in einem Paket geliefert wird, während der eigentliche Antwortabschnitt in einem anderen Paket folgt. Auf diese Weise manipuliert der Widersacher die DNS-Antwort auf eine legitime DNS-Abfrage.

Angenommen, ein Widersacher möchte ein fälschlich ausgestelltes Zertifikat für victim.com erhalten, indem er die Paketfragmentierung erzwingt und die DNS-Validierung manipuliert. Der Widersacher sendet einem DNS-Nameserver für victim.com ein ICMP-„Fragmentierung erforderlich“-Paket mit einer kleinen maximalen Übertragungseinheit oder maximaler Bytegröße. Dadurch wird der Nameserver dazu gebracht, DNS-Antworten zu fragmentieren. Wenn die Zertifizierungsstelle eine DNS-Abfrage an einen Nameserver von victim.com sendet, um nach den TXT-Einträgen von victim.com zu fragen, fragmentiert der Nameserver die Antwort in die beiden oben beschriebenen Pakete: Das erste enthält die Abfrage-ID und den Quellport, die der Widersacher nicht manipulieren kann, und der zweite enthält den Antwortabschnitt, den der Widersacher manipulieren kann. Der Widersacher kann während des gesamten DNS-Validierungsprozesses kontinuierlich manipulierte Antworten an die Zertifizierungsstelle senden, in der Hoffnung, seine manipulierten Antworten einzuschleusen, bevor die Zertifizierungsstelle die echte Antwort vom Nameserver erhält.

Dabei kann der Antwortabschnitt einer DNS-Antwort (der wichtige Teil!) manipuliert werden, wodurch ein Widersacher eine Zertifizierungsstelle dazu bringen kann, ein Zertifikat falsch auszustellen.

Auf den ersten Blick könnte man meinen, dass ein Certificate-Transparency-Protokoll ein falsch ausgestelltes Zertifikat offenlegen kann und es dadurch einer Zertifizierungsstelle möglichen ist, es schnell zu widerrufen. CT-Protokolle können jedoch bis zu 24 Stunden benötigen, um neu ausgestellte Zertifikate aufzunehmen, und der Widerruf von Zertifikaten kann von verschiedenen Browsern inkonsistent verfolgt werden. Wir brauchen eine Lösung, die es Zertifizierungsstellen ermöglicht, diese Angriffe proaktiv zu verhindern, damit sie sie nicht rückwirkend beheben müssen.

Wir freuen uns, Ihnen mitteilen zu können, dass Cloudflare Zertifizierungsstellen eine kostenlose API zur Verfügung stellt, mit der sie unser globales Netzwerk können, um DCVs von mehreren Standorten auf der ganzen Welt aus durchzuführen. Diese API wappnet den DCV-Prozess gegen BGP-Hijacking- und Off-Path-DNS-Angriffe.

Da Cloudflare weltweit mehr als 175 Rechenzentren betreibt, befinden wir uns in einer einzigartigen Position, um eine DCV von mehreren Standorten aus durchzuführen. Jedes Rechenzentrum verfügt über einen eindeutigen Pfad zu DNS-Nameservern oder HTTP-Endpunkten, was bedeutet, dass ein erfolgreiches Hijacking einer BGP-Route nur eine Teilmenge von DCV-Anfragen betreffen kann, was BGP-Hijacking weiter erschwert. Und da wir RPKI verwenden, signieren und verifizieren wir tatsächlich BGP-Routen.

Dieser DCV-Checker schützt Zertifizierungsstellen außerdem vor Angriffen mit Off-Pfad-DNS-Spoofing. Eine zusätzliche Funktion, die wir in den Dienst integriert haben und die zum Schutz vor Off-Path-Angreifern beiträgt, ist die Randomisierung der Quell-IP von DNS-Abfragen. Indem die Quell-IP für den Angreifer unvorhersehbar gemacht wird, wird es schwieriger für ihn, das zweite Fragment der falschen DNS-Antwort an den DCV-Validierungsagenten zu manipulieren.

Mithilfe des Vergleichs mehrerer DCV-Ergebnisse, die über mehrere Pfade gesammelt wurden, macht es unsere DCV-API für einen Widersacher praktisch unmöglich, eine Zertifizierungsstelle so zu täuschen, dass sie denkt, jemand besitze eine Domain besitzt, ohne dass er das tatsächlich tut. Zertifizierungsstellen können unser Tool verwenden, um sicherzustellen, dass sie nur Zertifikate an rechtmäßige Domaininhaber ausstellen.

Unser Multipath-DCV-Checker besteht aus zwei Diensten:

1. DCV-Agenten, die für die Ausführung der DCV in einem bestimmten Rechenzentrum zuständig sind, und

2. ein DCV-Orchestrator, der Multipath-DCV-Anfragen von Zertifizierungsstellen bearbeitet und an eine Teilmenge von DCV-Agenten weiterleitet.

Wenn eine Zertifizierungsstelle sicherstellen will, dass eine DCV durchgeführt wird, ohne abgefangen zu werden, kann sie eine Anfrage an unsere API senden, in der sie den Typ des auszuführenden DCV und seine Parameter angibt.

Der DCV-Orchestrator leitet jede Anfrage an eine zufällige Teilmenge der über 20 DCV-Agenten in verschiedenen Rechenzentren weiter. Jeder DCV-Agent führt die DCV-Anfrage aus und leitet das Ergebnis an den DCV-Orchestrator weiter, der aggregiert, was jeder Agent beobachtet hat, und es an die Zertifizierungsstelle zurückgibt.

Dieser Ansatz kann auch verallgemeinert werden, um Multipath-Abfragen über DNS-Einträge, z. B. CAA-Einträge (Certificate Authority Authorization), auszuführen. CAA-Einträge autorisieren Zertifizierungsstellen, Zertifikate für eine Domain auszustellen; es wird also durch die Mehrwegebeobachtung ein weiterer Angriffsvektor – Spoofing, um nicht autorisierte Zertifizierungsstellen zur Ausstellung von Zertifikaten zu veranlassen – verhindert.

Als wir unseren Multipath-Checker entwickelten, standen wir im Austausch mit der Forschungsgruppe in Princeton, die den Proof-of-Concept (PoC) der Fehlausgabe von Zertifikaten durch BGP-Hijacking-Angriffe einführte. Prateek Mittal, Mitverfasser der Forschungsarbeit Bamboozling Certificate Authorities with BGP, schrieb:

„Unsere Analyse zeigt, dass die Domainvalidierung aus mehreren Blickwinkeln die Auswirkungen lokalisierter BGP-Angriffe deutlich mildert. Wir empfehlen allen Zertifizierungsstellen, diesen Ansatz zu verfolgen, um die Websicherheit zu erhöhen. Ein besonders attraktives Merkmal der Implementierung dieser Abwehrmaßnahme durch Cloudflare ist, dass Cloudflare Zugriff auf eine große Anzahl von Standorten im Internet hat, was die Robustheit der Domain Control Validation deutlich erhöht.“

Unser DCV-Checker folgt unserer Überzeugung, dass Vertrauen im Internet verteilt sein und durch Analysen Dritter (wie die von Cloudflare) überprüft werden muss, um Konsistenz und Sicherheit zu gewährleisten. Dieses Tool ergänzt unsere bereits existierenden Certificate-Transparency-Monitorals Set von Diensten, die Zertifizierungsstellen zur Verbesserung der Verantwortung bei der Ausstellung von Zertifikaten verwenden können.

Der Aufbau unseres Multipath-DCV-Checkers ermöglichte es uns auch, Selbstversuche mit mehreren Cloudflare-Produkten durchzuführen.

Der DCV-Orchestrator als einfacher Abrufer und Aggregator war ein fantastischer Kandidat für Cloudflare Workers. Wir haben den Orchestrator in TypeScript mit diesem Beitrag als Leitfaden implementiert und einen typisierten, zuverlässigen Orchestrator-Service erstellt, der einfach zu implementieren und zu iterieren war. Hurra, dass wir keinen eigenen DCV-Orchestrator-Server unterhalten müssen!

Wir nutzen Argo Tunnel, um Cloudflare Workers den Kontakt mit DCV-Agenten zu ermöglichen. Argo Tunnel ermöglicht es uns, unsere DCV-Agenten einfach und sicher in die Umgebung von Workers einzubinden. Da Cloudflare über etwa 175 Rechenzentren mit DCV-Agenten verfügt, stellen wir viele Dienste über Argo Tunnel zur Verfügung und hatten die Möglichkeit, als Power-User Argo-Tunnel mit einer Vielzahl von Ursprüngen zu testen. Argo Tunnel hat diesen Zustrom neuer Ursprünge problemlos bewältigt!

Wenn Sie und/oder Ihre Organisation daran interessiert sind, unseren DCV-Checker auszuprobieren, lassen Sie es uns wissen, indem Sie eine E-Mail an dcv@cloudflare.com senden! Wir würden gerne mehr darüber erfahren, wie Mehrwegeabfragen und -validierungen die Sicherheit Ihrer Zertifikatsausstellung erhöhen.

Da eine neue Klasse von BGP- und IP-Spoofing-Angriffen die PKI-Grundlagen zu untergraben droht, ist es wichtig, dass sich die Benutzer von Webseiten für die Mehrwegevalidierung einsetzen, wenn ihnen Zertifikate ausgestellt werden. Wir empfehlen allen Zertifizierungsstellen, Mehrwegevalidierung zu verwenden, unabhängig davon, ob es sich um Cloudflares oder ihre eigene handelt. Jacob Hoffman-Andrews, Tech Lead, Let’s Encrypt, schrieb:

„BGP-Hijacking ist eine der großen Herausforderungen, die die Web-PKI noch zu lösen hat, und wir denken, dass die Mehrwegevalidierung Teil der Lösung sein kann. Wir testen unsere eigene Implementierung und empfehlen anderen Zertifizierungsstellen, ebenfalls Multipath einzusetzen.“

Hoffentlich werden Website-Besitzer in Zukunft bei der Auswahl einer Zertifizierungsstelle auf die Unterstützung von Mehrwegevalidierung achten.Crypto Week Krypto Kryptografie DNS BGP