Mehr Sicherheit durch aktuelle SSL/TLS-Versionen in Plesk

Server Security

Wir nutzen für unsere Server vielfach Plesk als Verwaltungstool. Beim Prüfen eines SSL-Zertifikates ist nun aufgefallen, dass TLS in den Versionen 1.1 und 1.0 noch unterstützt wurde.

TLSv1.0 und TLSv1.1 unter Plesk deaktivieren

Nachdem man sich auf dem Server eingeloggt hat, wird einfach der folgende Befehl ausgeführt:

plesk bin server_pref -u -ssl-protocols 'TLSv1.2 TLSv1.3'

Dieser Befehl aktiviert um genau zu sein TLSv1.2 und 1.3 als einziges. Wenn man vorher (oder nachher) Prüfen möchte, welche Methoden freigeschaltet sind:

plesk bin server_pref -s | grep ssl-protocols

ACHTUNG: Achte unbedingt darauf, dass dein Server die entsprechenden Protokolle unterstützt! Ebenfalls ist so eine Kommunikation mit älteren Browsern oder E-Mail-Programmen nicht mehr mit dem Server möglich, da diese die Methoden nicht unterstützen!

Unsichere Cipher Suites deaktivieren

Im Transport Layer Security (TLS) Protokoll legt die sog. Cipher Suite fest, welche Algorithmen zum Aufbau einer gesicherten Datenverbindung verwendet werden sollen. Dabei identifiziert jede Cipher Suite eine Kombination aus vier Algorithmen: Schlüsselaustausch, z.B.: RSA, DH (auch ADH, ECDH), PSK, SRP.

Nun waren bei uns noch schwächere Kombinationen möglich:

Unsichere Cipher Suites

Diese werden deaktiviert, indem man nur diese setzt, die man unterstützen möchte. Für TLSv1.3 wären das die folgenden:

  • AES_256_GCM_SHA384
  • CHACHA20_POLY1305_SHA256
  • AES_128_GCM_SHA256

Für TLSv1.2 diese:

  • ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • ECDHE_RSA_WITH_AES_256_GCM_SHA384
plesk bin server_pref -u -ssl-ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384'

ein wenig sicherer wäre folgende Konfiguration:

plesk bin server_pref -u -ssl-ciphers ‚ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256‘

Mit dieser Konfiguration kommen auch noch ältere Apple Computer und Smartphones problemfrei auf den Server.

CAA-Ressource-Reccord (RR) im DNS setzen für die Domains

Ein CAA-Record definiert, welche Zertifizierungsstellen (die sog. CA = Certificate Authority) Zertifikate für eine bestimmte Domain oder Subdomain ausstellen dürfen. Ab September 2017 sind Aussteller von SSL-Zertifikaten dazu verpflichtet, CAA-Einträge zu prüfen.

Somit kann zu jeder Domain, die über Lets Encrypt die Zertifikate bekomme nun noch ein CAA-Eintrag im DNS hinzugefügt werden:

0 issue "letsencrypt.org"

Somit ist dann die Sicherheit der Domains und der entsprechenden Übertragungsmethodiken auch wieder ein Stückchen besser geworden.

Hier könnt ihr übrigens auch die Qualität der Verschlüsselung Eurer Domain Prüfen: ssllabs.com/ssltest/analyze

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Weitere spannende Posts zu digitalen Themen

Allgemein

SEO leicht gemacht oder doch nicht?

Einer meiner Kunden hatte mir die nachfolgende E-Mail weitergeleitet. Sie hatte Ihn angesprochen und er fragte nun mich als seinen Entwickler, ob er diesen Bericht

Willst du dein Unternehmen digital nach vorne bringen?

Kontaktiere uns jetzt

small_c_popup.png

Bestelle für Deine Webseite das

Soforthilfe-Paket

Wir schauen uns das Problem direkt unverbindlich an und melden uns bei Dir. Wir teilen dir mit was wir benötigen und gehen an die Arbeit. Je 15 Minuten berechnen wir 30,- Euro netto, egal wie viel Uhr es ist.