Content tagged tls

Kompatibilität von 8192-Bit-Zertifikaten

posted on

Aufgrund der Tatsache, dass die Hardware mit denen Public-Key-Schlüssel angegriffen werden kann immer leistungsfähiger wird, ist es notwendig, dass auch die Größe der eingesetzten Schlüssel immer weiter vergrößert wird.

Für den Einsatz mit qualifizierten digitalen Signaturen in Deutschland veröffentlicht beispielsweise die Bundesnetzagentur jährlich den sogenannten Algorithmenkatalog. In ihm steht jeweils welche Mindestschlüssellänge bis zu welchem Zeitpunkt als ausreichend angesehen werden kann.

Aktuell wird für den Einsatz von RSA-Schlüsseln bis Ende 2018 beispielsweise empfohlen, dass diese mindestens 2048 Bit lang sein sollten.

Dies betrifft aber natürlich nicht nur qualifizierte Signaturen sondern beispielsweise auch die verschlüsselte Übertragung von Webseiten mit dem HTTPS-Protokoll. Auch hierfür werden meistens RSA-Schlüssel eingesetzt. Üblicherweise trifft man auf Webservern dabei meistens Schlüssel der empfohlenen Länge an. (Ergebnis einer nicht repräsentativen Überprüfung einiger Websites durch mich.)

Natürlich kann man aber auch längere Schlüssel erzeugen und genau das habe ich gemacht bevor ich mir mein letztes Zertifikat habe ausstellen lassen. Der zugehörige RSA-Schlüssel ist 8192 Bit lang. Sicher eine an sich zur Zeit noch übertriebene Schlüssellänge, aber ein interessanter Key um damit zu testen ob alle Browser mit Keys dieser länge umgehen können.

ChromeFirefoxInternet Explorer 9Opera 12Safari 6
Linux (Debian wheezy)OKOK-OK-
Mac OS X (10.8)Meldung „Ungültiges Serverzertifikat“. Fehler kann nicht ignoriert werden.OK-OKLaden der Seite hängt, keine Fehlermeldung
Windows 7OKOKOKOK- (Safari 5: OK)

Wer sicherstellen möchte, dass seine Seite problemlos von allen Nutzern angeschaut werden kann, sollte zur Zeit also noch keine 8192-Bit-Schlüssel einsetzen, da er ansonsten einen Großteil von Mac-OS-X-Nutzern ausschließt.


Fehlermeldung von Chrome unter Mac OS X 10.8.1

TODO: Es interessiert mich noch, wie es mit älteren Versionen von Windows aussieht. Ich habe es noch nicht getestet, aber es könnte sein, dass es unter Windows XP anders aussieht als unter Windows 7.

Probleme mit TLS-Verbindungen bei StartSSL-Zertifikaten

posted on

Ich greife mit zwei E-Mail-Programmen auf meinen Mailaccount zu. Das eine ist mutt, das andere ist Thunderbird. Während ich mit mutt keine Probleme habe, kann ich seit zwei Tagen mit Thunderbird nicht mehr auf mein E-Mail-Konto zugreifen.

Wenn ich es probiere, dann sehe ich Thunderbird für etwa 20 Sekunden versuchen eine Verbindung mit dem Mailserver aufzubauen. Nach diesen 20 Sekunden stellt sich Thunderbird wieder so als hätte es nicht versucht E-Mails abzufragen. Es kommt also auch keine Fehlermeldung oder dergleichen.

Da ich meinen Mailserver selbst betreibe, habe ich auch die Gelegenheit in dessen Logfile zu schreiben. Besonders aussagekräftig ist der Eintrag dort allerdings auch nicht:

Jul 11 22:30:24 eder imapd: couriertls: read: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate

Das heißt so viel wie „der Client hat uns gesagt, dass er unser Zertifikat nicht akzeptiert, mehr weiß ich auch nicht“.

Ich habe eine ganze Zeit gesucht an was es liegen könnte, dass mein Thunderbird das Zertifikat des Mailservers nicht mehr akzeptiert. Des Rätsels Lösung ist, dass ich Thunderbird so eingestellt habe, dass er jedes Zertifikat bei der jeweiligen Zertifizierungsstelle (in meinem Fall StartSSL) überprüft, ob es inzwischen zurückgezogen wurde. Hierzu gibt es das Protokoll OCSP (Online Certificate Status Protocol).

Screenshot von den OCSP-Einstellungen meines Thunderbirds.
OCSP-Einstellungen von Thunderbird. Zu erreichen über Einstellungen > Erweitert > Zertifikate > Validierung

Hier liegt auch das aktuelle Problem: StartSSL scheint aktuell nicht in der Lage zu sein OCSP-Anfragen zu beantworten. Und eine weitere Einstellung in meinem Thunderbird sagt diesem: „Wenn eine OCSP-Server-Verbindung fehlschlägt, das Zertifikat als ungültig betrachten“. Soweit ich weiß, ist diese Einstellung per Default in den Mozilla-Produkten ausgeschaltet. Ich halte dies jedoch für keine gute Idee, da auf diesem Weg von einem Angreifer sehr einfach eine Überprüfung eines ggf. gestohlenen Zertifikates über OCSP verhindert werden kann. Er müsste nur dafür sorgen, dass kein Connect zum Zertifikatsherausgeber mehr gelingt. Diese Einstellung abzusichern ist bei der Konfiguration von Thunderbird also immer eines der ersten Dinge die ich mache.

Auch jetzt habe ich mich dazu entschlossen, dass ich diese Einstellung in meinem Mailprogramm nicht lockere sondern stattdessen besser vorübergehend auf den Einsatz von Thunderbird verzichte und all meine E-Mails mit mutt lese. Man könnte zwar nun sagen, dass dieser aktuell ja auch nur funktioniert, da er keiene OCSP-Überprüfung durchführt. Allerdings läuft mein mutt auf dem gleichen Server wie auch mein Mailserver. Da aller Traffic nur über das loopback-Device läuft habe ich hier geringere Sorgen auf diesem Weg angegriffen zu werden. Wenn jemand in der Lage ist diese IP-Pakete zu modifizieren, dann hat er solchen Zugriff auf den Server, dass er sich diese Mühen nicht mehr machen muss. Er verfügt dann ohnehin über mehr Möglichkeiten.

Was man an der ganzen Erfahrung eigentlich am Meisten enttäuscht ist, dass mir Thunderbird keine Fehlermeldung ausgibt. Ein Hinweis, dass die OCSP-Abfrage beim Herausgeber des Zertifikates nicht möglich war und er das Zertifikat des Servers deswegen ablehnt, hätte mir viel Problemsuche erspart. Oder zumindest nur eine Ausgabe, dass das Zertifikat ungültig sei, hätte mir zumindest die Suche nach dem Grund dafür erleichtert. Ich habe einen Bug hierzu bei Thunderbird aufgemacht. Vielleicht baut ja jemand eine entsprechende Fehlermeldung in zukünftige Versionen ein.

Mein Dank geht übrigens an Milan Berger, er hat mich mit seinem Blogpost OCSP, StartSSL und Performanceeinbußen auf den richtigen Weg gebracht die Ursache zu finden.

Nachtrag 12. Juli 2012, 10:00

Aktuell scheint der OCSP-Responder von StartSSL wieder zu funktionieren. Thunderbird akzeptiert das Zertifikat meines Mailservers wieder.

Virtuelles Hosting für HTTPS mit Apache und mod_gnutls

posted on

Die IPv4-Adressen gehen aus – so ließt man. Im Februar 2011 wurde die letzte freie Adresse in Europa vergeben. Was seitdem getan wird: nichts. Trotzdem leiste ich meinen Beitrag: ich spare IPv4-Adressen mit virtuellem Hosting auch für HTTPS.

HTTPS und die IP-Adressen

Der wichtigste Grund warum ein Webserver mehrere IP-Adressen hat ist HTTPS. Für jede HTTPS-Domain brauchte man bisher eine eigene IP-Adresse. Die Verschlüsselung von HTTPS wird aktiviert bevor der Webbrowser dem Server sagt welche Webadresse er abrufen möchte. Das Problem dabei: das Zertifikat welcher Domain soll der Server nun benutzen? Verwendet er das falsche meckert der Browser. Eine rote Seite erscheint und warnt den Internetnutzer, dass da etwas nicht stimmt und die Seite vielleicht unsicher ist. Das wollen wir nicht!

Die Lösung bisher: jede Domain hat eine eigene IP-Adresse. Muss ein Webserver eine HTTPS-Anfrage beantworten, schaut er welche IP-Adresse angesprochen wurde. Kein Problem, das kann er. Für jede IP-Adresse weiß er die zugehörige Domain. Er kann das richtige Zertifikat nutzen.

Schon 2003 aber wurde Server Name Indication (engl. für „Andeutung des Servernamens“) erfunden [RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions]. Moderne Browser übermitteln hiermit schon bevor verschlüsselt wird welche Domain sie erwarten. Wenn sich der Browser an diesen Standard hält, dann kann der Webserver auch ohne verschiedene IP-Adressen erkennen welches Zertifikat er nutzen muss.

Funktioniert das auch immer?

Nein! Sowohl der Browser als auch der Server muss das Verfahren unterstützen. Probleme gibt es wenn der Nutzer mit einem Internet Explorer Version 6 oder mit Windows XP unterwegs sind. Beides ist aber inzwischen selten. Mit anderen Browsern und Betriebssystemen gibt es keine Probleme mehr.

Und der Server? Das haben wir Administratoren selbst in der Hand. Ich nutze Apache mit mod_gnutls. Server Name Indication versteht dieses seit irgendwann zwischen April 2005 (Version 0.2.0) und November 2007 (Version 0.3.4).

Also passt alles?

Leider nein. Ich hatte alles nach Anleitung eingerichtet. Die Fehlermeldungen sind nicht verschwunden. Immer wieder beschwerte sich der Browser: das Zertifikat ist falsch.

Suchen wir mit Google. Es gibt fast kein Problem, das ein anderer schon hatte. Tatsächlich: Jan Krüger beschreibt das gleiche Problem in mod_gnutls and StartSSL level 1 certificates: the problem (and solution).

mod_gnutls berücksichtigt nur die im Feld CN (Common Name) des Zertifikates eingetragene Domain. Dort ist aber nur Platz für eine einzelne Domain. Steht ein Zertifikat für mehrere Domains (z.B. mit ohne ohne „www“), so werden diese in einem anderen Feld eingetragen: Subject Alternative Name / dnsName. Solche Zertifikate hatte ich von StartSSL bekommen.

Jan hat hierfür einen Patch geschrieben und veröffentlicht. Allerdings unterstützt seine Lösung nur bis zu vier Domains pro Zertifikat. In den meisten Fällen reicht das sicherlich. Trotzdem wollte ich das Problem noch allgemeiner lösen.

Meine Version des gnu_tls-Patches kann mit einer beliebigen Anzahl von Domains in einem Zertifikat umgehen.

Ich wollte meine Verbesserung auch anderen Nutzern von Debian und mod_gnutls einfach zur Verfügung stellen. Eine E-Mail habe ich an den Debian-Paket-Betreuer und den Entwickler von mod_gnutls geschickt. Beide kamen unzustellbar zurück.


Unless otherwise credited all material Creative Commons License by Matthias Wimmer