Artikel mit Tag Einstellungen

ssh-audit - OpenSSH Sicherheit testen, konfigurieren und härten

Secure Shell (SSH) dürfte fast jeder schon einmal gehört haben, nicht nur wegen der vielen Updates in letzter Zeit.

Das Netzwerkprotokoll, welches häufig zur Wartung oder zum Datenaustausch mit entfernten Geräten verwendet wird, ist aus dem Alltag kaum wegzudenken.

SSH ermöglicht eine sichere Verbindung in unsicherer Umgebung, dank Verschlüsselung und Authentifizierung.

Neben Passwortauthentifizierung kann das Protokoll mit Public Key Verfahren genutzt werden, was durchaus zu empfehlen ist.

Die Einstellungen in der Konfiguration "/etc/ssh/sshd_config" dazu sind schnell gesetzt:

PubkeyAuthentication yes

PasswordAuthentication no

 

Neben der Authentifizierungsmethode gibt es allerdings noch weitere Einstellungsmöglichkeiten.

Um Verbindungen zwischen Client und Server möglichst sicher zu gestalten, können in der Konfiguration verschiedene Einstellungen gesetzt werden.

Unter anderen folgende Werte.

 

  • KexAlgorithms (Key Exchange): Die Schlüsselaustausch-Algorithmen für die symmetrische Verschlüsselung.
  • Ciphers Die Ciphers zur symmetrischen Verschlüsselung der Verbindung.
  • MACs (Message authentication codes): Nachrichten Authentifizierungsverfahren, um die Integrität zu sichern.
  • HostKeyAlgorithms Algorithmus welchen der Client verwendet

 

Durch alte bzw. gebrochene oder mangelhafte Verschlüsselung kann es zu Sicherheitslücken kommen, welche sich durch richtige Einstellungen vermeiden lassen.

Mit Hilfe des Kommandozeilen Tools ssh-audit lassen sich fehlerhafte SSH Einstellungen schnell ausfindig machen.

ssh-audit - OpenSSH Sicherheit testen und richtig konfigurieren

Das Programm liest die Version und Einstellungen von OpenSSH aus und zeigt im Ampelformat an, welche Algorithmen und Ciphers abgeschaltet werden sollten.

ssh-auditDazu werden zusätzliche Infos eingeblendet. Warum genau diese Cipher oder jener Algorithmus nicht mehr verwendet werden sollten.

In der aktuellen Programmversion 1.7.x werden folgende Hauptfeatures unterstützt.

  •     SSH1 and SSH2 protocol server support
  •     grab banner, recognize device or software and operating system, detect compression
  •     gather key-exchange, host-key, encryption and message authentication code algorithms
  •     output algorithm information
    • available since 
    • removed/disabled 
    • unsafe/weak/legacy, etc
  •     output algorithm recommendations
    • append or remove based on recognized software version;
  •     output security information
    • related issues
    • assigned CVE list, etc
  •     analyze SSH version compatibility based on algorithm information
  •     historical information from OpenSSH, Dropbear SSH and libssh
  •     no dependencies, compatible with Python 2.6+, Python 3.x and PyPy

Installation unter Ubuntu 16.04 und Python3

Die Installation ist relativ einfach, allerdings kann es sein, dass mit Ubuntu 14.04 und Python 2.7 und Ubuntu 16.04 mit Python 3 noch ein paar Handgriffe notwendig sind.

wget https://github.com/arthepsy/ssh-audit/archive/v1.7.0.zip

unzip v1.7.0.zip

cd ssh-audit-1.7.0/

Zum Starten des Audits muss Python Script und eine Serveradresse aufgerufen werden. Als ersten Test bietet sich localhost an.

Unter Ubuntu 16.04 muss allerdings darauf geachtet werden, dass Python 3 richtig eingerichtet ist. Darum sollte hier noch ein Symlink gesetzt werden, damit das Script richtig ausgeführt werden kann

$ python -V
-bash: /usr/bin/python: No such file or directory

$ sudo ln -s /usr/bin/python3 /usr/bin/python

$ ls -l /usr/bin/ |grep python
lrwxrwxrwx 1 root   root          16 Oct 29 19:29 python -> /usr/bin/python3

Danach kann das Audit Script den Ubuntu 16.04 Server auf schwache Einstellungen kontrollieren. Hier ein Auszug.

sudo ./ssh-audit.py localhost

# general
(gen) banner: SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
(gen) software: OpenSSH 7.2p2
(gen) compatibility: OpenSSH 7.2+, Dropbear SSH 2013.62+
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                    -- [fail] using weak elliptic curves

# host-key algorithms
(key) ssh-rsa                               -- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
(key) rsa-sha2-512                          -- [info] available since OpenSSH 7.2

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com         -- [info] available since OpenSSH 6.5
                                            `- [info] default cipher since OpenSSH 6.9.
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) umac-64-etm@openssh.com               -- [warn] using small 64-bit tag size
                                            `- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com              -- [info] available since OpenSSH 6.2


 

OpenSSH Härtung (ab Version OpenSSH 6.7)

Bei der neuesten OpenSSH Version können verschiedene Sicherheitseinstellungen gesetzt werden.

Im Screenshot seht ihr eine laut Audit optimale Einstellung für einen Server zum jetzigen Zeitpunkt.

ssh-gehaertet


Die Einstellungen kommen wie folgt zu Stande: 

Zunächst zum Key Exchange. Elliptische Kurven vom National Institute of Standards and Technology (Nist) haben nicht den besten Ruf und sind durch Timingangriffe verletzbar. SHA1 zählt auch nicht mehr zu den besten Methoden unserer Zeit und kann ebenfalls deaktiviert werden.

Das heißt von den verfügbaren Möglichkeiten (siehe unten) bleiben nur noch curve25519-sha256 und diffie-hellman-group-exchange-sha256 als Auswahl übrig. 

  • curve25519-sha256: ECDH over Curve25519 with SHA2
  • diffie-hellman-group1-sha1: 1024 bit DH with SHA1
  • diffie-hellman-group14-sha1: 2048 bit DH with SHA1
  • diffie-hellman-group-exchange-sha1: Custom DH with SHA1
  • diffie-hellman-group-exchange-sha256: Custom DH with SHA2
  • ecdh-sha2-nistp256: ECDH over NIST P-256 with SHA2
  • ecdh-sha2-nistp384: ECDH over NIST P-384 with SHA2
  • ecdh-sha2-nistp521: ECDH over NIST P-521 with SHA2
Quelle

Für Mac, HostKeys und Ciphers gelten ähnliche Regeln. Auch hier sollten Einstellungen mit MD5/SHA1 oder CBC entfernt werden. Open SSH Audit hebt diese in roter Schrift hervor. Am Ende bleibt eine sichere Einstellung und folgende Angaben unter /etc/ssh/sshd_config.

Diese beispielhaften Einstellungen wurde so gewählt, dass eine Verbindung via Windows und PuTTY möglich ist.

debianbanner no

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

Fazit

open-ssh audit bietet eine einfache und schnelle Möglichkeit SSH Verbindungen zu testen und bei Bedarf auch zu härten. Das Tool erklärt dem Nutzer seine Wahl und ist somit recht verständlich.

Allerdings sollte immer auf die jeweilige Umgebung in Verbindung mit den Einstellungen geachtet werden. Auch sollte nach einer Änderung zwingend eine Testverbindung aufgebaut werden (SSH Dienst neu starten nicht vergessen).

Details zu weiteren Einstellungen und deren Funktion, welche der Audit zurzeit nicht bieten kann, sollten an anderer Stelle nachgelesen werden. Hier empfiehlt sich das Raven Wiki für einen ersten Überblick

ssh audit

Kiosk Systeme für alle - kein Problem mit FullPageOS

Nicht nur im professionellen Bereich sind Kiosk Systeme gerne gesehen, auch im privaten Bereich erfüllen sie durchaus ihren Zweck.
In Firmen dienen sie der steten Überwachung im Netzwerkbereich oder einer ersten Firmenpräsentation in der Lobby. Im privaten Sektor können damit aktuelle Wetter- und Temperaturdaten auf den Bildschirm oder neuerdings den Spiegel gebracht werden.

Meistens steckt hinter solchen Systemen nicht mehr als ein RaspberryPi oder andere Mini Computer. Diese werden mit einem schlichten System bestückt und booten in die gewünschte Umgebung. Doch bis zum fertigen Kiosksystem sind oft mehrere Handgriffe notwendig, hier setzt FullPageOS an.

FullPageOS

FullPageOS - Kiosk System fürs Volk

FullPageOS ist ein Fork von OctoPi, welches im 3D Druckbereich verbreitet ist. Beide Systeme basieren auf Raspbian und bringen lediglich einige Scripte mit, welche das System zu einem reinen Kiosk System umwandeln.
Das FullPageOS bootet in diesem Fall einen Chromium Browser im Vollbildmodus, nicht mehr und nicht weniger, fast ganz ohne manuellen Eingriff ist aber auch das nicht möglich.
Die gewünschte Webseite zur Präsentation kann individuell festgelegt werden.

Installation FullPageOS

Konfiguration von FullPageOS

Auch wenn das System als fertiges Kiosk System angepriesen wird, sind ein paar wenige Handgriffe für die Erstkonfiguration notwendig.

Zunächst sollten die Lan- oder Wlan Einstellungen unter "/boot/fullpageos-network.txt" angepasst werden.

Ist dieser Schritt erledigt, wird das System nochmal gebootet.

Nun erfolgt eine Einwahl über SSH auf das Gerät (am besten mit Putty). Ein Login ist mit "pi" und "raspberry" möglich. Nach der ersten Verbindung sollte das Passwort des Standardnutzers mit "passwd pi" geändert werden. Weitere Konfigurationen können mit "sudo raspi-config" erfolgen.

Die Startseite eures Kiosk Systems kann unter "boot/fullpageos.txt" angepasst werden.

raspi-config

Auf dem System ist ein VNC Server zur Wartung vorinstalliert, solltet ihr diesen nicht benötigen, schaltet ihn besser ab.

sudo apt-get remove x11vnc

Je nach Sicherheitslevel können weitere Härtungsmaßnahmen ergriffen und unnötige Pakete oder Dienste deaktiviert werden.

Nach diesen letzten Schritten sollte ein fertiges Kiosk System vorhanden und funktionstüchtig sein.

Weitere Infos sind auf der Entwickler Webseite zu finden.



Für ein Kiosk System ist sicherlich nicht zwingend ein extra Betriebsystem notwendig, denn auch vorhandene Raspbians lassen sich einfach in ein Präsentations System umwandeln.

Kiosk System auf einem vorhandenen Raspbian installieren

Hier gilt, wie so oft, viele Wege führen ans Ziel, den einfachsten für ein vorhandenes Raspbian System möchte ich hier kurz aufzeigen.

Iceweasel installieren

Ein Kiosk System ist mit jedem Browser möglich, in diesem Beispiel wird Iceweasel verwendet, welches dem bekannten Firefox entspricht.

apt-get install iceweasel iceweasel-l10n-de

Beim zweiten Paket handelt es sich um das deutsche Sprachpaket

Verknüpfung von Iceweasel im Autostart erstellen und die Startseite anpassen

sudo cp /usr/share/applications/iceweasel.desktop /home/pi/.config/autostart/iceweasel.desktop

sudo nano /home/pi/.config/autostart/iceweasel.desktop
        Exec=iceweasel https://kioskmodus.online

Bildschirmschoner deaktivieren

Hier ist der einfachste Weg, einen vollwertigen Bildschirmschoner zu installieren und zu deaktivieren, damit erspart man sich die Suche nach den genauen Einstellungen.

sudo apt-get install xscreensaver

Unter den Einstellungen des Xscreensavers kann nach der Installation einfach auf  "deaktivieren" geklickt werden.  Als Alternative hier noch die Einstellungen via Kommandozeile.

sudo nano /etc/xdg/lxsession/LXDE/autostart

#@xscreensaver -no-splash

@xset s off #(Screensaver ausschalten) Geht alternativ auch über die Oberfläche.
@xset -dpms #(Energiesparmodus deaktivieren) Geht alternativ auch über die Systemeinstellungen
@xset s noblank #(Screensaver ausschalten)

Der Energiesparmodus sollte in jedem Fall ausgeschaltet werden, unabhängig davon wie der Bildschirmschoner deaktiviert wird.

Vollbildmodus via Plugin oder F11

Für Iceweasel/Firefox gibt es zwei Plugins, welche einen Kioskmodus verwalten, bzw. unterstützen. Unter dem Namen mKiosk oder rKiosk sind diese zu finden. Beide erfüllen ihren Zweck und bieten alles, was es zur Verwaltung eines Kiosksystems braucht.
 

firefox-kiosk


Sollten ihr damit nicht zurechtkommen, reicht es aus den Browser so zu konfigurieren, dass er nach einen Neustart mit den alten Einstellungen wieder hoch kommt. Danach startet ihr Iceewasel  mit F11 im Vollbild, diese Einstellungen wird er sich merken und nach dem nächsten Neustart habt ihr immer noch ein Vollbild (Hier besteht allerdings die Möglichkeit, dass andere Nutzer in das System eingreifen, da kein Password hinterlegt werden kann).

Manche Nutzer stören sich sicherlich am Mauszeiger, dieser kann mit Unclutter ausgeblendet werden.

sudo apt-get install unclutter

sudo nano /etc/xdg/lxsession/LXDE/autostart

@unclutter -idle 5

Fazit

FullPageOS ist eine praktische Variante für einen Kiosk Modus, wenn noch kein System vorhanden ist. Bei installiertem Raspbian ist der Betrieb als Kiosksystem mit wenigen Handgriffen auf gleichem Niveau möglich.

Bei Varianten erfüllen ihren Zweck, wobei sich FullPageOS auf Chromium eingeschossen hat. Der händische Kiosk Modus erlaubt den Einsatz verschiedener Browser und Einstellungen, egal ob Midori, Iceweasel oder Chrome. Hier wäre eine Auswahlmöglichkeit bei der Installation von FullPageOS sicherlich eine feine Sache.

Ubuntu - IPv6 auf einem Apache, MySQL Server ausschalten

Kurztipp zum Wochenende, zum Thema Ipv6 und Apache/MySQL. 

ipv6_apache2

IPv6 auf einem Apache Server ausschalten

Um IPv6 auf einem Apache2 Server abzuschalten genügt ein einfacher Eintrag in der ports.conf. 

Hier muss das vorhandene Listen 80 angepasst werden.

nano /etc/apache2/ports.conf

Listen 0.0.0.0:80

sudo service apache2 restart

Ipv6 bei einem MySQL Server deaktivieren

Beim MySQL Server verhält es sich ähnlich, wie beim Apache. Es genügt in der Hauptkonfiguration die Listenadresse zu setzen.

nano /etc/mysql/my.con

bind-address            = 0.0.0.0

sudo service mysql restart

apache

Das könnte dich auch interessieren

 

SSLyze - SSL Server Einstellungen per Kommandozeile überprüfen

Die richtigen SSL/TLS Einstellungen für Server zu finden ist nicht immer leicht. Eine etablierte Prüfvariante wird von SSL Labs gestellt. Auf deren Webseite können Server auf Herz und Nieren geprüft werden und bekommen im Optimalfall ein A+ Rating, wenn Techniken wie beispielsweise HTTP Strict Transport Security aktiv sind.

Seit kurzen stellt Qualys mit ssllabs-scan ein Tool auf Github zur Verfügung, welches einen Server Test via Kommandozeile erlaubt. Das Tool basiert auf der vorhandenen Technik und greift somit auch immer auf die Qualys Server zurück.

Als Alternative bietet sich das ebenfalls etablierte Phyton Script SSLyze an. Anders als ssllabs-scan unterstützt der SSL Scanner bereits SMTP, XMPP, LDAP, POP, IMAP, RDP und FTP und steht auch für Windows Nutzer zur Verfügung.

Download SSLyze

SSLyze unter Ubuntu Server 14.04, 16.04, 20.04 LTS verwenden

Installation

sudo apt install python-pip
pip install --upgrade setuptools
pip install sslyze
pip install --upgrade setuptools
pip install --upgrade sslyze
python -m sslyze --regular www.yahoo.com:443 www.google.com "[2607:f8b0:400a:807::2004]:443"

Alle Funktionen anzeigen

./sslyze.py --help

     Usage: sslyze.py [options] target1.com target2.com:443 etc...

Normaler Scan

Prüfung auf die Protokolle SSLv2.0, SSLv3.0, TLS1.0/1.1/1.2 Heartbleed, CipherSuites und andere Einstellungen.

Die reguläre Methode fast quasi eine Befehlskette zusammen "--sslv2 --sslv3 --tlsv1 --reneg --resum --certinfo=basic --hide_rejected_ciphers --http_get"

python -m sslyze --regular url.de:443

REGISTERING AVAILABLE PLUGINS
 -----------------------------
  PluginSessionRenegotiation
  PluginCompression
  PluginSessionResumption
  PluginHSTS
  PluginOpenSSLCipherSuites
  PluginChromeSha1Deprecation
  PluginCertInfo
  PluginHeartbleed

 CHECKING HOST(S) AVAILABILITY
 -----------------------------

   url.de:443                        => 127.0.0.1:443

 SCAN RESULTS FOR url.DE:443 - 127.0.0.1:443
 ---------------------------------------------------

  Deflate Compression:
      OK - Compression disabled

  Session Renegotiation:
      Client-initiated Renegotiations:   OK - Rejected
      Secure Renegotiation:              OK - Supported

  OpenSSL Heartbleed:
      OK - Not vulnerable to Heartbleed

  Session Resumption:
      With Session IDs:                  OK - Supported (5 successful, 0 failed, 0 errors, 5 total attempts).
      With TLS Session Tickets:          OK - Supported

  Certificate - Content:
      SHA1 Fingerprint:                  xxxxxxxxxxxxxxxx
      Common Name:                       url.com
      Issuer:                            url Internet xxxxxxxxx G2
      Serial Number:                     xxxxxxxxxxxxx
      Not Before:                        
      Not After:                         
      Signature Algorithm:               sha1WithRSAEncryption
      Key Size:                          2048 bit
      Exponent:                          xxxxxx (0x10001)
      X509v3 Subject Alternative Name:
 * Certificate - Trust:
      Hostname Validation:               FAILED - Certificate does NOT match url.de
      "Mozilla NSS - 08/2014" CA Store:  OK - Certificate is trusted
      "Microsoft - 08/2014" CA Store:    OK - Certificate is trusted
      "Apple - OS X 10.9.4" CA Store:    OK - Certificate is trusted
      "Java 6 - Update 65" CA Store:     OK - Certificate is trusted
      Certificate Chain Received:        ['url.com', ']

  Certificate - OCSP Stapling:
      NOT SUPPORTED - Server did not send back an OCSP response.

  SSLV2 Cipher Suites:
      Server rejected all cipher suites.

...........

Mit dem Zusatz "--hide_rejected_ciphers" lassen sich abgelehnte CipherSuites ausblenden, was die Übersicht erhöht.

Scan auf SHA-1

Eine ebenso praktische Scanvariante ist der Test auf SHA-1.

Die Hasfunktion SHA-1 wird beispielsweise von Google Chrome inzwischen als unsicher gemeldet.

python -m sslyze --chrome_sha1 url.de:443

 REGISTERING AVAILABLE PLUGINS
 -----------------------------

  PluginSessionRenegotiation
  PluginCompression
  PluginSessionResumption
  PluginHSTS
  PluginOpenSSLCipherSuites
  PluginChromeSha1Deprecation
  PluginCertInfo
  PluginHeartbleed

 CHECKING HOST(S) AVAILABILITY
 -----------------------------

  url.de:443                        => xxxxxxxxx:443

 SCAN RESULTS FOR url.DE:443 - xxxxxxxx:443
 ------------------------------------------------

  Google Chrome SHA-1 Deprecation Status:
      OK - Certificate chain does not contain any SHA-1 certificate.

Prüfung auf  HTTP Strict Transport Security HSTS Unterstützung

Auch das bereits oben erwähnte HSTS lässt sich überprüfen.

python -m sslyze --hsts url.de:443

Test auf StartTLS für SMTP oder XMPP Server

Gleiches gilt für XMPP oder SMTP Server.

python -m sslyze --starttls=smtp url

python -m sslyze --starttls=xmpp url

Zu den genannten Befehlen gibt es noch zig weitere Möglichkeiten SSL Server auf Konfiguration zu testen. Hier sei für alle Funktionen auf die Hilfe verwiesen, welche alle Befehle auflistet und erklärt. (Die Scanausgaben wurden zugunsten der Übersicht gekürzt).

Fazit

Anders als SSL Lab zeigt SSLyze kein Ranking und macht keine Überprüfung auf Browserunterstützung, dafür werden mehr Protokolle unterstützt. Je nach Einsatzgebiet werden wohl beide Tools benötigt. Auf einem Server ohne Browser und Co bietet sich SSLyze natürlich an.

Das Tool ist auf gängigen Linux Distributionen wie Kali Linux, die für Pentesting und andere Sicherheitschecks verwendet werden, mit an Bord.

Eine Übersicht, auf welche Wege SSL/TLS Cipher Suites gestetet werden können, bietet Oswap.

Tomcat 7/8 absichern - SSLv2 und SSLv3 deaktivieren - PFS aktivieren

In den damaligen Artikel über Poodle und SSLv3 Abschaltung bzw. Servehärtung ist der Tomcat total untergegangen. Das will ich mal schnell nachholen.

tomcat

Tomcat 7/8 härten - unsicheres SSL abschalten

Im Prinzip muss nicht viel gemacht werden, es sollten lediglich die richtigen Parameter in der server.xml hinterlegt werden. Zusätzlich darf natürlich gerne eine aktuelle und sichere Java Version verwendet werden.

Wichtig 

  • Aktuelle Java Version einsetzen
  • Aktuelle Tomcat Version einsetzen
  • Aktuelle DB Connectoren einsetzen

HTTPS Servereinstellungen

<Connector port="443" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true" maxThreads="150" maxHttpHeaderSize="8192" minSpareThreads="25" scheme="https" secure="true" keystoreFile="\PfadzumKeystore\keystore" keystorePass="Password" clientAuth="false" sslProtocol="TLSv1.2" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1"

ciphers="

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA"
 
/>

Die Erklärung für die einzelnen Attribute dieser Konfiguration könnt ihr hier finden.

Wer sich nun fragt, wo hier Perfect Forward Secrecy konfiguriert ist, der findet diese in allen Cipher Suites mit "ECDHE_ECDSA und ECDHE_RSA" wieder. Da diese präferiert werden ist ein Diffie-Hellman Schlüsselaustauschverfahren gewährleistet. ECDH_ECDSA und ECDH_RSA unterstützen übrigens kein PFS.

Weiterführende Links