Schlagwort-Archive: X.509

HTTPS mit signierten Zertifikaten auf HP/HPE/Procurve/Aruba/Procurve-Switchen

HTTPS, vorzugsweise mit gültigen Zertifikaten, sollte heute eigentlich Standard sein – erst recht wenn man mehr oder weniger kritische Infrastrukturen darüber verwalten möchte. Auch wenn ich eher ein Verfechter von SSH bei der Konfiguration von Switchen bin, so wird doch oft auch ein Webinterface gefordert. Bei HP/HPE/Aruba/Procurve ist dies in der Standardkonfiguration unverschlüsselt per HTTP erreichbar. HTTPS lässt sich aktivieren, die Einrichtung von etwas anderem als self-signed ist jedoch leider nicht so intuitiv wie ich das gerne hätte. Also gehen wir die Schritte mal durch. Im CLI natürlich.

Erst muss ein “Trust Anchor” erstellt werden. Dies ist sozusagen die Zertifikatsdatenbank des Switches. Da mehrere vorhanden sein können wird er mit einem aussagekräftigem Namen (her “MEINNETZ“) versehen.

Anschließend wird das Zertifikat der Zertifizierungsstelle (CA) importiert. Leider ist dies bei vielen  Geräten nur per TFTP und nicht über USB-Stick, Terminal  o.Ä. möglich. Auch dieses bekommt zur besseren Auffindbarkeit einen Namen (hier “MYCA“). Die angegebene IP entspricht der des TFTP-Servers, unter Windows lässt sich hierzu z.B. TFTPD32 nutzen. Der Switch selbst muss hierfür natürlich bereits eine passende Netzwerkkonfiguration besitzen und den PC erreichen können, ohne passende Konfiguration sucht er sich eine Adresse per DHCP auf dem Standard-VLAN.

Im Anschluss kann die Zertifikatsunterschriftanfrage (CSR) generiert werden. Wichtig für ein gültiges Zertifikat ist hierbei im Feld “common-name” den späteren Hostname oder die IP-Adresse des Switches anzugeben, welche letztendlich für das Management verwendet werden soll..

Zu beachten ist, dass je nach Modellgeneration die Verfügbaren Cryptomethoden limitiert sein können. Das hier genutzte Modell unterstützt so leiglich RSA-Schlüssel mit bis zu 2048 Bit. Die verfügbaren Optionen lassen sich wie immer durch “?” abrufen. Das Erstellen kann je nach verbautem Managementprozessor einige Zeit in Anspruch nehmen, im Anschluss erscheint die Anfrage als Text.

Diese Anfrage kopiert man aus dem Terminal und reicht sie als .csr-Datei an die gewünschte Zertifizierungsstelle weiter bzw. signiert diesen selbst mit seiner lokalen CA. Als Ergebnis erhält man ein Zertifikat, üblicherweise im PEM-Format (meist .pem oder .crt), welches im Switch importiert werden muss. Erhält man stattdessen eine DER oder P7B-Datei kann diese an einem PC z.B. mit openssl konvertiert werden. Nach Eingabe des Importbefehls erwartet der Switch den Inhalt der PEM-Datei als Texteingabe. Unter Windows mit PuTTy kann mit einem Rechtsklick eingefügt werden.

Mit Erkennen der “END CERTIFICATE“-Zeile kehrt der Switch automatisch zur Konfigurationsoberfläche zurück.  Das Zertifikat sollte nun in der Liste der installierten Zertifikate zu sehen sein.

Zuletzt wird HTTPS ein- und HTTP ausgeschaltet. Das zuvor installierte und somit einzige Zertifikat sollte automatisch verwendet werden.

Somit ist der Switch nicht mehr unverschlüsselt verwaltbar und die zuständigen “Administratoren” teilen ihr Passwort nicht mehr zwangsläufig allen Lauschern im Netz servierfertig mit. Mit etwas Glück spart das Ganze am Ende mehr Arbeit als das turnusmäßige Auffrischen der Zertifikate verursacht. Wenn nicht schont der nicht mehr vorhandene HTTP-Login  immerhin meine Nerven.

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. – Ein kurzer Überblick (Part 1)

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. - Ein kurzer Überblick (Part 1)

(26 MB) 00:07:18

2015-09-20 10:00 🛈

Part 1: Warum verschlüsseln, Symmetrisch vs. Asymmetrisch
Part 2: RSA, PFS, DHE, ECDHE und sonstige Innereien

HTTPS dürften die meisten kennen, TLS (früher SSL genannt) vielleicht auch, wie sieht es mit RSA, DHE oder ECDHE aus? Alle Begriffe sind Techniken um Zugriffe auf Webseiten zu gegen unberechtigtes Mitlesen abzusichern.

Warnung wie immer: Alles nur als Überblick – die Erklärungen sind stark vereinfacht, teilweise unvollständig und können Fehler enthalten.

Warum überhaupt?

Ich hab doch nichts zu verbergen!

So heißt es vielfach, wenn man über Verschlüsselung diskutiert. Aber ist das wirklich so? Selbst wenn man selbst sein ganzes Leben zugänglich macht, so gibt es dennoch Gründe nicht alle Daten unverschlüsselt zu übermitteln. Klassisches Beispiel: Zugangsdaten. Werden diese ungeschützt übertragen können sie von Dritten abgefangen werden. Unerwünschte Posts können schnell mit Stress im Freundeskreis oder gar vor Gericht enden. Und das Konto wäre vermutlich ebenso schnell leer. Hätte man die Daten besser mal verborgen.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/3-mettbook-userpass-300×227.png

Symmetrische Kryptografie

Fangen wir mit dem einfachsten an: Symmetrische Kryptografie. Hierunter versteht man Verfahren, bei denen z.T. ein Text mit einem Passwort verschlüsselt wird. Das Ergebnis ist für Außenstehende nicht zu entziffern und somit wertlos. Wer jedoch den Schlüssel kennt kann aus dem Kauderwelsch wieder den ursprünglichen Text reproduzieren.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/sym7-300×169.png

Solche Verfahren sind natürlich schön für Dokumente, jedoch Problematisch für Webseiten: Entweder müssten alle Besucher das selbe Kennwort kennen – könnten also auch die Daten der anderen entschlüsseln – oder man müsste für jeden Besucher ein eigenes Passwort aushandeln. Nur wie, wenn der Besucher zum ersten mal die Seite aufruft? Etwas anderes muss her.

Asymmetrische Kryptografie

Klassischerweise wird zum Schlüsseltausch im Internet ein asymmetrisches Verfahren verwendet. Hierbei hat der Betreiber der Webseite einen “Schlüssel” erstellt, welcher aus zwei Teilen besteht: Einem privaten Teil, welcher geheim gehalten wird, und einem öffentlichen Teil, welcher allen Besuchern weitergegeben wird. Dahinter steckt eine Einwegfunktion – sozusagen eine mathematische Einbahnstraße. Mit dem öffentlichen Teil lässt sich ein Text einfach verschlüsseln, jedoch das Ergebnis nach aktuellem Stand nicht mehr Zurückrechnen. Hat man jedoch den privaten Teil, so hat man auch die fehlenden Informationen um aus dem zuvor berechneten Wirrwarr wieder den ursprünglichen Text zu erhalten. Der Client kann also dem Server verschlüsselte Nachrichten zukommen lassen, ohne die Gefahr des Mitlesens.

Ebenfalls möglich ist eine andere Richtung: Mit dem privaten Schlüssel kann der Server eine Nachricht unterschreiben, also bestätigen, dass diese von ihm so gewollt ist. Der Client kann mit dem öffentlichen Teil am Ende prüfen, ob die Unterschrift tatsächlich vom Absender stammt und der Text unterwegs nicht verändert wurde.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/asym12-300×169.png

Zertifikatswahn

Wem ist etwas aufgefallen? Wir benötigen öffentliche Schlüssel für alle verschlüsselten Webseiten. Doch wo kommen sie her? Nun – das ist schnell gelöst: Der Server schickt uns diese beim Verbinden. Klingt praktisch, hat aber einen Nachteil: Wir können nicht sicher sein, dass das Ziel tatsächlich unser Server und nicht ein Angreifer zwischendrin ist. Der Lösungsansatz lautet X.509, oder kurz: Zertifikate. Diese Zertifikate enthalten nicht nur den Schlüssel, sondern auch weitere Informationen wie den Servernamen, die zugehörige Organisation, ein Haltbarkeitsdatum und einen Fingerabdruck. Zusätzlich sind diese Zertifikate zum Nachweis der Identität des Betreibers von einer weiteren Firma, der so genannten Certificate Authority (CA) unterschrieben. Alle aktuellen Browser und Betriebssysteme haben eine Liste mit Firmen, welche solche Unterschriften leisten dürfen, im Lieferumfang. Ist das Zertifikat von einer dieser Firmen unterschrieben, so vertraut der Browser diesem ohne weitere Nachfrage. Ist die Unterschrift unbekannt erhält man eine passende Warnung. In diesem Fall kann man natürlich trotzdem z.B. den erhaltenen Fingerabdruck telefonisch mit dem Betreiber abgleichen und so die Identität selbst feststellen.

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