Let’s Encrypt mit Plesk nutzen

letsencrypt01

Seit dem 3. Dezember 2015 befindet sich das Projekt Let’s Encrypt in der öffentlichen Beta Phase. Das Projekt hat sich zum Ziel gesetzt, möglichst viele Webseiten auf SSL umzustellen. Dafür werden kostenlos kurzlebige Server-Zertifikate automatisch bereitgestellt. Hinter der Kampagne steht die Internet Security Research Group (ISRG), die von großen non-profit und kommerziellen Organisationen finanziell unterstützt wird. Zu den bekanntesten Sponsoren gehören die Mozilla Foundation, Cisco, Akamai, Electronic Frontier Foundation, Google, Facebook und viele andere bekannte Namen.

Der große Vorteil von Let’s Encrypt Zertifikaten im Vergleich zu herkömmlichen durch eine CA ausgestellte Zertifikate ist die Einfachheit. Es muss kein Zertifikat beantragt und auf den Server übertragen werden. Dies geschieht vollautomatisch. Daher ist es auch möglich die Gültigkeit der Zertifikate recht kurz zu halten. Ein klassisches Zertifikat gilt in der Regel ein Jahr und muss dann manuell ersetzt werden. Zudem ist Let’s Encrypt kostenlos und daher auch für Betreiber einer kleinen privaten Webseite erschwinglich. „Let’s Encrypt mit Plesk nutzen“ weiterlesen

Veeam Backup Problem nach Update auf ESXi 6.0 U1

Nach dem Update auf ESXi 6.0 Update 1 kommt es zu Problemen bei Veeam Backup Jobs.

SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

In der Veeam Konsole erscheint die Meldung

Failed to create NFC download stream

Ursache ist die Abschaltung von SSLv3 in ESXi 6.0 U1. Der VMware KB Artikel 2121021 erklärt, wie man SSLv3 wieder aktivieren kann. Nach der Reaktivierung funktionieren die Veeam Backup Jobs wieder.

Nicht nur Veeam

Betroffen sind eine Reihe Anwendungen – auch vmware eigene. Offensichtlich kann die VMware NFC API nicht mit TLS umgehen. Ein Fallback auf SSLv3 ist seit dem Update jedoch nicht mehr möglich.

Auch wenn SSLv3 als veraltet und unsicher gilt, so kann man das Risiko in kontrollierter LAN Umgebung abwägen und dieses vorübergehend wieder aktivieren, bis VMware und/oder Veeam einen Patch bereitstellt.

 

SSL Fehler – schwacher Diffie Hellman Public Key

Zur Administration virtueller Appliances und Hardware im LAN verwende ich gerne Chrome als Browser. Das funktionierte bis vor kurzem einwandfrei. So war ich auch nicht schlecht überrascht, als mir beim gewohnten Aufruf einer WebGUI diese Meldung auf dem Schirm erschien:

WeakDHKey01
Wie bitte!? Ich hatte an der Appliance nichts verändert. Also probierte ich es mit Firefox. Aber auch damit gab es die rote Karte. Keine Möglichkeit die Warnung zu Bestätigen und “auf volles Risiko” fortzufahren (danke für den Hinweis, aber alles ist gut).

WeakDHKey02
Hintergrund dieses Phänomens ist die Tatsache, dass sowohl Google, als auch Mozilla ihren aktuellen Browsern den Kontakt mit https zu Webseiten mit schwachen SSL Schlüsseln komplett untersagt haben. Das ist nett gemeint und zu meinem Schutz im bösen Internet, aber es sperrt mich auf einen Schlag von der Administration zahlreicher Geräte und Appliances aus. Zumindest eine Experten-Option für nicht DAUs wäre nett gewesen.
Zumindest Firefox bietet hier etwas Spielraum über die Konfiguration. Bei Chrome gibt es nur Dirty Tricks, die aber im Alltag nicht praktikabel sind.

Firefox

Die erweiterten Einstellungen von Firefox erreicht man durch Eingabe von “about:config” (ohne Anführungszeichen) in der Adresszeile. Dort gibt es erweiterte Einstellungen. Wählt man diese erstmalig aus, erscheint eine Warnung zum Verlust der Gewährleistung (welche Gewährleistung?). Es müssen die beiden unten dargestellten Optionen auf “false” gesetzt werden. Dann erlaubt Firefox wieder den Kontakt mit der Webseite, trotz schwachem Private Key.

 

WeakDHKey03

Chrome

Den Workaround für Chrome poste ich nur der Vollständigkeit wegen. Er ist in meinen Augen nicht praxistauglich. Dazu muss Chrome über CLI oder eine angepasste Verknüpfung gestartet werden.

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Eine Lanze für den IE

Mit dem IE ins Web gehen ist ja etwas für Chuck Norris und Danger-seeker, aber gelegentlich ist reduzierte Sicherheit auch von Vorteil. 😉

Zumindest machte IE 10 keine Schwierigkeiten beim Kontakt mit der schwach gesicherten Webseite.

Links

  • Test der Browser Einstellungen – DCSec

FTS Custom ESXi Image ohne Heartbleed Bug

Fujitsu (FTS) hat ein aktualisiertes Custom ESXi Image (5.5.0 U1) bereitgestellt, welches den SSL Heartbleed Bug nicht mehr enthält. Die Datei mit der Bezeichnung “FTS_FujitsuCustomImageESXi55Update1_31111746018_1108239.zip” ist seit dem 22.4.2014 im FTS Support-Portal erhältlich.

ESXi 5.5 update 1 build 1623387 is vulnerable to the actual openSSL heartbleed
security bug. To solve this issue VMware provides the Patch ESXi550-201404001
which is base of this ISO-Image.
If an upgrade on ESXi5.5 is done with this image, you also need to replace
certificates and change passwords.
See VMware KB-Article http://kb.vmware.com/kb/2076665

Links