Schlagwort-Archive: OpenSSL

Gentoo: OpenSSL ohne ECDHE

Unter Gentoo unterstützt OpenSSL standardmäßig kein ECDHE, welches für aktuelle Crypto kaum wegzudenken ist. Ursache sind die Lizenzbestimmungen bzw. Patente: Teile der Quellen dürfen ausschließlich als Sourcecoude verteilt werden und müssen daher aus vorkompilierten Teilen wie z.B. der Stage3 entfernt werden. Dieses entfernen wird über die USE-Flag “bindist” (Binary distribution) gesteuert, welche standardmäßig eingeschaltet ist. Um OpenSSL mit EC-Cryoto zu bauen muss bindist entfernt werden – z.B. durch ein “-bindist” in der globalen make.conf. Nach rebuild von OpenSSL und OpenSSH (sowie ggf anderer Abhängigkeiten und darauf aufbauende Software wie der Webserver) per

sollte die Crypto auch unter Gentoo verfügbar sein.

“Vernünftiges” TLS (SSL/HTTPS/…) mit Apache

Langsam aber sicher setzt sich die verschlüsselte Kommunikation per TLS auch auf Internetseiten (HTTPS) durch. Gut konfiguriert verhindert sie effektiv das Mitlesen der gesendeten Informationen und Einschleusen fremder Codestücke. Wichtig hierbei ist, dass der zugehörige Webserver richtig konfiguriert ist. Ich werde hier auf den aktuellsten Ableger des Apache HTTPd, die Version 2.4, eingehen. Alle Einstellungen werden im jeweiligen virtual Host vorgenommen und sollten teilweise bereits vorhanden sein. Bei Arch Linux befindet sich die SSL-Konfiguration unter /etc/httpd/conf/extra/httpd-ssl.conf.

Zertifikatstheorie

TLS, und damit auch HTTPS, arbeiten mit einem hierarchisch organisierten System. Viele Browser und Betriebssysteme liefern eine Liste mit vertrauenswürdigen Organisationen mit – ist das eigene Zertifikat nicht, zumindest indirekt, von einer dieser Organisationen unterschrieben, so wird eine Sicherheitswarnung angezeigt. Ob dies Sinnvoll ist kann kritisch beäugt werden, vor allem wenn man bedenkt, dass z.B. auch diverse Banken, Regierungen oder Organisationen, welche in der Vergangenheit eher durch Sicherheitsmängel aufgefallen sind, auf dieser Liste stehen. Generell erstell man selbst einen Key, den privaten Schlüssel des Zertifikates, und leitet hiervon einen Request (CSR) ab. Letzterer – und nur dieser – wird an die Zertifizierungsstelle (CA) zum Unterschreiben gegeben. Nachdem die eigene Identität nachgewiesen wurde wird aus Request und Unterschrift das eigentliche, öffentliche Zertifikat, welches das eigene, zweiteilige Schlüsselpaar komplettiert. Als Betreiber hat man hier mehrere Möglichkeiten ein solches SSL-Zertifikat zu erhalten:

  • Kaufen. Die diversen Organisationen bieten ihre Unterschriften üblicherweise gegen Gebühr an. Für eine eizelne Domain ohne Zusatzfunktionen sind etwa 15€/Jahr fällig, möchte man Subdomains oder erweiterte Sicherheitsfunktionen kann der Preis schnell auf über 1000€/Jahr steigen.
  • Selber machen. “Selbstsignierte” Zertifikate sind prinzipiell auch möglich, hier wird aber eine Sicherheitswarnung angezeigt. Der Nutzer muss selbst bestätigen, dass er dem Zertifikat vertraut. Für interne Systeme, auf denen man zentral ein Zertifikatsvertrauen ausrollen kann kein Problem, ansonsten eher nur für eigene Testsysteme geeignet.
  • StartSSL. StartCom stellt mit StartSSL kostenfrei SSL-Zertifikate zur Verfügung. Die Israelische Firma wird von allen gängigen Browsern als Vertrauenswürdig eingestuft. Bedenklich ist jedoch, dass das zurückziehen im Falle eines Sicherheitsproblem Gebühren verursacht und so dazu verleitet bei Problemen die Augen zuzukneifen.
  • CACert …ist eine freie, communitybasierte Zertifizierungsstelle. Auch hier lassen sich kostenfrei Zertifikate signieren, die Qualität der Signatur steigt mit der Anzahl der Personen, welche die Identität prüfen. Leider ist CACert auf vielen Systemen nicht hinterlegt, somit werden auch hier ohne manuellen Eingriff Sicherheitswarungen angezeigt.
  • Let’s Encrypt geht einen ähnlichen, allerdings weniger Community-Zentrierten weg. Sie möchte automatisiert und kostenfrei einfache SSL-Zertifikate bereitstellen. Dahinter stehen Internetgrößen wie Mozilla, Akamai, Cisco oder die EFF, es ist also davon auszugehen, dass die Vertrauensstellungen machbar sein sollen. Warum soll? Let’s Encrypt wird erst mitte Oktober 2015 starten.

Wir basteln einen Request

Welchen weg auch immer man geht: Wir brauchen einen Key und den passenden Request. Fangen wir mit ersterem an:

Der Schlüssel nutzt den RSA-Algorithmus mit einer Länge von 4096 Bit. Empfohlen wird >=2048 Bit, wer aber nicht unbedingt auf die letzten CPU-Takte Performance schaut sollte diese zugunsten der vermutlich längeren Zukunftssicherheit investieren.

Auf Basis dieses Schlüssels wird nun der Request erstellt:

Die Attribute wie Adresse sollten passend den eigenen Angaben ausgefüllt werden. Wichtigster Punkt: Der “Common Name” (CN) muss dem Servernamen entsprechen.

Diesen Request übersendet man nun der Zertifizierungsstelle, die Antwort wird als “server.crt” im selben Verzeichnis gespeichert. Sollte man ein so genanntes “intermediate” benötigen (Das eigene Zertifikat wurde von jemandem unterschrieben welcher selbst nicht vertrauenswürdig ist aber eine Unterschrift einer anderen, vertrauenswürdigen Stelle hat), so werden diese Zertifikate einfach am Ende der Textdatei drangehangen.

Apache-Konfiguration

Erster Schritt: Wir schalten “SSL” (so hies TLS früher mal, Apache hat die Namen beibehalten) ein und geben den Pfad zum Zertifikat an.

Als Nächstes werden die möglichen Protokollversionen und Algorithmen festgelegt. Bei ersterem sollte alles mit SSL abgeschaltet werden – diese haben bekannte Sicherheitslücken. Auch zu TLSv1 gibt es einige Bedenken, jedoch noch keinen praxisrelevanten Angriff – wer auf Nummer sicher gehen will kann auch dies Abschalten, jedoch sperrt man hiermit möglicherweise ältere Geräte und Browser aus. Bei den Ciphern ist die Reigenfolge entscheidend – der erste Eintrag, welcher von Server und Client unterstützt wird, wird verwendet. Einträge mit *DHE* bieten “perfect forward secrecy” (PFS) – hierbei wird für jede Verbindung ein temporäres Passwort abgewandelt. Liest ein Bösewicht die verschlüsselten Daten mit kann er sie später, auch wenn er den Server knackt und so an die Schlüssel kommt, nicht mehr entschlüsseln. RC4 und MD5 werden wegen ihrer hohen Geschwindigkeit zwar gerne von Großkonzernen und einigen Banken verwendet, haben aber bekannte Lücken, sodass sogar das Bundesamt für Sicherheit in der Informationstechnik (BSI) vor deren Einsatz warnt. Die SSL-Kompression hat ebenfalls eine gewisse Angriffsfläche und sollte abgeschaltet werden. Wie immer gilt: Je mehr man auf Sicherheit Wert legt, desto mehr alte Geräte sperrt man aus.

Bei neueren Servern kann man die Ladezeit des Besuchers noch etwas drücken: Dessen Browser geht üblicherweise hin und fragt nach der Verbindung bei der Zertifizierungsstelle, welche die Unterschrift geleistet hat, nach, ob diese überhaupt noch gültig ist. Mit OCSP-Stapeling fordert unser Server regelmäßig eine kleine, unterschriebene “Notiz” der Zertifizierungsstelle an, in welchem die Gültigkeit mit der aktuellen Uhrzeit hinterlegt ist. Diese senden wir gleich mit – ist dem Browser diese Info aktuell genug und die Unterschrift OK muss er nicht extra nochmal nachfragen.

Letzter Punkt: HSTS – HTTP Strict Transport Security. Hiermit sagen wir dem Browser, dass wir für die nächste Zeit ausschließlich per HTTPS arbeiten wollen. Alle zukünfigen Zugriffe werden automatisch per HTTPS abgewickelt, auch wenn der Nutzer nicht per Hand https anfordert. Im Gegensatz zu den gängigen HTTP-Umleitungen spart es einen unverschlüsselten Request, welcher ggf. auch als Angriffspunkt dienen kann. Wenn man seine Webseite absichtlich per HTTP und HTTPS anbieten möchte sollte man den Header natürlich überspringen.

Der Rest
Eine gute Ressource um zwischen Sicherheit und Kompatibilität abzuwähen oder die Konfiguration für andere Webserver und Funktionen anzupassen ist der Mozilla SSL Configuration Generator, auf dessen Ausgaben auch das hiesige Beispiel basiert.

Sollen alle Anfragen über HTTPS laufen kann man den HTTP-Listener anweisen für alle Anfragen mir einer Umleitung auf die HTTPS-Seite zu antworten. Hierzu reicht folgende Zeile im zuständigen VHost:

Wer testen möchte, ob alles Funktioniert hat und welche Geräte und Browser zu alt sind um auf die Webseite zugreifen zu können, kann die SSL-Tester von SSLLabs nutzen – dieser generiert einen ausführlichen und gut verständlichen Report und gibt weitere Tipps bei möglichen Problemen.

SSL-Zertifikate mit SHA256 erstellen

Mit OpenSSL kann man sich schnell einen Zertifikatsantrag zusammenstellen – hat man mit diesem ein Zertifikat beantragt kann man so z.B. Webseiten per HTTPS ausliefern. Leider musste ich feststellen, dass auf einigen Systemen noch SHA1 für die Authentifizierung verwendet wird. Dies ist schon etwas länger auf der Abschlussliste, da sich Zweifel an der Sicherheit mehren. Besser ist es für diesen Message Authentication Code (MAC) einen neueren Hashfunktion wie z.B. den Nachfolger SHA-2 zu verwenden. Der Befehl zum Erstellen eines neuen Keys mit Request lautet:

openssl req -sha256 -new -newkey rsa:4096 -nodes -keyout yourdomain.key -out yourdomain.csr

Will man sein bestehendes Zertifikat ummodeln kann man auch

openssl req -new -sha256 -key your-private.key -out your-domain.csr

Denizbank: Gehen sie weiter, hier gibt es nichts zu sehen

Wieder einmal ein Kandidat für den Award “unsichere Bank”, diesmal jedoch mit ganz besonderer Note. Beworben hat sich dieses mal die Denizbank. Eigentich sehen die (technischen) Werte ihrer deutschen Niederlassung sowie der österreichischen Kontoseite weitestgehend OK aus – fehlendes Forward Secrecy beim Kontilogin, ein paar Kleinigkeiten, aber keine offensichtlichen Mängel. PFS ist inzwischen ja nicht mehr so kompliziert, also kann man es ja mal anregen – eine passende Mail ging also vor einigen Wochen raus.

Zurück kam eine E-Mail, welche mehr Disclaimer als Inhalt besaß – ein Traum für alle Spieler von Bullshit Bingo. Die Angaben wären als Meinungsäußerung des Mitarbeiters und nicht als Aussagen der Bank zu verstehen. Interessant, hatte ich nicht um eine Stellungnahme gebeten? Kommt die Mail nicht von einem offiziellen Bank-Account und ist es üblich, dass Mitarbeiter diesen für private Meinungsäußerungen nutzen? Wie auch immer: Man ließ mich wissen, dass die Server

die aktuellste OPEN SSL Version verwenden und somit eine Sicherheitslücke ausgeschlossen ist.

Tja, wir alle wissen: OpenSSL ist so sicher wie die Rente. Auf meine Frage zu PFS & Co ging man gar nicht ein. No further questions…

CURL & OpenSSL – Zertifikatsfehler

In den letzten Tagen hatte ich einige seltsame Ergebnisse bei CURL – einige URLs wurden wegen eines fehlerhaften Zertifikatsunterschrift abgelehnt:

Cannot connect to URL : Peer certificate cannot be authenticated with known CA certificates: SSL certificate problem, verify that the CA cert is OK. Details:
[…]routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Seltsamerweise ist manuell sowohl Zertifikat als auch CA fehlerfrei, letztere ist auch in /etc/ssl/certs/ korrekt hinterlegt. Laut diversen Posts handelt es sich wohl um einen Fehler in OpenSSL – um vorerst Ruhe zu bekommen habe ich curl nun unter Gentoo mit CURL_SSL=”gnutls” oder CURL_SSL=”polarssl” installiert und bisher keine Probleme mehr. Für Ubuntu wäre libcurl4-gnutls-dev der richtige Startpunkt.