TLS-Sicherheitsproblem „Logjam“

Vor einigen Tagen wurde unter dem Namen Logjam ein mögliches Sicherheitsproblem mit der TLS-Verschlüsselung bekannt, die zur Verschlüsselung von Webseiten (HTTPS) und E-Mails (POP3, IMAP, SMTP) genutzt wird. Ein Angreifer kann unter bestimmten Umständen den DiffieHellman-Schlüsselaustausch zwischen Client und Server so manipulieren, dass nur schwache 512 Bit Parameter genutzt werden, die nach aktuellem Stand nicht mehr als sicher gelten. Dieser Angriff ist auf unseren Servern jedoch nicht möglich, da wir keine so kurzen Diffie-Hellman-Paramter unterstützen.

Wir haben uns im Rahmen des Logjam-Sicherheitsproblems dazu entschieden, wenn möglich nur noch als extrem sichere geltende 4096 Bit Diffie-Hellman-Parameter zu nutzen. Die meisten unserer Server nutzten bereits vor Bekanntwerden dieses Sicherheitsproblems 4096 Bit Parameter, auf einigen Servern wurden jedoch noch kürzere 1024 Bit Parameter genutzt, die von machen Sicherheitsexperten als bereits problematisch kurz eingestuft werden. Seit dem 22.05. nutzen alle Server (bis auf eine Ausnahme) 4096 Bit Parameter, dadurch kann es jetzt jedoch bei einigen veralteten Programmen zu Verbindungsproblemen kommen.

Einzige Ausnahme bilden die Mail-Server, wir mussten bei POP3 und IMAP aufgrund von Problemen mit älteren Mail-Clients wieder auf 1024 Bit Diffie-Hellman-Parameter zurückwechseln. Aktuelle Mail-Clients nutzten jedoch im Regelfall ohnehin das modernere Elliptic-Curve-Diffie-Hellman, das mit kürzeren Parametern und weniger Rechenleistung auskommt.

Die technischen Hintergründe

Die TLS-Verschlüsselung nutzt eine Kombination aus asymmetrischer Verschlüsselung zum Schlüsselaustausch und symmetrischer Verschlüsselung zur eigentlichen Verschlüsselung der Daten. Mittels asymmetrischer Verschlüsselung wird ein zufälliger geheimer Schlüssel vom Client an den Server übertragen, der nur vom Server wieder entschlüsselt werden kann. Da die asymmetrische Verschlüsselung sehr aufwändige kryptographische Algorithmen nutzt, kann sie aus Performance-Gründen nicht zur eigentlichen Verschlüsselung der Daten eingesetzt werden, hierfür werden wesentliche effizientere symmetrische Verschlüsselungsalgorithmen genutzt.

Der TLS-Standard sieht mehrere Verfahren zum Schlüsselaustausch und zur Verschlüsselung vor, einige davon sind jedoch mittlerweile veraltet und gelten als unsicher. Unsere Server sind daher so konfiguriert, dass nur nach aktuellem Stand sichere Verfahren genutzt werden können.

Die gegenwärtig sichersten Verfahren zum Schlüsselaustausch sind Diffie-Hellman (DHE) sowie Elliptic-Curve-DiffieHellman (ECDHE). Bei beiden Verfahren wird zwischen Client und Server für jede Verbindung ein individueller Schlüssel generiert (Perfect Forward Secrecy). Weiterhin wird für ältere Clients noch das RSA-Verfahren unterstützt, bei dem der Schlüsselaustausch mit dem RSA-Schlüssel aus dem X.509-Zertifikat des Servers gesichert wird. Dieses Verfahren hat jedoch den Nachteil, dass ein Angreifer mit Kenntnis des geheimen Server-Schlüssels alle Verbindungen entschlüsseln kann. ECDHE und DHE werden daher bevorzugt, RSA wird nur genutzt, wenn ein Client kein Diffie-Hellman unterstützt.

Bei DHE und ECDHE sendet der Server bestimmte Parameter an den Client, die in einem komplexen Algorithmus zur Berechnung der Verschlüsselung genutzt werden. Die Länge dieser Parameter entscheidet über die Sicherheit der Verschlüsselung. Bei DHE ist die minimal zulässige Länge 512 Bit, dies gilt jedoch seit längerer Zeit als nicht mehr als ausreichend sicher. Auch 1024 Bit Parameter gelten mittlerweile als problematisch, es werden mindestens 2048 Bit empfohlen.

Schwere Sicherheitslücke im Web-Shop Magento

Am 9. Februar 2015 wurde relativ stillschweigend ein Patch für die bekannte Web-Shop-Software Magento veröffentlicht, der mehrere schwere Sicherheitslücken in fast allen aktuellen und auch älteren Magento-Versionen schließt. Betroffen ist sowohl die Community Edition als auch die Enterprise Edition. Über diese Sicherheitslücken lassen sich SQL-Befehle sowie PHP-Code einschleusen, dadurch könnten Angreifer beispielsweise zusätzliche Adminstrator-Benutzer erstellen, auf Kreditkartennummern von Kunden zugreifen oder Spam-Scripte installieren.

Die Details zu der Sicherheitslücke wurden mehrere Monate geheimgehalten, um Magento-Benutzern genügend Zeit zum Einspielen des Patches zu geben. Am 23. April wurden nun sämtliche Details zur dieser Sicherheitslücke veröffentlicht; bereits wenige Stunden nach Veröffentlichung finden sich Hinweise auf die ersten Angriffe in unseren Webserver-Logs. Wir haben die Angreifer mittlerweile so gut es geht per Webserver-Firewall ausgesperrt, einige ungepatchte Magento-Installationen sind jedoch bereits gehackt wurden. Offenbar haben die Angreifer zusätzliche Administrator-Benutzer angelegt, die unbedingt wieder gelöscht werden müssen. Wir werden betroffene Kunden in Kürze informieren. Wenn eine Installation bereits manipuliert wurde, sollten sicherheitshalber alle Passwörter (Administrator-Accounts, MySQL, FTP) geändert werden.

Bitte beachten Sie, dass durch unsere Webserver-Firewall Tests auf diese Sicherheitslücke (z.B. shoplift.byte.nl) falsche Ergebnisse liefern.

Falls Sie bei uns einen Magento-Shop betreiben, sollten Sie unbedingt den von Magento bereitgestellten Patch SUPEE-5344 installieren. Die Installation ist leider etwas kompliziert, da die Patches als Shell-Script für die jeweilige Magento-Version bereitgestellt werden, dass Sie per (S)FTP in das Wurzelverzeichnis Ihrer Magento-Installation kopieren und dort per SSH oder über ein PHP-Script ausführen müssen:

  • Patch per SSH einspielen
    Kopieren Sie die Patch-Datei per (S)FTP in das Magento-Installationsverzeichnis. Loggen Sie sich dann per SSH auf Ihrem Webserver ein. Falls Sie Magento in einem Unterverzeichnis installiert haben (z.B. magento), wechseln Sie zuerst in dieses Verzeichnis:
    cd magento
    Anschließend führen Sie folgenden Befehl aus:
    bash PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh
    Ersetzen Sie dabei PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh durch den Namen der Patch-Datei für Ihre Magento-Version.
  • Patch per PHP-Script einspielen
    Erzeugen Sie eine Text-Datei patch.php mit folgendem Inhalt:
    <?php
    passthru("/bin/bash PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh");
    ?>

    Ersetzen Sie dabei PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh durch den Namen der Patch-Datei für Ihre Magento-Version. Kopieren Sie die PHP-Datei und die Patch-Datei per (S)FTP in das Magento-Installationsverzeichnis auf den Webserver. Anschließend rufen Sie die PHP-Datei über Ihren Web-Browser unter der URL Ihres Webshops auf (z.B. „www.meinshop.de/patch.php“). Die beiden hochgeladenen Dateien sollten danach wieder gelöscht werden.

Falls der Patch erfolgreich war erscheint folgende Ausgabe:

Checking if patch can be applied/reverted successfully…
Patch was applied/reverted successfully.

Anschließend sollten Sie den Cache in Magento zurücksetzen (System -> Cache Management). Bitte prüfen Sie auch, ob der im August 2014 bereitgestellten Patch SUPEE-1533 installiert wurde, der eine ähnliche Sicherheitslücke schließt.

Bitte beachten Sie, dass auch die gegenwärtig aktuellste Magento-Version 1.9.1.0 von dieser Sicherheitslücke betroffen ist und gepatcht werden muss.

Probleme mit PayPal nach SSL-Abschaltung

Der Zahlungsanbieter PayPal hat zum 12.01.2015 die Unterstützung der mittlerweile veralteten SSL-Verschlüsselung eingestellt, dadurch funktionieren die Zahlungsmodule vieler bekannter Webshops wie Oxid, Gambio, xt:commerce oder Prestashop unter Umständen nicht mehr. Ältere Versionen der PayPal-Module dieser Webshops setzen die Verschlüsselung der Verbindung zu den PayPal-Servern fest auf SSL Version 3, daher wird die sonst standardmäßig benutzte, sichere TLS-Verschlüsselung nicht eingesetzt.

Die meisten Webshop-Anbieter haben mittlerweile Updates herausgebracht, die dieses Problem beheben. Falls Sie auf unseren Webservern einen Webshop mit PayPal-Anbindung installiert haben, sollten Sie daher dringend prüfen, ob es Updates für die von Ihnen eingesetzte Shop-Software gibt.

Sie können prüfen, ob Ihr Webshop betroffen ist, in dem Sie nach „CURLOPT_SSLVERSION“ im PHP-Quellcode des PayPal-Moduls suchen. Loggen Sie sich dazu einfach per SSH auf Ihrem Webserver ein und geben folgenden Befehl ein:
ag CURLOPT_SSLVERSION

Dann werden Ihnen alle Dateien angezeigt in denen diese Zeichenkette vorkommt. Achten Sie dabei auf Dateien, deren Name „paypal“ enthält. Sie sind von diesem Problem betroffen, wenn Sie in diesen Dateien Zeilen ähnlich den folgenden finden:
curl_setopt ($ch, CURLOPT_SSLVERSION, 3);
curl_setopt ($ch, CURLOPT_SSLVERSION, CURL_SSLVERSION_SSLv3);

Falls es keine Updates für Ihren Webshop gibt, können Sie diese Zeilen einfach im Quellcode auskommentieren (am Anfang der Zeile // hinzufügen), dann wird automatisch TLS-Verschlüsselung genutzt.

Ausführlichere Informationen und Hintergründe finden Sie bei t3n.

Probleme beim E-Mail-Versand mit Speedport-Routern der Deutschen Telekom

Bei den aktuellen Speedport-Routern (Modell „W 724V“) der Deutschen Telekom kommt es zu Problemen mit dem Mailversand über den Variomedia SMTP-Server, da die Telekom dort standardmäßig alle SMTP-Server bis auf die eigenen und die weniger anderer großer Anbieter gesperrt hat. Betroffen sind insbesondere Telekom-Kunden, die im Rahmen der Umstellung auf den IP-basierten Anschluss einen neuen Router erhalten haben.

Um wieder E-Mails über unseren SMTP-Server versenden zu können, müssen Sie diese Sperre entweder entweder ganz deaktiveren, oder den Variomedia SMTP-Server manuell freischalten. Loggen Sie sich dazu im Web-Interface des Routers (URL: „speedport.ip“) ein und wählen Sie oben das Menü „Internet“. Dann finden Sie links ein Menü „Liste der sicheren E-Mail-Server“, dort wählen Sie entweder die Option „Liste der sicheren E-Mail-Server verwenden“ ab, oder Sie fügen den Variomedia SMTP-Server „smtp.variomedia.de“ (bzw. „smtp.securehost.de“) zur Liste hinzu.

Nachtrag
Mit der Aktualisierung vom 10.03. hat die Telekom unsere SMTP-Server zu dieser Liste hinzugefügt, damit sollte das Problem behoben sein.

Apache-Modul „mod_speling“ verfügbar

Auf unseren Linux-basierten Webservern wird (im Gegensatz zu normalen Windows-PCs) zwischen Groß- und Kleinschreibung bei Datei- und Verzeichnisnamen unterschieden, wenn Sie z.B. in Ihrem Webspace-Verzeichnis eine Datei „index.php“ ablegen, und diese im Web-Browser als „INDEX.PHP“ aufrufen, so wird der Aufruf fehlschlagen. Beim Domainnamen hingegen wird nicht zwischen Groß- und Kleinschreibung unterschieden, so macht es z.B. keinen Unterschied, ob Sie „variomedia.de“ oder „VARIOMEDIA.DE“ in Ihrem Browser aufrufen.
Manchmal ist es auch wünschenswert, dass kleine Tippfehler bei URLs automatisch korrigiert werden. z.B. wenn im Browser statt „.html“ als Dateiendung „.htm“ eingegeben wird.

Mit dem Apache-Modul mod_speling können diese Fehler in URLs automatisch korrigiert werden, der Webserver leitet dann auf die korrekte URL weiter. Falls es zu einer ungültigen URL mehrere möglicherweise passende Dateien auf dem Server gibt, wird eine Auswahl dieser Dateien angezeigt.

Das Modul wurde gestern auf allen Webservern installiert, ist jedoch aus Sicherheits- und Performancegründen standardmäßig deaktiviert. Um es zu aktivieren, muss eine .htaccess-Datei mit der Option „CheckSpelling on“ im gewünschten Webspace-Verzeichnis erstellt werden. Sie können dabei wählen, ob ausschließlich Groß-/Kleinschreibung oder zusätzlich auch (maximal 1) Tippfehler automatisch korrigiert werden sollen:

Tippfehler und Groß-/Kleinschreibung korrigieren
<IfModule mod_speling.c>
  CheckSpelling on
</IfModule>

Nur Groß-/Kleinschreibung korrigieren
<IfModule mod_speling.c>
  CheckSpelling on
  CheckCaseOnly on
</IfModule>

Wie bei .htaccess-Dateien üblich gilt diese Einstellung dann auch für alle Unterverzeichnisse.

Es gibt etwas zu feiern: 10 Jahre Variomedia

Die Variomedia AG wird 10 Jahre alt und wir möchten diesen Geburtstag mit unseren Kunden feiern. Dazu planen wir von August bis Dezember für jeden Monat eine Aktion, die unsere Kunden begeistern wird!

Zwischen dem 1. August und dem 31. August gewähren wir für alle Domainübernahmen die Rabattstufe „ab 100 Domains“ – dauerhaft und nicht nur im ersten Jahr. Nutzen Sie die Gelegenheit und übernehmen Sie Domains, die Sie noch bei anderen Providern haben in diesem Monat zu uns und sparen Sie bis zu 40 Prozent vom Normalpreis (z.B. .de-Domain für 5,40 Euro statt 9,00 Euro pro Jahr). Es ist dabei egal, ob es nur um eine oder mehrere Domains geht – die Rabattstufe „ab 100 Domains“ gilt in diesem Monat für alle Domainübernahmen aller Kunden!

Am 14. August 2000 wurde Variomedia – damals noch als Variomedia IT-Service GmbH – im Handelsregister eingetragen und wir feiern diesen Tag als unseren Firmengeburtstag. Ein weiteres besonderes Angebot wird es daher am darauffolgenden Montag, den 16. August 2010 geben. Dieses werden wir vormittags über unseren Twitter-Feed bekannt geben. Seien Sie gespannt!

Wir möchten uns bei allen Kunden bedanken, die uns schon viele Jahre treu sind und freuen uns über alle Kunden, die uns erst kürzlich ihr Vertrauen geschenkt haben. Wir hoffen, auch in den nächsten 10 Jahren die Leistung zu erbringen, die Sie sich von Ihrem Webhoster und Domainregistrar wünschen und freuen uns dabei wie immer auf Ihr Feedback, Ihre Anregungen und Ihre Kritik, falls mal etwas nicht so rund läuft.

Variomedia im „Social Web“

Soziale Netzwerke haben in den letzten Jahren immer mehr an Bedeutung gewonnen. Seit Ende 2008 informieren wir unsere Kunden oft täglich aktuell über Neuigkeiten, Wartungsarbeiten und eventuelle Störungen via Twitter (http://twitter.com/variomedia). Seit einigen Monaten gibt es auch ein Variomedia-Facebook-Profil (http://facebook.com/variomedia), über das wir immer wieder über Aktionen berichten, Fotos und Videos aus unserem Geschäftsalltag veröffentlichen und mit Kunden über Trends im Internet plaudern.

Neu ist unser Blog (https://blog.variomedia.de), das den bisherigen Bereich „Aktuelles“ ersetzt. Hier werden wir wie bisher aktuelle Informationen verbreiten, die sich z.B. auch als RSS-Feed abonnieren lassen. Hinzu kommen immer wieder kleine oder große Geschichten aus unserem Geschäftsalltag, mit denen wir unseren Kunden einen Einblick hinter unsere Kulissen geben wollen.

Wir laden Sie ein, die Möglichkeiten des „Social Web“ zu nutzen. Vernetzen Sie sich mit uns und profitieren Sie von aktuellen Informationen zu unseren Diensten. Nutzen Sie die vielen Möglichkeiten, mit uns Kontakt aufzunehmen. Wir freuen uns auf Ihre Fragen und Kommentare und antworten Ihnen gern.

Neue TLD: .co-Domains für 35,40 Euro pro Jahr

Die Registrierung von .co-Domains (Kolumbien) ist ab sofort für alle Interessenten möglich.

Durch den geringen Preis von 35,40 Euro pro Jahr eigenet sich diese Domainendung hervorragend als Alternative zu .com-Domains, die häufig schon vergeben sind.

Die Bestellung ist über unsere Webseite oder das Kundenmenü möglich. Es sind keine besonderen Voraussetzungen erforderlich.

Eine Übernahme von .co-Domains ist mit einem Authcode möglich. Den Authcode erhalten Sie beim derzeitigen Provider.

Änderung der Rabattstufen für .com-Domains zum 1.7.2010

Zum zweiten Mal innerhalb eines Jahres erhöht die Verisign den Preis für .com-Domains. Bei der letzten Preiserhöhung im Herbst 2009 konnten wir auf eine Weitergabe der Steigerung um immerhin 6% verzichten, da sich der Euro-Kurs für uns positiv entwickelt hat und die Preiserhöhung dadurch kompensiert werden konnte.

Inzwischen ist der Euro so schwach wie seit einem Jahr nicht mehr und wir kommen nicht darum herum, die erneute Preiserhöhung an unsere Kunden weiterzugeben. Wir beschränken uns dabei allerdings auf die Rabattstufen, die bisher wie folgt galten:

Grundpreis: 0,95 Euro pro Monat
ab 20 Domains: 0,85 Euro pro Monat
ab 50 Domains: 0,75 Euro pro Monat
ab 100 Domains: 0,65 Euro pro Monat

Die neuen Preise ab dem 1.7. lauten:

Grundpreis: 0,95 Euro pro Monat (unverändert)
ab 20 Domains: 0,90 Euro pro Monat (+0,05 Euro)
ab 50 Domains: 0,80 Euro pro Monat (+0,05 Euro)
ab 100 Domains: 0,70 Euro pro Monat (+0,05 Euro)

Der Grundpreis von 0,95 Euro pro Monat bzw. 11,40 Euro pro Jahr bleibt also unverändert, damit sind ca. 65% unserer Kunden nicht von der Preiserhöhung betroffen.

Der neue Preis gilt für alle Neuregistrierungen, Übernahmen und Verlängerungen ab dem 1.7.2010 in den Rabattstufen „ab 20“, „ab 50“ und „ab 100“.

Wir hoffen auf Ihr Verständnis für diese Preisänderung und stehen Ihnen für Fragen gerne zur Verfügung!

Änderung der Registrierungsrichtlinien für .ru-Domains

Vor einigen Tagen hat die Registrierungsstelle für .ru-Domains allen Inhabern mitgeteilt, dass diese bis zum 01.04.2010 einen Identitätsnachweis einreichen sollen. Dies gilt sowohl für Firmen wie auch für Privatpersonen. Ohne diesen Identitätsnachweis wird die Registrierungsstelle die entsprechenden .ru Domains deaktivieren.

  • Bei Privatpersonen benötigen wir eine Kopie der Vorder- und Rückseite des Personalausweises, möglichst zusammengefasst auf einer DIN A4 Seite.
  • Bei Einzelunternehmern wird ebenfalls der Personalausweis benötigt.
  • Bei Firmen benötigen wir den Handelsregisterauszug bzw. die Gewerbeanmeldung, auf der der Firmenname deutlich sichtbar ist.

Wir haben alle Kunden und Reseller über diese neuen Richtlinien informiert und entsprechende Dokumente angefordert.

Häufig gestellte Fragen zu diesem Thema:

  • Ist dieser Nachweis wirklich nötig?
    Ja, ohne Ausnahme. Die Vergabestelle erzwingt dies von allen Domaininhabern und es ist verpflichtend für alle Provider.
  • Was passiert, wenn die Dokumente nicht oder nicht rechtzeitig eingereicht werden?
    Kurzfristig will die Vergabestelle entsprechende Domains nur deaktivieren, d.h. die Webseite und E-Mail Adressen sind nicht mehr erreichbar. Langfristig wird die Vergabestelle entsprechende Domains auch löschen, d.h. Sie sind nicht länger Inhaber dieser Domains.
  • Was passiert anschließend mit den Dokumenten?
    Laut der Vergabestelle werden sie dort nur intern gespeichert und außer für die Validierung nicht weiter verwendet. Wie hoch die Standards bei der russischen Vergabestelle in punkto Datenschutz sind lässt sich schwer einschätzen.
  • Der Inhaber ist nicht mehr aktuell, ich möchte ihn aktualisieren.
    Versuchen Sie irgendwie trotzdem einen Nachweis für den bisherigen Inhaber zu liefern, z.B. mit einem alten Handelsregisterauszug, auch wenn die Firma sich vielleicht schon umbenannt hat. Inhaberwechsel sind bei .ru Domains eine extrem zeit- und arbeitsaufwändige Sache, denn es müssen Dokumente im Original mit notarieller Beglaubigung nach Moskau zur Vergabestelle geschickt werden und hin und wieder kommen die Dokumente nicht an oder werden nicht akzeptiert. Kurzfristige Inhaberwechsel werden nicht erfolgreich sein. Riskisieren Sie daher bitte nichts, sondern senden Sie notfalls auch veraltete Unterlagen zu.

Update vom 09.04.2010: Bisher hat die Registrierungsstelle nur einen Bruchteil der eingereichten Dokumente verifiziert und gleichzeitig zahlreiche Dokumente wegen winzigen Abweichungen abgelehnt. Bisher wurden allerdings auch noch keine Domains deaktiviert. Es sieht im Moment so aus, dass Änderungen an unverifizierten Domains nicht mehr möglich sind, die Domains aber weiterhin erreichbar bleiben.