Neue Hosting-Pakete mit dedizierten Servern

Nachdem wir zum Jahreswechsel unsere neuen Easy.Hosting-Pakete eingeführt haben, gibt es nun auch neue Pro.Hosting-Pakete, die sich an Kunden mit besonders hohen Ansprüchen richten.

Unser Pro.A-Paket ersetzt das bisherige Premium-Upgrade. Das Paket beinhaltet 10 Inklusivdomains, 50 GB Webspace und 100 Postfächer mit jeweils 10 GB Speicherplatz und kostet 30,- Euro pro Monat. Das Paket wird auf einem Premium-Server gehostet, der von maximal 9 anderen Kunden genutzt wird. Mit PHP-FPM bieten wir allen Betreibern von Online-Shops und Content-Management-Systemen die maximale Performance.

Die Pro.B- und Pro.C-Pakete nutzen jeweils einen kompletten Server für sich allein. Sie kosten 45,- Euro pro Monat bzw. 75,- Euro pro Monat und beinhalten noch mehr Speicherplatz, Datenbanken und Postfächer. Die Nutzung eines dedizierten Servers mit bis zu 4 CPU-Kernen, 8 GB RAM und PHP-FPM stellt genug Reserven für sehr umfangreiche und gut besuchte Seiten zur Verfügung.

Ihren Auftrag zum Tarifwechsel in eines der neuen Pakete nehmen wir jederzeit formlos per E-Mail entgegen. Für den Umzug auf den jeweiligen Server benötigen wir eine Vorlaufzeit von 2 Tagen, damit der Wechsel ohne Unterbrechungen stattfinden kann. Eine Übersicht aller neuen Pro-Pakete finden Sie auf unserer Webseite.

Probleme bei der Einrichtung von E-Mail-Konten unter Thunderbird

Beim beliebten E-Mail-Client Thunderbird gibt es einen seit mehreren Jahren unbehobenen Bug bei der Erkennung der SMTP-Server-Einstellungen, der für Probleme bei der Einrichtung von E-Mail-Konten sorgt.

Das SMTP-Protokoll wird zum Versenden von E-Mails genutzt. Thunderbird nutzt für SMTP standardmäßig den TCP-Port 587, für den wir auf unseren SMTP-Servern (optional) Verschlüsselung mittels StartTLS anbieten. Bei der automatischen Erkennung der Server-Einstellungen versucht Thunderbird zunächst eine verschlüsselte Verbindung mittels StartTLS aufzubauen. Wenn dies fehlschlägt, wird eine unverschlüsselte Verbindung genutzt.

Leider hält sich Thunderbird bei der Erkennung der SMTP-Server-Einstellungen nicht genau an das SMTP-Protokoll, so dass unser Mail-Server beim Verbindungsaufbau mittels StartTLS eine Fehlermeldung zurückliefert, und Thunderbird dann automatisch eine unverschlüsselte Verbindung wählt:

smtp_500

In aktuellen Thunderbird-Versionen wird dann im nächsten Schritt eine Warnung angezeigt, dass keine Verschlüsselung genutzt wird, obwohl unsere Server sehr wohl Verschlüsselung unterstützen:

tb-fehler-500

Wählen Sie in diesem Fall für den SMTP-Server entweder unter Port 465 und unter SSL SSL/TLS und klicken dann auf “Erneut testen”, dann sollte die automatische Erkennung sofort funktionieren und Sie können “Fertig” auswählen.

Alternativ können Sie unter Port 587 und unter SSL StartTLS wählen und dann “Erneut testen” klicken. Meistens schlägt der Verbindungstest dann jedoch erneut fehl, und Thunderbird meldet einen Fehler. In diesem Fall sollten sie so lange auf “Erneut testen” klicken, bis es irgendwann klappt. Dies erfordert normalerweise mehrere Versuche, doch irgendwann funktioniert es und Sie können “Fertig” auswählen.

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.

Aktuelle Änderungen an der Webserver-Konfiguration

Gegenwärtig wechseln wir die Server-Plattform bestehender älterer Webserver auf unsere aktuelle Softwareumumgebung, die wir seit Januar 2014 für neue Benutzeraccounts einsetzen. Dabei aktualisieren wir auch die verwendete Webserver-Software Apache von Version 2.2 auf 2.4, wodurch es vereinzelt zu Problemen aufgrund geänderter Konfigurationsdirektiven kommen kann.

Betroffen sind Benutzeraccounts, die vor dem Januar 2014 angelegt wurden.

Grundsätzlich sollten bestehende .htaccess-Konfigurationsdateien sowie HTML-Dateien mit “Server-Side-Includes” weiterhin funktionieren, in wenigen Ausnahmefällen kann es jedoch zu Problemen kommen. Eine ausführliche Dokumentation der mit Apache 2.4 möglichen Konfigurationsoptionen und SSI-Direktiven finden Sie hier.

Die Änderungen im Einzelnen:

  • Verzeichnisindex
    Auf den alten Webservern wurde für Verzeichnisse ohne Indexdatei (index.php, index.html usw.) standardmäßig eine Auflistung aller Dateien angezeigt, dieser Verzeichnisindex ist auf den neueren Webservern aus Sicherheitsgründen deaktiviert. Falls es keine gültige Index-Datei gibt, wird eine Fehlermeldung angezeigt. Diese Änderung wurde notwendig, da viele Kunden dieses Verhalten des Webservers nicht erwartet haben, und dadurch unter Umständen Dateien mit sensiblen Inhalten ungewollt  im Internet auffindbar waren. Um den Verzeichnisindex wieder zu aktivieren, legen Sie in in Ihrem Benutzerverzeichnis (bzw. dem gewünschten Unterverzeichnis) auf dem Webserver eine .htaccess-Datei mit der Option “Options +Indexes” an.
  • .htaccess-Dateien
    In .htaccess-Dateien ist unbedingt auf korrekte Groß- und Kleinschreibung bei den Konfigurationsdirektiven zu achten.
  • Server-Side-Includes
    Die Syntax für SSI-Expressions wurde in Apache 2.4 geändert, die alte Syntax lässt sich durch eine .htaccess-Datei mit der Option “SSILegacyExprParser on” wieder aktivieren.
  • Cronjobs
    Es ist in Einzelfällen vorgekommen, dass Cronjobs, die auf den bisherigen Servern liefen jetzt nicht mehr aktiv sind. Bitte fügen Sie diese wieder hinzu, sollte Ihr Benutzeraccount von dem Problem betroffen sein.
  • PHP
    Auf den neuen Webservern steht PHP 4 nicht mehr zur Verfügung, da es mittlerweile veraltet ist und sei Jahren nicht mehr mit Sicherheitsupdates versorgt wird. Verfügbar sind die PHP-Versionen 5.2, 5.3, 5.5 und 5.6. Die Standard-PHP-Version hat sich nicht geändert, für ältere Accounts ist dies weiterhin PHP 5.3. Sie können auch eine andere PHP-Version auswählen, Informationen dazu finden Sie hier. Bitte beachten Sie: Die Deaktivierung des ebenfalls veralteten PHP 5.2 ist für den 1.7.2015 geplant.
    Aus Sicherheitsgründen wurde weiterhin die PHP-Einstellung “allow_url_fopen” in allen PHP-Versionen standardmäßig deaktiviert. Sie können diese Einstellung über eine php.ini-Datei mit der Option “allow_url_fopen = on” wieder aktivieren.
  • SSH Host Keys
    Wir haben einige bestehende Webserver mit sehr vielen Präsenzen auf mehrere neue Server aufgeteilt, um die Leistung zu verbessern. Daher kommt es bei einigen Kunden-Accounts zu einer Warnung beim SSH- bzw. SFTP-Zugriff, dass sich der Host-Key geändert hat.
  • HTTP Status Codes
    Mit der neuen Apache-Version werden nur noch offizielle HTTP Status-Codes unterstützt. Die Verwendung inoffizieller Status-Codes wie 421 oder 509 in .htaccess-Direktiven führt jetzt zu einem Server-Fehler.
  • Server-Betriebssystem
    Durch den Wechsel der verwendeten Linux-Distribution von CentOS 5 auf Ubuntu 14.04 kann es für Kunden, die eigene Binärpakete nutzen, ebenfalls vereinzelt zu Problemen aufgrund aktuellerer Softwarepakete und Systembibliotheken kommen.

PHP 5.6 auf allen neuen Webservern

Ab sofort steht auf allen neuen Webservern PHP in der Version 5.6 zur Verfügung.  In unseren FAQ finden Sie eine Anleitung, wie sich PHP 5.6 für Ihren Benutzeraccount aktivieren lässt.

Kunden, die derzeit noch auf älteren Webservern liegen und PHP 5.6 daher noch nicht nutzen können, werden in den nächsten Wochen auf neuere Webserver umgezogen. Neu eingerichtete Benutzeraccounts werden ausschließlich auf neuen Webservern eingerichtet.

Ruhe in Frieden: SSL 3

SSL und TLS werden im Internet zum Verschlüsseln des Datenverkehrs zwischen Clients und Servern verwendet.  Es findet unter anderem Verwendung bei dem verbreiteten HTTPS-Protokoll, aber auch beispielsweise bei der Kommunikation zwischen E-Mail-Servern. Bei SSL handelt es sich ursprünglich um einen Standard von Netscape, während TLS seit 1999 der offizielle Nachfolger ist und von der IETF – dem Standardorgan des Internets – spezifiziert wird.

Da uns die Sicherheit der von unseren Kunden genutzten Dienste sehr am Herzen liegt, hatten unsere Server stets sehr ausgefeilte TLS-Konfigurationen, die maximale Sicherheit mit praktikabler Kompatibilität balancierten.  Deshalb war auch SSL in der Version 3 (die letzte Version vor TLS aus dem Jahr 1996!) aktiviert, da es keine handfesten Gründen dagegen gab.

Da sich nun jedoch die Gerüchte mehren (hier oder hier), dass Microsoft in dieser Woche kritische Probleme mit SSL 3 veröffentlichen will, nehmen wir es zum Anlass und deaktivieren es auf allen unseren Systemen.

Das bedeutet, dass ab sofort nur noch Verschlüsselung mit TLS 1.0 (aus dem Jahr 1999!) und neuer möglich ist.

In der Praxis bedeutet dies, dass Internet Explorer 6 unter Windows XP nicht mehr auf HTTPS-Seiten auf unseren Servern zugreifen kann.

Es ist jedoch weiterhin möglich unter Windows XP mit Internet Explorer 8, Firefox oder Chrome diese Seiten abzurufen. Wir denken daher nicht, dass ernsthafte Einschränkung bei der Nutzung unserer Webserver zu erwarten sind. Ebenfalls aktualisiert wurden die Konfigurationen unserer E-Mail-Server.

Update vom 15.10.2014: Mittlerweile wurde die Schwachstelle von Google (statt wie anfangs vermutet Microsoft) veröffentlicht: sie wurde POODLE getauft und ist ein naher Verwandter des älteren BEAST-Angriffs. Das bedeutet, es benötigt einen aktiven Angreifer und ist somit nicht mit Shellshock oder gar Heartbleed vergleichbar. Wir sehen uns in der Maßnahme, SSL 3 abzuschalten bestätigt. Es sind keine weiteren Maßnahmen notwendig.