Sicherheit

Auf SSL und TLS sind jeweils eine Reihe von Angriffen bekannt, die die Sicherheitsgarantien untergraben. Die folgende Liste stellt einen Teil der bekannten Angriffe dar.

Padding-Oracle-Angriffe

Der Kryptologe Serge Vaudenay entdeckte 2002, dass ein Man-in-the-Middle-Angreifer aus dem Padding einer mit dem Cipher Block Chaining Mode (CBC) verschlüsselten Nachricht Informationen erhalten kann, die zur Entschlüsselung der Nachricht genutzt werden können. Durch gezielte Manipulation einer verschlüsselten Nachricht lernt der Angreifer, ob der Server ein gültiges Padding meldet und damit ein Teil des Klartexts richtig erraten wurde.

Als Schutzmaßnahme sollte der Server ungültige Nachrichten verwerfen, ohne dabei zu offenbaren, ob das Padding oder die Nachrichtenauthentizität ungültig war. Allerdings kann ein Angreifer diese Information auch durch eine Analyse der Antwortzeiten herleiten (Timing-Angriff). Betroffen sind SSL, TLS bis Version 1.2 und DTLS, sofern eine Cipher Suite mit CBC verwendet wird. Cipher Suites mit Authenticated Encryption sind nicht betroffen.

Im Oktober 2014 demonstrierten Sicherheitsforscher den POODLE-Angriff (Padding Oracle On Downgraded Legacy Encryption), mit dem ein Angreifer ein Versions-Downgrade einer TLS-Verbindung erzwingt, um einen Padding-Oracle-Angriff gegen SSL 3.0 durchzuführen. Zwecks Kompatibilität wurde SSL 3.0 trotz zu dem Zeitpunkt bekannter Sicherheitsschwächen noch von Webbrowsern und anderen Implementierungen unterstützt. Im Nachgang hat die Internet Engineering Task Force SSL 3.0 als überholt gekennzeichnet und ein Verfahren zum Schutz vor Downgrade-Angriffen auf TLS spezifiziert.

BEAST

SSL 3.0 und TLS 1.0 verwenden im CBC-Modus einen vorhersagbaren Initialisierungsvektor. Ein Angreifer kann dadurch mit einem Chosen-Plaintext-Angriff unbekannte Teile des Klartexts ermitteln. Ein Angriffsszenario ist das Stehlen von HTTP-Cookies, die verschlüsselt übertragen werden. Hierzu muss der Angreifer das Angriffsopfer auf eine bösartige Website locken, die wiederholt HTTP-Anfragen an eine fremde Domain auslöst, wobei der Webbrowser automatisch die für die Domain gesetzten HTTP-Cookies mitsendet. Durch den teilweise selbst gewählten Inhalt der HTTP-Anfragen und durch Abhören der verschlüsselten TLS-Nachrichten kann der Angreifer das Cookie zeichenweise erraten.

Die Grundlagen des Angriffs wurden 2004 beschrieben

und 2011 erstmals in der Praxis unter dem Namen BEAST (Browser Exploit Against SSL/TLS) demonstriert.

TLS-Version 1.1 und höher sind nicht betroffen, da jede Nachricht mit einem pseudozufälligen Initialisierungsvektor verschlüsselt wird.

Der kryptographische Unterschied zwischen TLS 1.0 und TLS 1.1 ist marginal und es gibt einen trivialen und abwärtskompatiblen Workaround mittels 1/(n-1) TLS record splitting, welcher diesen marginalen Unterschied zwischen TLS 1.0 und TLS 1.1 formal beweisbar irrelevant macht. Dieser triviale Workaround wurde von allen von BEAST betroffenen Anwendungen im Laufe des Jahres 2011 eingebaut. BEAST betrifft nur Webbrowser, Java im Browser und SSL-VPNs, weil BEAST nur als Inside-Angriff möglich ist.

Kompressionsangriffe

Die Verwendung der optionalen Kompression von Nutzdaten eröffnet eine Klasse von Angriffen, die das Erraten von Teilen des Klartexts ermöglichen. Das Angriffsszenario ist ähnlich wie beim BEAST-Angriff: der Angreifer führt einen Chosen-Plaintext-Angriff durch und beobachtet die verschlüsselten TLS-Nachrichten im Netz. Das Kompressionsverfahren entfernt Redundanzen aus den Nutzdaten, sodass der zu verschlüsselnde Klartext und damit auch der Geheimtext kürzer wird. Hat der Angreifer einen Teil des unbekannten Klartexts erraten, zum Beispiel ein Zeichen eines HTTP-Cookies, so erfährt er dies aus dem Längenunterschied einer verschlüsselten TLS-Nachricht.

Der Angriff wurde 2012 von den Urhebern des BEAST-Angriffs unter dem Namen CRIME (Compression Ratio Info-leak Made Easy) veröffentlicht.

Neben SSL und TLS ist auch das SPDY-Protokoll betroffen. Als Schutzmaßnahme wird von der Verwendung der Kompression abgeraten. TLS ab Version 1.3 unterstützt keine Kompression mehr. Der SPDY-Nachfolger HTTP/2 verwendet ein vereinfachtes Kompressionsformat (HPACK), das weniger effizient komprimiert als Deflate, dafür aber schwerer anzugreifen ist.

TIME und BREACH sind verbesserte Varianten des Angriffs. TIME (Timing Info-leak Made Easy) leitet die Größe einer verschlüsselten TLS-Nachricht aus der Antwortzeit her, ohne dass der Netzwerkverkehr abgehört werden muss.

Beide Angriffe erlauben das Erraten von TLS-verschlüsselten Inhalten, wenn TLS-Kompression abgeschaltet ist und stattdessen HTTP-Kompression verwendet wird. Da TLS Kompressionsangriffe nicht grundsätzlich verhindern kann, müssen anwendungsspezifische Schutzmaßnahmen verwendet werden, zum Beispiel der vollständige Verzicht auf Kompression.

Downgrade auf Exportverschlüsselung

Als Folge der Exportbeschränkungen von Kryptographie aus den Vereinigten Staaten sind in TLS zahlreiche exporttaugliche Cipher Suites spezifiziert, die nur kurze Schlüssel verwenden. Trotz bekannter Sicherheitsschwächen wurden oder werden diese zum Teil noch von Implementierungen unterstützt. Der TLS-Handshake soll eigentlich verhindern, dass ein Man-in-the-Middle-Angreifer einen Downgrade auf eine nicht angefragte Cipher Suite erzwingen kann, indem die Handshake-Nachrichten authentifiziert werden. Die Sicherheit der Authentifizierung hängt allerdings auch von der ausgehandelten Cipher Suite ab, sodass der Angreifer den Schlüssel brechen kann.

Beim 2015 veröffentlichten FREAK-Angriff (Factoring RSA Export Keys) findet ein Downgrade auf RSA-basierte Cipher Suites mit 512 Bit langen Exportschlüsseln statt.

Der Angriff setzt einen Implementierungsfehler voraus, bei dem der Client den 512-Bit-Schlüssel anstatt des längeren Schlüssels aus dem Serverzertifikat verwendet. Der Fehler betraf unter anderem OpenSSL und SecureTransport (Apple).

Kurz darauf veröffentlichte ein Forscherteam den Logjam-Angriff, der einen Downgrade des Diffie-Hellmans auf 512-Bit-Restklassengruppen ermöglicht. Ursache ist die Unterstützung von exporttauglichen Cipher Suites mit Ephemeral Diffie-Hellman.

Anders als bei FREAK handelt es sich um eine Protokollschwäche in TLS, die auch ohne Implementierungsfehler ausgenutzt werden kann. Der Logjam-Angriff kann in der Praxis performant durchgeführt werden, da ein Großteil der Rechenarbeit zum Brechen des Schlüssels schon vor dem Verbindungsaufbau durchgeführt werden kann. Der erforderliche Rechenaufwand während des eigentlichen Schlüsselaustauschs dauert etwa 70 Sekunden. Als Schutzmaßnahme sollten Server die Unterstützung für exporttaugliche Cipher Suites abschalten und mindestens 2048 Bit lange Gruppen verwenden. Clients sollten Gruppen verwerfen, die kürzer als 1024 Bit sind.

Implementierungsfehler

Neben Sicherheitsschwächen im Protokoll sind TLS-Implementierungen in wiederkehrender Regelmäßigkeit von sicherheitsrelevanten Implementierungsfehlern betroffen. Einer der schwerwiegendsten Fehler war der 2014 entdeckte Heartbleed-Bug in OpenSSL.

Öffentlicher und vorsätzlicher Bruch der Verschlüsselung

Über die ETSI wurde ein sozialer Angriff auf den TLS-Standard gestartet, bei dem eine nachschlüsselfähige und daher als gebrochen anzusehende Version des Standards Eingang in allgemeine Kommunikationsprozesse finden soll.

Die Angreifer leiten eine Berechtigung für ihren Angriff auf die Verschlüsselung daraus ab, dass es in der Wirtschaft, insbesondere in der Finanzindustrie, sowie bei Behörden Möglichkeiten geben müsse, übergeordneten Einblick in verschlüsselte Kommunikation zu nehmen, ohne dass die Beteiligten davon erfahren.

Viele Fachleute und Organisationen, wie z. B. die EFF, warnen aufgrund der möglichen Kollateralschäden sehr deutlich vor der Nutzung dieses Verfahrens.

Der Versuch, diese defekte Verschlüsselung als „eTLS“ („Enterprise TLS“)

in die TLS-Familie einzuführen, wurde über die Namensrechte an TLS abgewehrt, weshalb das Verfahren in ETS umbenannt werden wird.

Da ETS/eTLS als CVE von TLS anerkannt ist, kann man ETS/eTLS auch als (vorsätzlich) fehlerhafte Implementierung von TLS bezeichnen.

Infolgedessen erhielt das Technical Committee CYBER des ETSI 2019 den Negativpreis BigBrotherAward:Vorlage:Zitat

TMP

Sicherheit

Auf SSL und TLS sind jeweils eine Reihe von Angriffen bekannt, die die Sicherheitsgarantien untergraben

Die folgende Liste stellt einen Teil der bekannten Angriffe dar

Padding-Oracle-Angriffe

Der Kryptologe Serge Vaudenay entdeckte 2002, dass ein Man-in-the-Middle-Angreifer aus dem Padding einer mit dem Cipher Block Chaining Mode (CBC) verschlüsselten Nachricht Informationen erhalten kann, die zur Entschlüsselung der Nachricht genutzt werden können

Durch gezielte Manipulation einer verschlüsselten Nachricht lernt der Angreifer, ob der Server ein gültiges Padding meldet und damit ein Teil des Klartexts richtig erraten wurde

Als Schutzmaßnahme sollte der Server ungültige Nachrichten verwerfen, ohne dabei zu offenbaren, ob das Padding oder die Nachrichtenauthentizität ungültig war

Allerdings kann ein Angreifer diese Information auch durch eine Analyse der Antwortzeiten herleiten (Timing-Angriff)
Betroffen sind SSL, TLS bis Version 1.2 und DTLS, sofern eine Cipher Suite mit CBC verwendet wird
Cipher Suites mit Authenticated Encryption sind nicht betroffen

Im Oktober 2014 demonstrierten Sicherheitsforscher den POODLE-Angriff (Padding Oracle On Downgraded Legacy Encryption), mit dem ein Angreifer ein Versions-Downgrade einer TLS-Verbindung erzwingt, um einen Padding-Oracle-Angriff gegen SSL 3.0 durchzuführen

Zwecks Kompatibilität wurde SSL 3.0 trotz zu dem Zeitpunkt bekannter Sicherheitsschwächen noch von Webbrowsern und anderen Implementierungen unterstützt
Im Nachgang hat die Internet Engineering Task Force SSL 3.0 als überholt gekennzeichnet

und ein Verfahren zum Schutz vor Downgrade-Angriffen auf TLS spezifiziert

BEAST

SSL 3.0 und TLS 1.0 verwenden im CBC-Modus einen vorhersagbaren Initialisierungsvektor

Ein Angreifer kann dadurch mit einem Chosen-Plaintext-Angriff unbekannte Teile des Klartexts ermitteln
Ein Angriffsszenario ist das Stehlen von HTTP-Cookies, die verschlüsselt übertragen werden
Hierzu muss der Angreifer das Angriffsopfer auf eine bösartige Website locken, die wiederholt HTTP-Anfragen an eine fremde Domain auslöst, wobei der Webbrowser automatisch die für die Domain gesetzten HTTP-Cookies mitsendet
Durch den teilweise selbst gewählten Inhalt der HTTP-Anfragen und durch Abhören der verschlüsselten TLS-Nachrichten kann der Angreifer das Cookie zeichenweise erraten

Die Grundlagen des Angriffs wurden 2004 beschrieben und 2011 erstmals in der Praxis unter dem Namen BEAST (Browser Exploit Against SSL/TLS) demonstriert

TLS-Version 1.1 und höher sind nicht betroffen, da jede Nachricht mit einem pseudozufälligen Initialisierungsvektor verschlüsselt wird

Der kryptographische Unterschied zwischen TLS 1.0 und TLS 1.1 ist marginal und es gibt einen trivialen und abwärtskompatiblen Workaround mittels 1/(n-1) TLS record splitting, welcher diesen marginalen Unterschied zwischen TLS 1.0 und TLS 1.1 formal beweisbar irrelevant macht

Dieser triviale Workaround wurde von allen von BEAST betroffenen Anwendungen im Laufe des Jahres 2011 eingebaut
BEAST betrifft nur Webbrowser, Java im Browser und SSL-VPNs, weil BEAST nur als Inside-Angriff möglich ist

Kompressionsangriffe

Die Verwendung der optionalen Kompression von Nutzdaten eröffnet eine Klasse von Angriffen, die das Erraten von Teilen des Klartexts ermöglichen

Das Angriffsszenario ist ähnlich wie beim BEAST-Angriff: der Angreifer führt einen Chosen-Plaintext-Angriff durch und beobachtet die verschlüsselten TLS-Nachrichten im Netz
Das Kompressionsverfahren entfernt Redundanzen aus den Nutzdaten, sodass der zu verschlüsselnde Klartext und damit auch der Geheimtext kürzer wird
Hat der Angreifer einen Teil des unbekannten Klartexts erraten, zum Beispiel ein Zeichen eines HTTP-Cookies, so erfährt er dies aus dem Längenunterschied einer verschlüsselten TLS-Nachricht

Der Angriff wurde 2012 von den Urhebern des BEAST-Angriffs unter dem Namen CRIME (Compression Ratio Info-leak Made Easy) veröffentlicht

Neben SSL und TLS ist auch das SPDY-Protokoll betroffen

Als Schutzmaßnahme wird von der Verwendung der Kompression abgeraten
TLS ab Version 1.3 unterstützt keine Kompression mehr
Der SPDY-Nachfolger HTTP/2 verwendet ein vereinfachtes Kompressionsformat (HPACK), das weniger effizient komprimiert als Deflate, dafür aber schwerer anzugreifen ist

TIME und BREACH sind verbesserte Varianten des Angriffs

TIME (Timing Info-leak Made Easy) leitet die Größe einer verschlüsselten TLS-Nachricht aus der Antwortzeit her, ohne dass der Netzwerkverkehr abgehört werden muss
Beide Angriffe erlauben das Erraten von TLS-verschlüsselten Inhalten, wenn TLS-Kompression abgeschaltet ist und stattdessen HTTP-Kompression verwendet wird
Da TLS Kompressionsangriffe nicht grundsätzlich verhindern kann, müssen anwendungsspezifische Schutzmaßnahmen verwendet werden, zum Beispiel der vollständige Verzicht auf Kompression

Downgrade auf Exportverschlüsselung

Als Folge der Exportbeschränkungen von Kryptographie aus den Vereinigten Staaten sind in TLS zahlreiche exporttaugliche Cipher Suites spezifiziert, die nur kurze Schlüssel verwenden

Trotz bekannter Sicherheitsschwächen wurden oder werden diese zum Teil noch von Implementierungen unterstützt
Der TLS-Handshake soll eigentlich verhindern, dass ein Man-in-the-Middle-Angreifer einen Downgrade auf eine nicht angefragte Cipher Suite erzwingen kann, indem die Handshake-Nachrichten authentifiziert werden
Die Sicherheit der Authentifizierung hängt allerdings auch von der ausgehandelten Cipher Suite ab, sodass der Angreifer den Schlüssel brechen kann

Beim 2015 veröffentlichten FREAK-Angriff (Factoring RSA Export Keys) findet ein Downgrade auf RSA-basierte Cipher Suites mit 512 Bit langen Exportschlüsseln statt

Der Angriff setzt einen Implementierungsfehler voraus, bei dem der Client den 512-Bit-Schlüssel anstatt des längeren Schlüssels aus dem Serverzertifikat verwendet
Der Fehler betraf unter anderem OpenSSL und SecureTransport (Apple)

Kurz darauf veröffentlichte ein Forscherteam den Logjam-Angriff, der einen Downgrade des Diffie-Hellmans auf 512-Bit-Restklassengruppen ermöglicht

Ursache ist die Unterstützung von exporttauglichen Cipher Suites mit Ephemeral Diffie-Hellman
Anders als bei FREAK handelt es sich um eine Protokollschwäche in TLS, die auch ohne Implementierungsfehler ausgenutzt werden kann
Der Logjam-Angriff kann in der Praxis performant durchgeführt werden, da ein Großteil der Rechenarbeit zum Brechen des Schlüssels schon vor dem Verbindungsaufbau durchgeführt werden kann
Der erforderliche Rechenaufwand während des eigentlichen Schlüsselaustauschs dauert etwa 70 Sekunden
Als Schutzmaßnahme sollten Server die Unterstützung für exporttaugliche Cipher Suites abschalten und mindestens 2048 Bit lange Gruppen verwenden
Clients sollten Gruppen verwerfen, die kürzer als 1024 Bit sind

Implementierungsfehler

Neben Sicherheitsschwächen im Protokoll sind TLS-Implementierungen in wiederkehrender Regelmäßigkeit von sicherheitsrelevanten Implementierungsfehlern betroffen

Einer der schwerwiegendsten Fehler war der 2014 entdeckte Heartbleed-Bug in OpenSSL

Öffentlicher und vorsätzlicher Bruch der Verschlüsselung

Über die ETSI wurde ein sozialer Angriff auf den TLS-Standard gestartet, bei dem eine nachschlüsselfähige und daher als gebrochen anzusehende Version des Standards Eingang in allgemeine Kommunikationsprozesse finden soll

Die Angreifer leiten eine Berechtigung für ihren Angriff auf die Verschlüsselung daraus ab, dass es in der Wirtschaft, insbesondere in der Finanzindustrie, sowie bei Behörden Möglichkeiten geben müsse, übergeordneten Einblick in verschlüsselte Kommunikation zu nehmen, ohne dass die Beteiligten davon erfahren Viele Fachleute und Organisationen, wie z. B

die EFF, warnen aufgrund der möglichen Kollateralschäden sehr deutlich vor der Nutzung dieses Verfahrens

Der Versuch, diese defekte Verschlüsselung als „eTLS“ („Enterprise TLS“) in die TLS-Familie einzuführen, wurde über die Namensrechte an TLS abgewehrt, weshalb das Verfahren in ETS umbenannt werden wird

Da ETS/eTLS als CVE von TLS anerkannt ist, kann man ETS/eTLS auch als (vorsätzlich) fehlerhafte Implementierung von TLS bezeichnen

Infolgedessen erhielt das Technical Committee CYBER des ETSI 2019 den Negativpreis BigBrotherAward: Vorlage:Zitat

TMP

Sicherheit

Angriffe und Schwachstellen

Mit den allgemein zunehmenden Kenntnissen über die HTTPS-Technik haben sich auch die Angriffe auf SSL-gesicherte Verbindungen gehäuft

Daneben sind durch Recherche und Forschungen Lücken in der Umsetzung bekannt geworden
Dabei ist grundsätzlich zu unterscheiden zwischen Schwachstellen bei der Kryptografie selbst und im Zertifikatsystem. 2013 wurde im Zusammenhang mit der globalen Überwachungs- und Spionageaffäre bekannt, dass die NSA beide Angriffskanäle nutzte, um Zugang zu verschlüsselten Verbindungen zu erlangen

Kryptografie

Die bei SSL eingesetzten Kryptografieverfahren werden unabhängig von ihrem Einsatzzweck regelmäßig überprüft und gelten als mathematisch sicher, d. h., sie lassen sich theoretisch mit den heute bekannten Techniken nicht brechen

Die Zuverlässigkeit der Algorithmen wird regelmäßig etwa durch Wettbewerbe unter Kryptologen überprüft
Regelmäßig werden in den Spezifikationen und den Implementierungen die Unterstützung veralteter Kryptografieverfahren, die nach dem aktuellen Stand der Technik als nicht mehr sicher gelten, gestrichen und neue Verfahren aufgenommen

Probleme entstanden in der Vergangenheit mehrfach durch fehlerhafte Implementierung der Kryptografie

Insbesondere Schwachstellen in der weit verbreiten OpenSSL-Bibliothek wie Heartbleed haben dabei große öffentliche Aufmerksamkeit erfahren

Da in der Regel Benutzer nicht explizit eine verschlüsselte Verbindung durch Spezifizierung des HTTPS-Protokolls (https://) beim Aufruf einer Webseite anfordern, kann ein Angreifer eine Kryptografie der Verbindung bereits vor Initialisierung unterbinden und einen Man-in-the-Middle-Angriff ausführen

Speziell zur Abwehr von Downgrade-Attacken gegen die Kryptografie sowie von Session Hijacking wurde 2012 das Verfahren HTTP Strict Transport Security oder HSTS vorgestellt

Es wird durch einen HSTS-Header seitens des Servers aktiviert, worauf im Browser u. a.http- in https-URLs umgewandelt werden

Zertifikatsystem

SSL-Verbindungen sind grundsätzlich gefährdet durch Man-in-the-Middle-Angriffe, bei denen der Angreifer den Datenverkehr zwischen Client und Server abfängt, indem dieser sich beispielsweise als Zwischenstelle ausgibt

Eine Reihe von Angriffsverfahren setzen voraus, dass sich der Angreifer im Netzwerk des Opfers befindet
Beim DNS-Spoofing wiederum bestehen diese Voraussetzungen nicht

Um sich als (anderer) Server auszugeben, muss der Angreifer auch ein Zertifikat vorweisen

Das ist ihm beispielsweise dann möglich, wenn es ihm gelingt, in das System einer Zertifizierungsstelle einzudringen, oder er anderweitig in den Besitz eines Zertifikats kommt, mit dem sich beliebige andere Zertifikate ausstellen lassen
Insbesondere bei einflussreichen Angreifern, wie etwa Regierungsbehörden, können solche Möglichkeiten bestehen, da mitunter auch staatliche Zertifizierungsstellen existieren. HTTP Public Key Pinning und Certificate Transparency sollen solche Angriffe erschweren

Phishing und HTTPS

Ein Nachteil der automatischen Bestätigung der Zertifikate besteht darin, dass der Anwender eine HTTPS-Verbindung nicht mehr bewusst wahrnimmt

Das wurde in jüngerer Zeit bei Phishing-Angriffen ausgenutzt, die etwa Online-Banking-Anwendungen simulieren und dem Anwender eine sichere Verbindung vortäuschen, um eingegebene PIN/TAN-Codes „abzufischen“
Als Reaktion wiesen betroffene Unternehmen ihre Kunden darauf hin, keine Links aus E-Mails anzuklicken und https-URLs nur manuell oder per Lesezeichen einzugeben

Wegen der teils oberflächlichen Prüfungen bei der Vergabe von Zertifikaten wurde von den Browserherstellern das extended-validation-Cert eingeführt, siehe oben

Gemischte Inhalte

Das Nachladen unverschlüsselter Ressourcen ermöglicht einem Angreifer, mittels eines Man-in-the-Middle-Angriffs Schadcode in die ursprünglich verschlüsselt übertragene Webseite einzuschleusen

Daher blockieren aktuelle Versionen gängiger Webbrowser das Nachladen unverschlüsselter Ressourcen standardmäßig
Ebenso besteht bei einem sowohl für verschlüsselte als auch unverschlüsselte Verbindungen genutzten HTTP-Cookie das Risiko eines Session Hijacking, auch wenn die Authentifizierung über eine verschlüsselte Verbindung erfolgte

Schwachstelle MD5

Auf dem 25. Chaos Communication Congress in Berlin wurde im Dezember 2008 ein erfolgreicher Angriff auf das SSL-Zertifikatsystem veröffentlicht

In internationaler Zusammenarbeit von Kryptologen und mit Einsatz speziell programmierter Hardware – einem Cluster aus 200 Playstation-3-Spielkonsolen – war es gelungen, im MD5-Algorithmus eine Kollision zu erzeugen, auf deren Basis ein Angreifer sich selbst beliebige Zertifikate ausstellen könnte. Von der Verwendung des MD5-Algorithmus wurde in Fachkreisen vorher schon abgeraten; bei EV-Zertifikaten kann er ohnehin nicht verwendet werden
Die meisten Webbrowser akzeptieren schon seit 2011 keine MD5-Zertifikate mehr. Um ähnliche Probleme zu vermeiden, kündigten die Browser-Hersteller darauf an, auch SHA1-Zertifikate nur noch eine beschränkte Zeit zu unterstützen