Schlagwort: TLS

Veröffentlicht am

Abschaltung der unverschlüsselten Nutzung unserer Mailserver zum 05. März 2025

Ab dem 05. März 2025 werden wir keine unverschlüsselten Verbindungen und keine Verbindungen mit den veralteten TLS-Versionen (1.0 und 1.1) zu unseren SMTP-, IMAP- und POP3-Servern mehr zulassen. Diese Maßnahme dient dazu, die Sicherheit Ihrer Daten und unserer Systeme zu erhöhen.

Warum diese Änderungen?

Unverschlüsselte Verbindungen stellen ein erhebliches Sicherheitsrisiko dar: Zugangsdaten und E-Mail-Inhalte können einfach abgefangen werden.

Die TLS-Versionen 1.0 und 1.1 gelten seit 2021 als veraltet und werden von aktuellen Betriebssystemen und E-Mail-Programmen ohnehin nicht mehr unterstützt.

Was bedeutet das für Sie?

Die meisten unserer Kundinnen und Kunden müssen nichts tun. E-Mail-Konten, die in den letzten Jahren auf einem PC oder Smartphone eingerichtet wurden, sollten automatisch mit den richtigen Einstellungen für verschlüsselte Verbindungen angelegt worden sein.

Dennoch sollten Sie dies in den Konto-Einstellungen Ihres E-Mail-Programms prüfen. Für die Verbindung zu unseren Servern muss SSL/TLS oder STARTTLS aktiviert sein. Die Standard-Ports lauten:

SMTP
smtp.variomedia.de		IMAP
imap.variomedia.de		POP3
pop3.variomedia.de
STARTTLS587, 25143110
SSL/TLS465993995

Die Nutzung von TLS 1.2 (seit 2008) und neuer wird von den meisten Systemen seit vielen Jahren unterstützt:

  • Microsoft Outlook: ab Version 2016
  • Mozilla Thunderbird: ab Version 52
  • Windows: ab Version 8
  • macOS: ab Version 10.11.6
  • iOS: ab Version 9
  • Android: ab Version 5

Problematisch könnten sehr alte E-Mail-Programme, Betriebssysteme oder IoT-Geräte (z.B. Router, Multifunktionsdrucker, Netzwerkkameras) aus der Zeit vor dem Jahr 2016 sein, die E-Mails über unsere Server verschicken oder abrufen.

Erlaubt eines Ihrer Geräte oder E-Mail-Programme keine verschlüsselten Verbindungen zu Mailservern, sollten Sie prüfen oder beim Hersteller nachfragen, ob es ein entsprechendes Update gibt.

Übergangszeit

Für eine beschränkte Übergangszeit bis zum 30.05.2025 stellen wir alternative SMTP- und IMAP/POP3-Server bereit, die noch TLS 1.0 und 1.1 und unverschlüsselte Verbindungen unterstützen:

ProtokollServername
SMTPsmtp-legacy.variomedia.de
IMAPimap-legacy.variomedia.de
POP3pop3-legacy.variomedia.de

Bei Bekanntwerden schwerwiegender Sicherheitsprobleme mit TLS 1.0 oder 1.1 kann jedoch eine frühere Abschaltung dieser TLS-Versionen erforderlich werden.

Hintergrund: Abschaltung veralteter TLS-Versionen

Transport Layer Security (TLS), auch bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL), ist das am häufigsten verwendete Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Es wird beispielsweise zur verschlüsselten Übertragung von Webseiten (HTTPS) oder E-Mails (SMTPS, IMAPS, POP3S) genutzt.

Die ursprüngliche TLS-Version 1.0 wurde im Jahr 1999 vorgestellt, aktuell ist die TLS-Version 1.3 aus dem Jahr 2018. Die TLS-Versionen 1.0 und 1.1 wurden von der Internet Engineering Task Force (IETF) im März 2021 als veraltet eingestuft und sollten nicht mehr verwendet werden.

Die Unterstützung von TLS 1.0 und 1.1 bei verschlüsselten Webseiten (HTTPS) haben wir aufgrund von Sicherheitsproblemen bereits am 15. Februar 2020 eingestellt. Bei den E-Mail-Protokollen SMTP, IMAP und POP3 unterstützen wir jedoch aus Kompatibilitätsgründen bisher noch diese veralteten TLS-Versionen.

E-Mail-Programme verwenden normalerweise automatisch die aktuellste unterstützte TLS-Version, für die Nutzung einer aktuellen TLS-Version ist daher keine Konfigurationsanpassung erforderlich; es genügt ein aktuelles E-Mail-Programm zu verwenden. TLS 1.0 und 1.1 werden von aktuellen Betriebssystemen und E-Mail-Programmen nicht mehr unterstützt, diese verwenden immer TLS 1.2 oder 1.3.

Momentan können die TLS-Versionen 1.0 und 1.1 im E-Mail-Kontext mit bestimmten Schlüsselaustauschprotokollen und Verschlüsselungsalgorithmen noch ohne gravierende Sicherheitsprobleme genutzt werden, da es für diese bisher keine bekannten Schwachstellen gibt, die über die E-Mail-Protokolle ausgenutzt werden können. Einige bekannte E-Mail-Anbieter wie Google Mail unterstützen aus Kompatibilitätsgründen ebenfalls noch diese veralteten TLS-Versionen.

Im Hinblick auf mögliche Sicherheitsprobleme können wir diese veralteten TLS-Versionen jedoch nicht unbegrenzt weiter unterstützen, da es im Falle von neu entdeckten Problemen keine Updates der betroffenen TLS-Softwarebibliotheken mehr geben wird. Außerdem kann die Nutzung von veralteten TLS-Versionen durch Sicherheitsrichtlinien untersagt sein. Auch Cyberversicherungen untersagen ihren Kundinnen und Kunden vermehrt die Nutzung von Mailservern, die noch die veralteten TLS-Versionen unterstützen.

Veröffentlicht am

Auslaufen der Unterstützung von TLS 1.0 und TLS 1.1

HTTPS

Seit Anfang dieses Jahres haben die bekannten Web-Browser Chrome , Firefox, Safari, Internet Explorer und Edge begonnen, die Unterstützung der mittlerweile veralteten TLS-Versionen 1.0 und 1.1 einzustellen. Das TLS-Protokoll (früher SSL) wird zum verschlüsselten Webseitenabruf (HTTPS) und für den verschlüsselten Versand und Abruf von E-Mails genutzt.

Die TLS-Versionen 1.0 und 1.1 weisen diverse Sicherheitsprobleme auf und sollten nicht mehr genutzt werden. Wir werden daher die Unterstützung dieser TLS-Versionen auf unseren Webservern zum 15. Februar 2020 einstellen. Ab diesem Zeitpunkt werden für HTTPS-Verbindungen zu unseren Webservern nur noch die aktuellen und sicheren TLS-Versionen 1.2 und 1.3 unterstützt. Für E-Mail-Dienste (SMTP, POP3, IMAP) werden wir die veralteten TLS-Versionen zu einem späteren Zeitpunkt deaktivieren, da die Sicherheitsprobleme hauptsächlich HTTPS betreffen.

Mögliche Probleme

Alle modernen Web-Browser unterstützen die aktuelle TLS-Version 1.3. Die Vorgängerversion TLS 1.2 wurde bereits im Jahr 2008 vorgestellt, daher wird sie auch von etwas älteren Betriebssystemen und Web-Browsern unterstützt.

Nur bei sehr alten Browsern und Betriebssystemen (z.B. Windows XP, Android 4.3, iOS 4, OS X Yosemite) kann es durch die Deaktivierung von TLS 1.0 und 1.1 zu Problemen bei HTTPS-Verbindungen kommen.

Sie können bei ssllabs.com prüfen, ob Ihr Browser eine aktuelle TLS-Version unterstützt.

Kunden mit eigenem Webserver (Reseller.Dedicated bzw. Pro.Hosting-Paket ab Pro.B), sowie Nutzer unserer Legacy-Server für alte PHP-Versionen können auf Wunsch weiterhin TLS 1.0 und 1.1 für HTTPS nutzen, falls dies für die Kompatibilität mit älteren Browsern erforderlich sein sollte. Bitte wenden Sie sich dazu an unsere Kundenbetreuung.

Veröffentlicht am

Webserver: Abschaltung von PHP 5.2

Mit dem heutigen Tag wurde die Unterstützung der seit mittlerweile 8 Jahren veralteten PHP-Version 5.2 auf unseren Webservern beendet. Alle Webseiten, die noch PHP 5.2 nutzen, wurden auf die PHP-Version 5.6 umgestellt.

Wir haben alle betroffenen Kunden, die noch diese PHP-Version für Ihre Webseiten einsetzen, im Februar per E-Mail über die Umstellung informiert. Die Unterstützung der ebenfalls veralteten PHP-Versionen 5.3 und 5.5 wird zum 15.05.2019 eingestellt.

Für Kunden, deren Webseiten nicht mit aktuellen PHP-Versionen kompatibel sind, bieten wir einen Umzug auf (aufpreispflichtige) Legacy-Webserver an, auf denen wir diese PHP-Versionen noch für mindestens 2 Jahre bereitstellen werden. Weitere Hinweise finden sie in unseren FAQ.

Veröffentlicht am

Webserver: Neue Features TLS 1.3 und Brotli-Kompression

TLS 1.3

Unsere Webserver unterstützen für verschlüsselte HTTPS-Verbindungen ab sofort die aktuelle TLS-Version 1.3. Mit dieser TLS-Version wurden viele bekannte Schwachstellen der Vorgängerversionen entschärft, zusätzlich wurde auch die Aushandlung der Verschlüsselung beschleunigt.
Die mittlerweile veralteten TLS-Versionen 1.0 und 1.1 werden aus Kompatibilitätsgründen mit älteren Web-Browsern zunächst weiter unterstützt, wir planen jedoch, diese aus Sicherheitsgründen mittelfristig zu deaktivieren, so dass nur noch TLS 1.2 und 1.3 unterstützt werden.

Brotli-Kompression

Weiterhin können Sie für Ihre Webseiten nun auch die Brotli-Kompression nutzen. Dieses Kompressionsverfahren wurde speziell für Webseiten (HTML, CSS, JavaScript) entwickelt, und erreicht etwas höhere Kompressionsraten als gzip / Deflate. Sie können die neue Kompression per .htaccess-Konfigurationsdatei mittels folgender Direktive aktivieren:

AddOutputFilterByType BROTLI_COMPRESS;DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

Veröffentlicht am

PayPal Umstellung auf TLS 1.2 und HTTP/1.1

Ab Juli 2018 stellt der Zahlungsanbieter PayPal die Unterstützung der mittlerweile veralteten TLS-Versionen 1.0 und 1.1 ein. Weiterhin setzt PayPal dann zwingend das HTTP-Protokoll ab Version 1.1 voraus, ältere Versionen wie 1.0 werden nicht mehr unterstützt.

Webshops, die PayPal als Zahlungsmethode anbieten, und dabei direkt auf eine PayPal-Schnittstelle zugreifen (z.B. Instant Payment Notification), müssen bis dahin auf die aktuelle TLS-Version 1.2 sowie HTTP/1.1 umgestellt werden. Die meisten Webshops greifen auf die PayPal-Schnittstellen mittels libcurl zu, dabei wird auf unseren Webservern standardmäßig HTTP/1.1 und TLS 1.2 genutzt. Manche Webshops nutzen jedoch nicht die Standardeinstellungen von libcurl, sondern setzen ausdrücklich eine ältere TLS Version wie 1.0. Dies wird zukünftig zu Problemen führen.

PayPal informiert betroffene Kunden aktuell per E-Mail, diese müssen bis zum Juli 2018 ein Update der Webshop-Software bzw. des PayPal Zahlungsmoduls vornehmen.

Falls Sie noch einen älteren WebShop betreiben, und keine Updates für das PayPal-Zahlungsmodul bereitstehen, müssen Sie ggf. den PHP-Quellcode anpassen. Suchen Sie dazu nach allen PHP-Dateien, in denen die Zeichenfolgen “curl_setopt” und “TLSv1” vorkommen, und kommentieren diese in einem Text-Editor mittels vorangestelltem // aus. Sie können die betroffenen Dateien mit den entsprechenden Stellen im Quellcode über folgenden SSH-Befehl ermitteln:

find . -name "*.php" -exec grep "curl_setopt(.*TLSv1" {} \; -print
Veröffentlicht am

Beginn der Let’s Encrypt Testphase

Wie angekündigt beginnt ab heute (23.05.2016) die Testphase für Let’s Encrypt-Zertifikate auf unseren Webservern.

Während der Testphase kann in jedem Webhosting-Paket ein Let’s Encrypt-Zertifikat (gültig für eine Domain sowie auf Wunsch eine zusätzliche Subdomain wie z.B. www) kostenfrei genutzt werden. Reseller können in der Testphase für ihre Hosting-Kunden insgesamt bis zu 10 Let’s Encrypt-Zertifikate erhalten. Die Einrichtung der Zertifikate ist während der Testphase noch nicht über unser Kundenmenü möglich, bitte wenden Sie sich dazu an unsere Kundenbetreuung.

Nach Ablauf der Testphase bleiben Ihre Zertifikate erhalten, wir planen in jedem Webhosting-Paket für unsere Endkunden mindestens ein Let’s Encrypt-Zertifikat ohne Mehrkosten anbieten, die dann einfach über unser Kundenmenü eingerichtet werden können. Reseller werden je nach Paket eine bestimmte Anzahl an Inklusiv-Zertifikaten erhalten.

Voraussetzung für die Ausstellung von Let’s Encrypt-Zertifikaten ist die Nutzung unserer Nameserver. Die Zertifikate gelten weiterhin nur auf unseren Webservern, falls Sie eine Domain per DNS A-Record auf Webserver von einem anderen Anbieter weiterleiten, müssen Sie ein SSL-Zertifikat bei diesem Anbieter beauftragen.

Weiterhin unterstützt Let’s Encrypt gegenwärtig keine Domain-Namen mit Sonderzeichen (IDN).

Tipp: In unseren FAQ finden Sie eine Anleitung, wie Sie nach Einrichtung des Zertifikats alle unverschlüsselten HTTP-Aufrufe auf HTTPS umleiten können.

Unterschiede zwischen Let’s Encrypt- und Comodo-Zertifikaten

Wir haben auf unseren Webservern bisher ausschließlich SSL-Zertifikate der Firma Comodo genutzt. SSL-Zertifikate dienen nicht nur zur Verschlüsselung, sondern weisen auch den Inhaber einer Domain verbindlich aus. Zur Überprüfung der Inhaberschaft gibt es unterschiedliche Verfahren:

  • Das einfachste Verfahren ist die Domain-Validierung, dabei prüft die Zertifizierungstelle mittels automatisierter technischer Vefahren, ob der Inhaber der Domain mit dem des Zertifikats übereinstimmt. Dies kann beispielsweise über spezielle DNS-Einträge erfolgen, die nach Vorgabe der Zertifizierungstelle angelegt werden müssen, und dann von dieser automatisch überprüft werden. Bei Domain-validierten Comodo-Zertifikaten übernehmen wir selbst die Prüfung der Inhaberangaben.
  • Ein besseres Verfahren ist die Inhaber- bzw. Organisations-Validierung, dazu muss der Besitzer einer Domain sich bei der Zertifizierungstelle (z.B. mittels Personalausweiskopie bei Privatpersonen oder Handelsregisterauszug bei Firmen) ausweisen, und diese Daten werden dann mit den im Whois der Domain hinterlegten Inhaberdaten verglichen. Im Zertifikat wird der Inhaber dann im Feld Organisation hinterlegt, während dieses Feld bei Domain-validierten Zertifikaten leer bleibt. Zusätzlich erfolgt eine telefonische Validierung des Inhabers durch die Zertifizierungsstelle.
    Wir empfehlen Unternehmen, Inhaber-validierte Zertifikate zu nutzen, da bei Domain-validierten Zertifikaten ein Missbrauch durch Angabe falscher Inhaber-Informationen viel einfacher möglich ist. Inhaber-validierte Zertifikate sind in der Wahrnehmung der meisten Nutzer seriöser und vertrauenswürdiger.
  • Eine besonders strenge Prüfung erfolgt bei sogenannten Extended Validation Zertifikaten, die sich für hohe Sicherheitsanforderungen empfehlen. Bei diesen wird der Inhaber des Zertifikats in der Bowser-Adresszeile grün hinterlegt angezeigt (vgl. www.variomedia.de), allerdings sind diese Zertifikate auch besonders teuer.

Let’s Encrypt Zertifikate sind ausschließlich Domain-validiert, eine Inhaber-Validierung ist nicht möglich.

Ein weiterer Unterschied besteht bei der Einbindung der Zertifikate auf den Webservern: Auf unseren Webservern verwenden wir (wie alle Shared-Hosting-Anbieter) das sogenannte namensbasierte Virtual Hosting, dabei nutzen alle Domains auf einem Webserver die gleiche IPv4-Adresse, und der Webserver ordnet einer Domain anhand des vom Browser gesendeten HTTP Host-Headers eine Webseite zu. Bei Domains mit SSL-Zertifikaten war es jedoch bis vor wenigen Jahren noch nicht möglich, mehrere Zertifikate unter der gleichen IP-Adresse zu nutzen, daher erhält jedes Comodo-Zertifikat aus technischen Gründen immer eine eigene IPv4-Adresse, die dann zusätzlich auf dem Webserver eingerichtet wird.

Für Let’s Encrypt-Zertifikate können wir jedoch keine eigenen IPv4-Adressen mehr vergeben, denn dafür stehen uns nicht genügend ungenutzte IPv4-Adressen zur Verfügung. Mittlerweile gibt es jedoch mittels SNI die Möglichkeit, beliebig viele SSL-Zertifikate unter einer IP-Adresse zu nutzen, allerdings wird dieses Verfahren von älteren Browsern (z.B. Internet Explorer 6) und Betriebssystemen (z.B. Windows XP, Android 2.4) nicht unterstützt. Es kann daher mit Let’s Encrypt-Zertifikaten bei älteren PCs, Smartphones oder Tablets zu Problemen kommen.

Hinsichtlich der Verschlüsselung gibt es jedoch keine Unterschiede zwischen Let’s Encrypt- und Comodo-Zertifikaten, unsere Webserver erfüllen alle modernen Standards wie TLS Version 1.2, (EC)DHE-Schlüsselaustausch (Perfect Forward Secrecy) und AES-Verschüsselung (SSL Labs Note A+ bei gesetztem HSTS-Header).

Update vom 01.02.2017: Die Testphase ist jetzt beendet. Bitte beachten Sie folgenden Blog-Beitrag: Let’s Encrypt-Zertifikate jetzt offiziell erhältlich

Veröffentlicht am

Kostenlose Let’s Encrypt Zertifikate bei Variomedia

Wie bereits angekündigt, wird es bald möglich sein, über uns kostenlose SSL-Zertifikate von Let’s Encrypt auf den Webservern zu beauftragen.

Wir haben die dafür nötigen Technologien und Methoden implementiert und werden voraussichtlich ab dem 23.05. zunächst eine Testphase für interessierte Kunden anbieten, um eventuell noch auftretende Probleme bei der automatischen Erstellung und Validierung von Zertifikaten zu beseitigen.

In der Testphase können SSL-Zertifikate auf Wunsch durch unsere Kundenbetreuung installiert werden, genauere Details zum Ablauf werden wir nächste Woche bekannt geben. Sobald alles zuverlässig funktioniert, können SSL-Zertifikate später einfach per Mausklick im Kundenmenü eingerichtet werden.

Wir planen, in jedem unserer Webhosting-Pakete zukünftig mindestens ein kostenloses SSL-Zertifikat anzubieten, das für eine Domain sowie die zugehörige www-Subdomain gilt.

Veröffentlicht am

Let’s Encrypt Zertifikate bei Variomedia

Ab dem 3. Dezember wird die Zertifizierungsstelle Let’s Encrypt kostenlose SSL-Zertifikate für Webserver ausstellen, die von sämtlichen Web-Browsern akzeptiert werden. Wir erhalten derzeit viele Anfragen von Kunden, ob wir diese ebenfalls unterstützen werden. Grundsätzlich planen wir, Let’s Encrypt Zertifikate anzubieten. Es gibt allerdings noch einige bisher ungelöste technische Probleme bei der Domain-Validierung durch Let’s Encrypt, so dass wir derzeit noch nicht genauer sagen können, wann und in welcher Form wir diese Zertifikate anbieten können.

Um ein SSL-Zertifikat zu erhalten, muss zuvor bei der Zertifizierungsstelle der Besitz der Domain nachgewiesen werden. Let’s Ecrypt nutzt hierzu einen Mechanismus, der eine Datei mit einem verschlüsselten Token per HTTP von der gewünschten Domain herunterlädt, die nur vom Inhaber der Domain angelegt werden kann. Alternativ kann auch eine Validierung mittels spezieller DNS-Einträge erfolgen, dieses Verfahren wird jedoch zum Start von Let’s Encrypt am 3. Dezember noch nicht unterstützt, sondern erst später nachgereicht.

Um den gesamten Vorgang zu automatisieren stellt Let’s Encypt eine eigene Software bereit, die jedoch auf unseren Webservern nicht funktioniert. Wir müssen daher das von Let’s Encrypt genutzte ACME-Protokoll selbst implementieren. Weiterhin gelten die Let’s Encrypt-Zertifikate nur 90 Tage, so dass wir auch eine automatische Verlängerung implementieren müssen. Eine automatisierte Validierung ist in unserem Webserver-Verwaltungssystem praktisch nur mittels DNS-Validierung umsetzbar, daher müssen wir noch warten, bis dies von Let’s Encrypt unterstützt wird.

Bitte beachten Sie, dass es bei uns grundsätzlich nicht möglich ist, selbst erstellte oder von regulären Zertifizierungsstellen direkt erworbene SSL-Zertifikate einzubinden, da wir ein automatisiertes System zur Verwaltung von SSL-Zerfikaten nutzen, das nicht mit Zertifikaten anderer Anbieter funktioniert.

Veröffentlicht am

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 Diffie–Hellman-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-Diffie–Hellman (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.