Schlagwort-Archive: SHA-2

SHA-1 Kollisionen und deren Bedeutung für die DFN-PKI

Wissenschaftler vom CWI Amsterdam und von Google haben eine Forschungsarbeit veröffentlicht, in der praktisch vorgeführt wird, wie Kollisionen für den Hashalgorithmus SHA-1 berechnet werden können. Dabei ist es gelungen, zwei PDF-Dokumente so zu konstruieren, dass sie denselben Hashwert besitzen.

http://shattered.io/

Artikel auf Heise: https://www.heise.de/newsticker/meldung/Todesstoss-Forscher-zerschmettern-SHA-1-3633589.html

Artikel Golem: https://www.golem.de/news/kollissionsangriff-hashfunktion-sha-1-gebrochen-1702-126355.html

Die Auswirkungen für die DFN-PKI sind nach unserer Einschätzung gering, denn noch ist niemand in der Lage, sogenannte Pre-Image-Angriffe durchzuführen. Dies bedeutet, dass es noch nicht möglich ist, zu einem bestehenden alten Zertifikat ein zweites, „gefälschtes“ mit identischer Signatur, aber anderen Daten zu berechnen.

Der jetzt veröffentlichte Angriff setzt nach unserem Kenntnisstand voraus, dass beide Datenobjekte, das „Original“ und die „Fälschung“, hochvariable Daten unter Angreiferkontrolle beinhalten. Ein erfolgreicher Angriff wäre damit nur möglich, wenn die DFN-PKI weiterhin Zertifikate oder andere Daten mit SHA-1 signieren würde. Dies ist nicht der Fall, die DFN-PKI ist komplett auf SHA-2 umgestiegen.

Daraus folgt: Der neue Angriff ändert noch nichts an der Sicherheit von bestehenden Zertifikaten der DFN-PKI, selbst wenn sie mit SHA-1 signiert sein sollten.

Es gilt aber natürlich nach wie vor: Die Verwendung von SHA-1-signierten Zertifikaten (sei es als Sub-CA-Zertifikat, als Server- oder als Nutzerzertifikat) sollte sehr zügig beendet werden, da die weitere Entwicklung nicht absehbar ist. Insbesondere sollten Sie darauf achten, dass Sie bei der Inbetriebnahme eines neuen SHA-2-Zertifikats auch die neue SHA-2-Zwischenzertifizierungskette einbinden.

Hinweis: Aktuelle Versionen von z.B. Google Chrome oder Internet Explorer/Edge lehnen SHA-1-signierte Server- oder Sub-CA-Zertifikate ab. Ob Sie Ihren Server korrekt konfiguriert haben, können Sie z.B. mit https://www.ssllabs.com/ssltest/ überprüfen.

Spezialfall Wurzelzertifikat

Die Tatsache, dass die erste Generation der DFN-PKI mit der „Deutsche Telekom Root CA 2“ aufgebaut ist, führt ebenfalls mit dem jetzt vorgestellten Angriff nicht zu Problemen. Dieses Wurzelzertifikat trägt zwar eine SHA-1-Selbstsignatur. Diese hat aber keine Sicherheitsfunktion. Dem Wurzelzertifikat wird vertraut, weil es in der Software (z.B. Betriebssystem, Webbrowser) fest vorinstalliert ist, die Signatur spielt keine Rolle. Siehe hierzu auch den Artikel in unserer FAQ: https://www.pki.dfn.de/faqpki/faq-umstellung-sha-2/#c18430

(jbr, 24.02.2017)

Alte SHA-1-Serverzertifikate in der Java RA-Oberfläche identifizieren

Da die nächste Phase der SHA-1-Abschaltung durch die Web-Browser ab Anfang 2017 ins Haus steht, ist es an der Zeit, die alten SHA-1-Serverzertifikate endgültig auszutauschen. Ein Blick in die Java RA-Oberfläche kann bei der Identifizierung der betroffenen Serverzertifikate helfen:

  1. Öffnen Sie in der Java RA-Oberfläche die Übersichtsliste der gültigen Zertifikate.
  2. Geben Sie in den Suchfilter „SHA“ ein und schränken Sie die Suche über die Häkchen der Suchoptionen auf das Zertifikatsprofil ein. Hierdurch finden Sie alle gültigen SHA-1-Zertifikate die nach der generischen SHA-1-auf-SHA-2-Umstellung im Sommer 2014 über ein spezielles SHA-1-Zertifikatprofil ausgestellt worden sein könnten. (Einige DFN-PKI Nutzer haben sich diese speziellen SHA-1-Zertifikatsprofile für Spezialanwendungen zu einer Zeit konfigurieren lassen, als dieses durch die DFN-PKI Global Policy und die Baseline Requirements des CA/Browser-Forums noch erlaubt war.)
  3. Setzen Sie die Suchoptionen zurück, so dass wieder alle gültigen Zertifikate angezeigt werden.
  4. Sortieren Sie diese nun nach absteigender „Seriennummer“ bzw. „Gültig ab“ Spalte.
  5. Suchen Sie dann das jüngste Zertifikat in der Liste (dieses müsste so zwischen Mai 2014 und Juli 2014 oder früher ausgestellt worden sein), das mit dem SHA-1-Signaturalgorithmus signiert worden ist aber kein spezielles SHA-1-Zertifikatprofil besitzt. Dazu öffnen Sie kurz die Zertifikatdetails eines ausgewählten Kanditatenzertifikats und schauen darin nach einem Eintrag „Signatur Algorithmus RSA (PKCS #1 v1.5) with SHA-1 signature„. Hierdurch finden Sie alle gültigen SHA-1-Zertifikate die vor der generischen SHA-1-auf-SHA-2-Umstellung im Sommer 2014 ausgestellt worden sein könnten.
  6. Alle älteren Zertifikate sind ebenfalls mit dem SHA-1-Signaturalgorithmus signiert worden.

Spätestens jetzt zahlt es sich aus, wenn bereits ausgetauschte und außer Betrieb genommene Zertifikate gesperrt wurden, da diese von vornherein nicht mehr in der Liste der gültigen Zertifikate aufgeführt sind.

Die Java RA-Oberfläche kann nicht erkennen, ist, ob die neuen SHA-2-Serverzertifikate auf den Servern zusammen mit der SHA-2-CA-Zertifikat-Kette installiert und konfiguriert wurden. Im Blog-Artikel „Wie lässt sich feststellen, ob auf einem Server ein SHA-1-Zertifikat installiert ist?“ wird beschrieben, wie dieses überprüft werden kann.

(rkm, 02.12.2016)

Nächste Phase der SHA-1-Abschaltung durch die Web-Browser ab Anfang 2017

Die nächste Phase der SHA-1-Abschaltung durch die Web-Browser steht ab Anfang 2017 ins Haus:

Konkret bedeutet das, dass nach dem jeweiligen Stichtag Microsoft-Systeme bzw. Mozilla/Firefox und Google/Chrome Web-Browser (jeweils aktuelle Software vorausgesetzt) mit einer Zertifikatsfehlermeldung vor TLS/SSL-Verbindungen zu Servern warnen, falls diese immer noch ein altes SHA-1-Server-Zertifikat oder SHA-1-Zwischen-CA-Zertifikat der öffentlich vertrauten DFN-PKI „Global“ präsentieren.

Das mit einer SHA-1-Selbstsignatur versehene Wurzel-CA-Zertifikat „Deutsche Telekom Root CA 2“ der ersten DFN-PKI Global Generation muss auch weiterhin nicht ausgetauscht werden (siehe Erläuterung in der FAQ). Das Wurzel-CA-Zertifikat „T-TeleSec GlobalRoot Class 2“ der neuen DFN-PKI Global Generation trägt bereits eine SHA-256-Selbstsignatur.

Weiteres zum Thema:

(rkm, 02.12.2016)

SHA-2-Migration der DFN-PKI abgeschlossen

Die DFN-PKI hat seit 2013 eine Migration des Hash-Algorithmus, mit dem Signaturen unter Zertifikaten, Sperrlisten und OCSP-Antworten erstellt werden, vorgenommen.

Da bei der Migration berücksichtigt werden musste, dass Alt-Anwendungen und -Geräte unter Umständen nicht sofort mit dem neuen Algorithmus SHA-2 umgehen können, konnte der Prozess erst jetzt abgeschlossen werden.

Die Umstellungsdaten in der DFN-PKI:

  • Herbst 2013: Umstellung der ersten CAs auf SHA-2 (Grid, SLCS, DFN-eigene CAs)
  • Februar 2014: Neu signiertes PCA-Zertifikat mit SHA-2
  • Mai-Auguts 2014: Neu-Signatur der Sub-CA-Zertifikate mit SHA-2
  • Bis August 2014: Umstellung der Standard-Profile für Nutzer- und Server-Zertifikate auf SHA-2
  • Mitte 2015: Begrenzung der Laufzeit von SHA-1-Zertifikate für Alt-Geräte auf Dezember 2016
  • Dezember 2015: Abschaltung der Möglichkeit, für Alt-Geräte SHA-1-Zertifikate zu beziehen
  • März 2016: Umstellung der Signatur von OCSP-Antworten auf SHA-2
  • April 2016: Umstellung der Signatur von Zeitstempeln auf SHA-2
  • August 2016: Umstellung der Signatur von Sperrlisten (CRLs) auf SHA-2

Damit wird jetzt für die Erstellung von Signaturen in der DFN-PKI ausschließlich SHA-2 verwendet.

Weitere Informationen zur Umstellung finden Sie unter https://www.pki.dfn.de/faqpki/faq-umstellung-sha-2/

Alle Artikel in diesem Blog zu diesem Thema: https://blog.pki.dfn.de/tag/sha-2/

(jbr, 23.09.2016)

Zeitstempeldienst der DFN-PKI jetzt mit SHA-2 Signaturen

Der Zeitstempeldienst der DFN-PKI steht seit 2009 zur Nutzung im Rahmen der Satzung des DFN-Vereins zur Verfügung.

Am 14.04.2016 wurde eine neue Version der Zeitstempel-Server-Software installiert, die die Zeitstempelsignaturen mittels SHA256withRSAEncryption-Algorithmus bildet, um die Zeitstempel mit derzeit als sicher zu betrachtenden Signaturalgorithmen zu erzeugen.

SHA-2 in Zeitstempelanfragen

Um durchgängig SHA-2 zu verwenden, müssen Sie auch bei der Anfrage nach Zeitstempeln auf SHA-2 umsteigen. Bei der Erzeugung einer Zeitstempelanfrage mittels openssl geschieht dies durch die Angabe des Parameters -sha256:

$ echo "Stempel mich!" | openssl ts -sha256 -query -cert > reqest.tsq

Kompatibilität mit openssl

Die Umstellung des Signaturalgorithmus erzwingt eine kleine Änderung der Datenstrukturen der Zeitstempel: Es wird nun zur Identifikation des unterschreibenden Zertifikats anstelle eines Attributs SigningCertificate das Attribut SigningCertificateV2 nach RFC 5035 bzw. RFC5816 aufgenommen.

Hierbei gibt es leider eine Inkompatibilität mit openssl. Der openssl-Code zur Erzeugung und Verifikation von Zeitstempeln ist offensichtlich über 10 Jahre alt, und unterstützt noch kein SigningCertificateV2-Attribut:

https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/ts/ts_rsp_verify.c#L320

Ein Update von openssl wird zur Zeit diskutiert:

https://github.com/openssl/openssl/pull/771

Wegen der fehlenden Unterstützung dieser Datenstruktur, die für aktuelle Signaturalgorithmen zwingend erforderlich ist, kommt es bei der Verifikation von Zeitstempeln mit openssl zu Fehlermeldungen, z. B.:

$ openssl ts -verify -queryfile request.tsq -in response.tsr -CAfile zeitstempel-ca.pem 
Verification: FAILED
139957412427408:error:2F067065:time stamp routines:TS_CHECK_SIGNING_CERTS:
ess signing certificate error:ts_rsp_verify.c:291:

Leider ist die Verwendung des alten Attributs SigningCertificate durch unseren Dienst nicht möglich, da dieses für andere Signaturalgorithmen als SHA-1 verboten ist (siehe https://tools.ietf.org/html/rfc5816#section-2.2.1).

Die sonstigen üblichen Zeitstempel-Clients sind nicht betroffen. jarsigner und Adobe Acrobat unterstützen mittels SHA256withRSAEncryption signierte Zeitstempel nach RFC5816 völlig problemlos.

Alternatives Werkzeug zur Prüfung von Zeitstempeln

Als Alternative stellen wir Ihnen ein Java-Werkzeug zur Verfügung, mit dem Zeitstempel verifiziert werden können. Das Werkzeug benötigt BouncyCastle 1.52, und kann unter folgendem Link heruntergeladen werden:

https://info.pca.dfn.de/doc/timestampverifier-latest.tar.gz

(jbr, 20.04.2016)

Endgültiges Ende von SHA-1 in der DFN-PKI Global

Seit Mitte 2014 ist SHA-2 der Standard-Algorithmus für Signaturen in Zertifikaten der DFN-PKI. Der inzwischen veraltete Algorithmus SHA-1 wird nur noch ausnahmsweise verwendet, insbesondere aus Kompatibilitätsgründen für älteren Geräte.

In Übereinstimmung mit den Regeln des CA/Browser-Forums ist ab 30.12.2015 die Verwendung von SHA-1 zur Signatur von Zertifikaten im Sicherheitsniveau Global in der DFN-PKI auch ausnahmsweise nicht mehr möglich.

Bitte beachten Sie auch, dass insbesondere Google Chrome die Warnmeldungen in der Adresszeile beim Auftreten eines SHA-1-signierten Zertifikats in der Zertifizierungskette eines Servers in letzter Zeit deutlich verschärft hat.

Wir raten dringend dazu, noch in Betrieb befindliche SHA-1-Serverzertifikate auszutauschen. Dabei muss auch die gesamte Zertifizierungskette auf dem betreffenden Server mit ausgetauscht werden.

Weitere Informationen: https://www.pki.dfn.de/faqpki/faqpki-sha2/

(jbr, 13.11.2015)

Skript zum Testen der Zertifikatkette und SSLv3-Fähigkeit eines Servers

Es kann mühsam sein zu prüfen, welche Zertifikatkette ein HTTPS-Server ausliefert. Die Ansicht im Webbrowser ist unzuverlässig, da der Browser unter Umständen eigene Zertifikatketten bei der Anzeige verwendet.

Ein direkter Test ist daher sinnvoll. Wir haben ein kleines Testprogramm entwickelt, das als Bash-Skript unter Linux, MacOS X und Cygwin (Windows, mit installiertem openssl und curl) läuft.

Es ist verfügbar unter: https://info.pca.dfn.de/doc/testserver.sh

Das Skript stellt eine Verbindung zu einem zu testenden Server her, und untersucht die Zertifikate, die beim Verbindungsaufbau vom Server übermittelt werden. Gegebenenfalls werden Handlungsempfehlungen ausgegeben.

Zusätzlich testet das Skript, ob auf dem Server das unsichere SSL 3.0 aktiviert ist.

Das Skript wird mit dem Namen des zu testenden Servers aufgerufen, optional mit dem Port. Als Beispiel (verkürzte Ausgabe):

$ ./testserver.sh www.dfn-cert.de 443

================================================
Informationen:
--------------
Server: www.dfn-cert.de
        www.dfn-cert.de has address 193.174.13.92
        www.dfn-cert.de has IPv6 address 2001:638:714:2801:2::
Port: 443
SSLv3 ist abgeschaltet (gut!)
Serverzertifikat:
  SubjectDN:    C=DE, ST=Hamburg, L=Hamburg, O=DFN-CERT Services GmbH, CN=www.dfn-cert.de
  Seriennummer: 6586080966759854 (0x176601787c55ae)
[...]
================================================
Ergebnisse:

Kette OK: www.dfn-cert.de:443 hat eine korrekte SHA-2 Konfiguration von Serverzertifikat und Zertifikatkette. Es ist nichts weiter zu tun.

SSLv3 ist abgeschaltet (gut!)

(jbr, 17.10.2014)

Mozilla und SHA-1 Zertifikate

Nach Microsoft und Google hat auch Mozilla sein Vorgehen zur Abkündigung von SHA-1 Zertifikaten veröffentlicht.

Für Nutzer der DFN-PKI ergeben sich keine weiteren Einschränkungen, da Mozilla einen Mittelweg zwischen Microsofts und Googles Vorgehensweisen plant:

https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/

Nach aktuellem Stand wird Mozilla für Zertifikate,die einen Gültigkeitsbeginn ab 1.1.2016 haben und mit SHA-1 signiert sind, eine „Untrusted Connection“ anzeigen.

Ab 1.1.2017 wird für alle SHA-1 Zertifikate unabhängig vom Ausstellungsdatum eine „Untrusted Connection“ angezeigt.

(jbr, 24.09.2014)

Kompatibilitätsliste SHA-2

[Laufend aktualisiert]

Globalsign hat eine Liste mit Kompatibilitätsinformationen zu SHA-2 veröffentlicht:

https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility

Zusätzlich wissen wir von folgenden Produkten, dass sie Schwierigkeiten mit SHA-2 haben:

(jbr, 17.09.2014)

Wie lässt sich feststellen, ob auf einem Server ein SHA-1-Zertifikat installiert ist?

[Update 19.9.: Testprogramm um detailliertere Ausgaben erweitert]

Google und Microsoft haben Pläne veröffentlicht, nach denen ihre Software die bisher verwendeten, mit SHA-1 signierten Serverzertifikate nicht mehr akzeptieren wird: Update zu Google Chrome/SHA-1 Zertifikate

Da der Zeitplan von Google bereits dieses Jahr Auswirkungen auf die Darstellung von Webseiten in Google Chrome haben wird, empfiehlt sich ein Austausch der mit SHA-1 signierten Serverzertifikate.

Dabei ist zu beachten, dass die gesamte auf einem Server installierte Zertifikatkette (mit Ausnahme des Wurzelzertifikates „Deutsche Telekom Root CA 2“) mit SHA-2 signiert sein muss, also auch die Intermediate-CAs.

Umstellungszeitpunkt auf SHA-2 in der DFN-PKI

In der folgenden Liste ist aufgeführt, zu welchem Zeitpunkt die einzelnen CAs der DFN-PKI (Sicherheitsniveau Global) vollständig, also inklusive der Intermediate-CAs, auf SHA-2 umgestellt wurden:

Liste mit Umstellungszeitpunkten der CAs in der DFN-PKI Global

Zwischen 1.1.2011 und dem Umstellungszeitpunkt Ihrer CA  ausgestellte Serverzertifikate sind betroffen und sollten  ausgetauscht werden,  um auch weiterhin in Google Chrome und ab 2017 in Microsoft-Produkten ohne Beeinträchtigung zu funktionieren.

Vor dem 1.1.2011 ausgestellte Serverzertifikate sind zwar auch mit SHA-1 signiert, sind aber bei maximal 5 Jahren Laufzeit wegen der enthaltenen Ablaufdaten nicht von den Plänen von Google und Microsoft betroffen.

Testprogramm

Ein unter Linux laufendes Testprogramm ist verfügbar unter: https://info.pca.dfn.de/doc/testserver.sh

Das Skript stellt eine Verbindung zu einem zu testenden Server her, und untersucht die Zertifikate, die beim Verbindungsaufbau vom Server übermittelt werden. Gegebenenfalls werden Handlungsempfehlungen ausgegeben.

Das Skript wird mit dem Namen des zu testenden Servers aufgerufen, optional mit dem Port. Als Beispiel (verkürzte Ausgabe):

$ ./testserver.sh www.dfn-cert.de

================================================
Informationen:
--------------
Server: www.dfn-cert.de
        www.dfn-cert.de has address 193.174.13.92
        www.dfn-cert.de has IPv6 address 2001:638:714:2801:2::
Port: 443
Serverzertifikat:
  SubjectDN:    C=DE, ST=Hamburg, L=Hamburg, O=DFN-CERT Services GmbH, CN=www.dfn-cert.de
  Seriennummer: 6586080966759854 (0x176601787c55ae)
[...]
================================================
Ergebnisse:

Alles OK: www.dfn-cert.de:443 hat eine korrekte SHA-2 Konfiguration von Serverzertifikat und Zertifikatkette. Es ist nichts weiter zu tun.

Ansicht des Zertifikats im Browser

In Webbrowsern kann man sich üblicherweise das verwendete Serverzertifikat anschauen.

Als Beispiel der Firefox von Mozilla, mit dem Tab „Details“ in der Zertifikateansicht (erreichbar über einen Klick auf das Schloss in der Adresszeile, dann „Weitere Informationen…“, dann „Zertifikat anzeigen“) :

zertifikat

Ergebnis: Im unteren Bereich erscheint als Feld-Wert „PKCS # 1 SHA-256 mit RSA-Verschlüsselung“. Das Zertifikat ist also mit SHA-2 signiert, und müsste nicht ausgetauscht werden.

Achtung: Die Ansicht im Webbrowser verrät noch nicht, ob auch die komplette Zertifikatkette des Webservers auf SHA-2 umgestellt wurde. Insbesondere können die dargestellten Intermediate-CAs auch aus dem internen Zertifikatspeicher des Webbrowsers kommen und nicht die tatsächliche Konfiguration des Webservers widerspiegeln.

Mit dieser Webbrowser-Ansicht ist daher nur ein schneller Überblick möglich, man erhält aber keine vollständige Aussage. Eine genauere Prüfung, z.B. mit dem oben genannten Testprogramm oder auf dem Server selbst, ist also trotzdem sinnvoll.

Überprüfung durch externe Dienste

Es gibt externe Dienste, die die Konfiguration von HTTPS-Webservern prüfen und Hinweise auf Verbesserungsmöglichkeiten geben. Ein gut funktionierender Dienst ist SSL Labs (https://www.ssllabs.com/ssltest). SSL Labs gibt bei SHA-1-Zertifikaten in der Zertifizierungskette eine Warnung aus.

Externe Dienste können natürlich nur genutzt werden, wenn der betreffende Server auch von außerhalb des eigenen Netzes erreichbar ist. Bitte beachten Sie bei der Nutzung von externen Diensten, dass Sie damit Daten über Ihre Server an Dritte weitergeben.

(jbr, 17.09.2014)