Schlagwort-Archive: Webserver

Let’s DFN-PKI!

Häufig wird in letzter Zeit die Frage nach dem Verhältnis der DFN-PKI zu Let’s Encrypt oder nach der Unterstützung des ACME-Protokolls gestellt. Es muss hierbei beachtet werden, was genau gemeint ist: Häufig wird ACME und Let’s Encrypt in einen Topf geworfen, was die Beantwortung der Frage nicht einfacher macht: Soll die DFN-PKI wirklich ACME sprechen oder soll sie so (einfach) funktionieren wie Let’s Encrypt?

Um diese Frage zu beantworten, müssen zwei Aspekte erst einmal getrennt betrachtet werden:

  1. Was ist der Unterschied zwischen der DFN-PKI und Let’s Encrypt?
  2. Unterstützt die DFN-PKI das ACME-Protokoll bzw. ist dies geplant?

Was ist der Unterschied zwischen der DFN-PKI und Let’s Encrypt?

Ganz einfach: Let’s Encrypt stellt domainvalidierte (DV) Serverzertifikate aus, die DFN-PKI stellt organisationsvalidierte (OV) Serverzertifikate aus. Aber was heißt das konkret? Das bereitgestellte Vertrauensniveau soll hier anhand der Aussage eines Serverzertifikats verglichen werden:

Zunächst das OV-Zertifikat, z.B. aus der DFN-PKI:

„Der Server www.example.com hat den öffentlichen Schlüssel 123456. Das Zertifikat wurde der Organisation XYZ ausgestellt und die Berechtigung dieser Organisation zur Verwendung der Domain in einem Zertifikat wurde geprüft. Die Rechtsperson Organisation XYZ sitzt in Land A in Stadt B in Bundesland C.“

Nun die Aussage eines DV-Zertifikats:

 „Der Server www.example.net hat den öffentlichen Schlüssel 987654“

DV-Zertifikate treffen also keine Auskunft darüber, wer den Server betreibt oder wo derjenige zu finden wäre. Das heißt, DV-Zertifikate taugen nur für die Verschlüsselung der übertragenen Daten. Die Authentisierung der juristischen Person des Verantwortlichen für den Server entfällt vollständig. Das bedeutet wiederum, dass für einen Nutzer nicht ersichtlich ist, ob er auf der richtigen Webseite ist. Dies lässt sich an www.dfn.de und www.dfn.com veranschaulichen. Beide Webseiten könnten problemlos mit validen DV-Serverzertifikaten geschützt sein. Ein Nutzer könnte dann aber nicht erkennen, ob er mit der Webseite der Organisation kommuniziert, die er intendiert hat (www.dfn.de vom DFN-Verein e.V.) oder einem völlig unbeteiligten Dritten. Noch schlimmer wird es, wenn diese Verwechslungsgefahr von Angreifern böswillig ausgenutzt wird.

Bei DV-Zertifikaten ist also lediglich die Kommunikation verschlüsselt, was Man-In-The-Middle-Angriffe verhindert. Sollte ein Betreiber aber in bösartiger Absicht www.dfn.de mit einer ähnlichen Domain und einem völlig validen DV-Serverzertifikat für diese Domain imitieren, beispielsweise um Passwörter abzugreifen, bestünde kein Schutz dagegen. Im Gegenteil würden sich viele Nutzer durch das Schloss in der URL-Zeile des Browsers möglicherweise sogar bestätigt sehen, eine „sichere“ Verbindung zu haben und daher ihr Passwort arglos eingeben.

Die zusätzlichen Aussagen zum Betreiber der Webseite bei Organisationsvalidierung (Organisationsname, Land, Ort und Bundesland) müssen durch die CA validiert werden. Diese Schritte sind in der DFN-PKI notwendig und erzeugen den wahrnehmbaren Overhead zu domainvalidierten Zertifikaten. Alle diese Werte können aber in den DFN-PKI für die betreffenden Domains vorab validiert werden, d.h. vor einer tatsächlichen Antragsstellung für Zertifikate unter dieser Domain. Wenn alle Werte für hs-pellworm.de vorab validiert sind, kann die Ausstellung aller konkreten Zertifikate mit FQDNs mit dieser Domain ohne erneute Validierung durch die DFN-PKI geschehen[1].

Unterstützt die DFN-PKI das ACME-Protokoll oder ist das geplant?

Das ACME-Protokoll wird in der DFN-PKI derzeit nicht unterstützt, ist aber perspektivisch in der Tat sehr interessant. ACMEv1 war allerdings nicht mächtig genug für die Organisationsvalidierung. Das ist mit ACMEv2 inzwischen besser geworden und ACME wurde als RFC 8555 von der IETF standardisiert. Die Umsetzung einer ACME-Schnittstelle in der DFN-PKI bringt allerdings signifikante Softwareentwicklungs-Aufwände mit sich, die wohl überlegt sein wollen.

Derzeit besteht mit der SOAP-Schnittstelle der DFN-PKI schon eine etablierte Schnittstelle, mit der ähnliche Workflows wie mit ACME umgesetzt werden können. Diese Schnittstelle ist zwar nicht standardisiert, die Softwareentwicklung gegen diese Schnittstelle wird von der DFN-PKI aber mit Beispiel-Implementierungen und API-Dokumentationen unterstützt. Der Vorteil der Unterstützung von ACME wäre also auf eine Unterstützung durch zunehmend Verbreitung findende ACME-Client-Tools beschränkt. Komplett neue Workflows, die derzeit nicht möglich wären, ergeben sich aber nicht unbedingt.

Darüber hinaus gibt es noch eine weitere Argumente, die zumindest dagegen sprechen, dass eine ACME-Unterstützung das „Allheilmittel“ für die effiziente Serverzertifikaterstellung in der DFN-PKI wäre:

  • Für einige Appliances/Softwares, die jetzt ACME mit Bordmitteln können, gilt, dass sie auf Let’s Encrypt hart verdrahtet sind – Es brächte also in diesen Fällen keinen Vorteil, wenn die DFN-PKI eine ACME-Schnittstelle anböte.
  • Die ACME-Tools funktionieren im Wesentlichen auf „normalen“ (Web-)Servern, die auch Verbindungen nach Außen aufmachen können/dürfen. Appliances, Access Points, Firewalls, interne Server ohne Außenkommunikation,… unterstützen in der Regeln kein ACME, benötigen aber auch häufig Server-Zertifikate. Dies müsste also auch bei der Verwendung von ACME mittels eigener Software auf dedizierten „Zertifikatsantragsmaschinen“ automatisiert werden – diese könnten dann aber auch gleich gegen die DFN-PKI SOAP-Schnittstelle entwickelt werden.
  • Es bleiben die Validierungspflichten von OV – so einfach wie Let’s Encrypt wird es also auch mit ACME nicht, manuelle Schritte bleiben notwendig (auch wenn diese, wie bereits jetzt, größtenteils vor der ersten Beantragung für eine Domain erledigt werden können).

Ein derzeit notwendiger manueller Schritt ist die Freigabe des Zertifikatantrags durch den Teilnehmerservice der DFN-PKI vor Ort anhand des Papierantrags, der bei der Beantragung als PDF erzeugt wird und ausgedruckt, unterschrieben und geprüft werden muss. Wenn dieser manuelle und analoge Schritt entfiele, wäre das für viele Workflows hilfreicher als die Umstellung von der DFN-PKI SOAP-Schnittstelle auf ACME. Daher konzentriert sich das Team der DFN-PKI derzeit weniger auf die Einführung der ACME-Schnittstelle als auf die Umstellung auf eine papierlose Zertifikatbeantragung für Serverzertifikate.

Fazit

ACME ist mittelfristig für die DFN-PKI ein interessanter Standard, um die SOAP-Schnittstelle abzulösen. Dies sollte aber erst passieren, wenn die bestehende SOAP-Schnittstelle „End of Life“ ist und sowieso eine Neuentwicklung ansteht, da sich keine grundlegend neuen oder effizientere Workflows durch die Umstellung auf ACME ergeben. Dies jetzt vorzuziehen würde Entwicklerkapazitäten binden, die derzeit an anderen Stellen der DFN-PKI sinnvoller eingesetzt werden.

Domainvalidierte Zertifikate wie die von Let’s Encrypt eignen sich gegebenenfalls für den privaten Gebrauch oder für Testumgebungen, Prototypen, etc. um niederschwellig an ein „echtes“ Serverzertifikat zu kommen. Auf Produktivsystemen sollte man sich aber sehr genau überlegen, ob das niedrigere Vertrauensniveau der Domainvalidierung ausreicht und ob die ACME-Tools überhaupt auf allen beteiligten Systemen lauffähig sind und auch zu den Validerungsservern der gewünschten CA kommunizieren dürfen/können.

Zur Vereinfachung von Workflows zur Ausstellung von Serverzertifikaten in der DFN-PKI wird derzeit die papierlose Beantragung von Serverzertifikaten konzipiert. Dies in Kombination mit der bestehenden SOAP-Schnittstelle erlaubt weitestgehend die gleichen Workflows wie bei der Verwendung des ACME-Protokolls. Dabei wird aber das Vertrauensniveau der DFN-PKI mit organisationsvalidierten Zertifikaten unter einer vertrauenswürdigen Root-CA und dem vertrauenswürdigen Betrieb der Sub-CAs durch den DFN-Verein genutzt, was bei einem Wechsel zu einem domainvalidierenden Anbieter nicht der Fall wäre.

(Ralf Gröper, 27.03.2019)

[1] Alle 825 Tage (=ca. 2,25 Jahre) müssen die Werte re-validiert werden. Das geschieht für Name, Land, Stadt und Bundesland „hinter den Kulissen“ automatisch durch die DFN-PCA. Für die Domains passiert dies im Self-Service durch den Teilnehmerservice vor Ort mit wenigen Klicks in wenigen Sekunden.

Konfiguration von TLS-Servern: Aktueller Cipher-String

Bekanntermaßen ist die Konfiguration der Crypto-Parameter von TLS-Servern  eine kontinuierliche Aufgabe, siehe hierzu auch den ausführlichen Artikel Konfiguration von TLS-Servern: Ständige Herausforderung.

In unserem aktuellen Apache Cipher-String haben wir 3DES entfernt:

SSLCipherSuite 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP:!PSK:!DSS:!SEED:!ECDSA:!CAMELLIA'

Bitte beachten Sie auch die weiteren Konfigurationsempfehlungen aus dem oben genannten Artikel , insbesondere die Anleitung für individuelle Diffie-Hellman-Parameter!

(jbr, 10.12.2017)

Konfiguration von TLS-Servern: Ständige Herausforderung

Die Konfiguration von TLS-Servern wird immer mehr zur großen Herausforderung für Administratoren. Die verschiedenen Einstellungsmöglichkeiten für die Algorithmen, die TLS-Version und weitere Nebenparameter sind sehr komplex und für den Einzelnen kaum direkt bewertbar.

Noch unangenehmer wird die Situation dadurch, dass inzwischen mehrmals pro Jahr neue Erkenntnisse über die Sicherheit von TLS-Konfigurationen veröffentlicht werden; aktuelles Beispiel ist Logjam. Diese Erkenntnisse spiegeln sich direkt in Änderungen an sehr wichtiger Software wie Mozilla Firefox oder Google Chrome wieder, die als unsicher geltende Konfigurationen dann auch klar und deutlich markieren. Über deren Auto-Update-Funktion dauert es dann nur wenige Wochen, bis Endanwender neue Fehlermeldungen über unsichere Konfigurationen zu sehen bekommen.

Man kann sich daher nicht auf eine einmal gefundene Konfiguration verlassen, sondern muss ständig Anpassungen vornehmen, damit ein TLS-Server sicher bleibt und moderne Client-Software ohne störende Warnmeldungen darauf zugreifen kann.

Andererseits gibt es viele alte Software, die mit modernen Konfigurationen nicht kompatibel ist. Betroffen ist sowohl die Server- als auch die Client-Seite. Die direkte Übernahme von Konfigurationsvorschlägen kann dadurch auch unerwünschte Nebenwirkungen haben und für ernsthafte Betriebsstörungen sorgen.

Um welche Server muss man sich kümmern?

Generell muss bei jedem Server, der in irgendeiner Art TLS unterstützt und verwendet, die TLS-Konfiguration vom Administrator regelmäßig überprüft werden. Betroffen sind z.B. die folgenden Dienste/Protokolle :

  • Webserver
  • IMAP/POP3
  • SMTP
  • OpenVPN
  • LDAPS
  • FTPS

Konfigurationsempfehlungen

Es ist dringend anzuraten, die Konfiguration eines TLS-Servers nicht komplett selbst zu erstellen, sondern immer von Empfehlungen von Experten auszugehen und Änderungen nur vorsichtig und mit Bedacht vorzunehmen. Es gibt zahlreiche Empfehlungen, denen man folgen kann:

Bettercrypto

Das Bettercrypto-Projekt erstellt einen Katalog an Algorithmen- und Konfigurationsempfehlungen für verschiedenste Software und reagiert sehr schnell auf neue Entwicklungen. Die Vielfalt und die kryptographische Expertise sorgen allerdings auch für eine kleine Schwäche des Projektes: Der Leitfaden ist sehr umfangreich und damit etwas unübersichtlich. Dafür erhält man aber auch Konfigurationsempfehlungen für selten behandelte Software.  https://bettercrypto.org/

Mozilla

Für den Einstieg leichter zu lesen sind die Empfehlungen des Operating-Teams des Mozilla-Projekts: https://wiki.mozilla.org/Security/Server_Side_TLS

Allerdings ist der von Mozilla vorgestellte Ciphersuite-String sehr unübersichtlich und aus unser Sicht unnötig komplex. Eigene Anpassungen sind alleine aufgrund der Länge des Strings praktisch nicht möglich.

Besonders interessant ist der „Mozilla SSL Configuration Generator“, mit dem man sich für diverse Server-Software eine fertige Konfiguration erzeugen lassen kann: https://mozilla.github.io/server-side-tls/ssl-config-generator/

Spezialfall Microsoft Server

Microsoft Server wie IIS oder Exchange arbeiten system-typisch nicht mit einer Konfigurationsdatei, sondern über Registry-Keys, wodurch die Übersichtlichkeit deutlich leidet. Microsoft dokumentiert die vorhandenen Registry-Keys auf der folgenden Seite:

https://technet.microsoft.com/en-us/library/dn786418.aspx

Konkrete Ratschläge für eine brauchbare Konfiguration finden sich z.B. bei Alexander Hass:

https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12

Microsoft liefert Anpassungen an die TLS-Konfiguration teilweise auch per Update aus, so dass der Bedarf, selbst Änderungen vorzunehmen, nicht ganz so groß ist wie z.B. bei Apache httpd. Trotzdem sollte auch bei Microsoft-Servern regelmäßig getestet werden, ob die Sicherheit der TLS-Konfiguration noch gegeben ist

Auswirkungen von Fehlern bei der TLS-Konfiguration

Zu alte Konfiguration: Veraltete Konfigurationen sind generell unsicher, ermöglichen das Abhören der Verbindung und möglicherweise sogar die Manipulation von übertragenen Daten.

Aber auch ohne einen konkreten Angreifer gibt es deutliche Konsequenzen: Unterstützt man alte Algorithmen, beschweren sich moderne Webbrowser wie Firefox und Chrome sehr aggressiv, und präsentieren dem Nutzer Warnhinweise über die unsichere Verbindung oder verweigern den Verbindungsaufbau gleich ganz.

Zu moderne Konfiguration: Hat man zu aggressiv nur die modernsten Algorithmen konfiguriert, sperrt man ältere Software aus. Während Windows XP hoffentlich bei niemandem mehr ernsthaft ein Thema ist, wird der Support von Android 4.3 für viele öffentlich erreichbare Webserver Pflicht sein. Die modernsten Einstellungen werden aber nur von Internet Explorer ab Version 11, Java 8, und Android ab 4.4 unterstützt. Dagegen sind Firefox und Chrome, auch durch die Auto-Updates, relativ unkritisch.

Java 6 (was übrigens seit Februar 2013 keine Sicherheitspatches mehr erhält und dringend außer Betrieb genommen werden sollte) ist sehr empfindlich und kaum noch vernünftig zu bedienen. Muss man solche alten Systeme unterstützen, hat man ein größeres Problem. Größtes Problem bei Java 6 ist die fehlende Unterstützung für Diffie-Hellman-Parameter mit mehr als 1024 Bit.

Tests

Aufgrund der Komplexität der vielen Einstellungsmöglichkeiten sollte man immer einen Test durchführen. Ohne Test kann niemand garantieren, dass einerseits die Kompatibilität zu den gewünschten Systemen da ist, andererseits der Server aber trotzdem eine sichere Konfiguration hat.

Eine sehr schöne Möglichkeit ist der SSL-Test von Qualys, der eine gute Übersicht über die Sicherheit des TLS-Servers bietet und dazu direkt die Kompatibilität zu über 30 Browsern und Betriebssystemen prüft: https://www.ssllabs.com/ssltest/

Leider liegt der Fokus der meisten Testtools auf Webserver/Port 443. Für andere Protokolle sind die Testmöglichkeiten rar.

Beispielkonfiguration

Als Beispiel soll hier die Apache-Konfiguration dieses Blogs, wie sie aktuell (Juni 2015) gesetzt ist, beschrieben werden. Übernehmen Sie diese Konfiguration nicht kritiklos, sondern prüfen Sie, ob sie Ihren Anforderungen genügt, und testen Sie gründlich!

Die Konfiguration ist nach unserem Kenntnisstand mit den meisten Systemen kompatibel, mit den verschmerzbaren Ausnahmen IE6/Windows XP und Java 6.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCompression Off
SSLCipherSuite 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:ECDH+3DES:DH+3DES:RSA+3DES:!aNULL:!eNULL:!LOW:!RC4:!MD5:!EXP:!PSK:!DSS:!SEED:!ECDSA:!CAMELLIA'

Diffie-Hellman-Parameter

Um speziell gegen Logjam sicher zu sein, sollte man eigene, individuelle Diffie-Hellman-Parameter verwenden. Für Apache httpd muss man diese selbst erzeugen. Der folgende Aufruf erzeugt sichere 2048-Bit Parameter und gibt sie auf die Konsole aus. Es wird empfohlen, dass die Länge der Diffie-Hellman-Parameter gleich der Länge des Server-Schlüssels ist, um ein gleichmäßiges Sicherheitsniveau zu erreichen. openssl kann übrigens durchaus einige Zeit an den neuen Parametern rechnen.

openssl dhparam 2048

Zur Konfiguration eines Apache httpd gibt es zwei Varianten, je nach Version: Bei nicht Top-aktuellen Versionen von Apache und openssl müssen die erzeugten Parameter an das Ende des Serverzertifikats (konfiguriert in SSLCertificateFile) angehängt werden, Beispiel:

[...]
 /s0FbDV+wjkbr9xzW4cG2ehbx2nsMXicRrrER1X5DGxl4KbzK0jzUTiLX9bAlEtK
 QGRICP74bb97RkfFTnK9D1Y0prhyh8gnNsircca6jbu+P0wYTkElSckyekwuDvUs
 g/YbnNdlHRxsO4dPP4lqlRux0YUVmhcfqAoJv5Ld5KY7v78S89nkpR1WKnlGkV6U
 2uO0HMmdZBheAvayBcfL
 -----END CERTIFICATE-----
 -----BEGIN DH PARAMETERS-----
 MIGHAoGBAKwwFBBNL7Vml7Fwl5U3P8XN8P3PSDnvlhpVRNm9aIiBXV9CsgBw8EMV
 2eASd0S38h5gJt/by9vCBMRtaDlKHnYt0J33Vu7r7RcriXBWlhaSyl2ljZcLYkRH
 [...]

Nach jedem Wechsel des Serverzertifikats müssen die Parameter neu eingetragen werden.

Setzt man einen Apache >= 2.4.8 mit openssl >= 1.0.2 ein, kann die oben erzeugten Parameter auch in eine eigene Datei auslagern und  separat konfigurieren (Information von https://weakdh.org/sysadmin.html, nicht selbst getestet):

SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"

Weitere Sicherheitsparameter

Für zusätzliche Sicherheit können noch die folgenden Parameter gesetzt werden. Insbesondere erhält man damit einen erhöhten Schutz gegen Frame-Einbettungs-Angriffe und einige Formen von XSS-Angriffen.

Strict-Transport-Security ist eine Anweisung an Web-Browser, bis zum Ablauf von max-age mit dieser Webseite ausschließlich über https zu kommunizieren, selbst wenn der Nutzer eine http-URL verwendet oder http-Ressourcen von der Seite nachgeladen werden sollen. Durch diesen Header werden sogenannte SSL-Stripping-Angriffe abgewehrt.

Für Webseiten, die auch unverschlüsselt erreichbar sein sollen, ist diese Option also nicht geeignet.

 Header always set Strict-Transport-Security "max-age=15768000"
 Header always set X-Frame-Options SAMEORIGIN
 Header always set X-XSS-Protection "1; mode=block"
 Header always set X-Content-Type-Options nosniff

OCSP-Stapling

Ebenfalls zu empfehlen ist die Verwendung von OCSP-Stapling, mit dem Sie die Ladezeiten Ihrer Seite etwas reduzieren und Ihren Nutzern mehr Anonymität bieten können. Für Erläuterungen und Konfigurationshinweise lesen Sie den separaten Artikel: Mehr Privacy für den Nutzer: OCSP-Stapling

Fazit

Befassen Sie sich regelmäßig mit der TLS-Konfiguration Ihrer Server, und testen Sie diese mit verfügbaren Test-Tools. Tun Sie dies nicht, riskieren Sie, dass die Verbindungen zu Ihrem Server nicht mehr sicher sind, und sich Nutzer über Warn- oder Fehlermeldungen beschweren.

(jbr, 04.06.2015)

FREAK-Attack: Konfiguration von TLS-Servern prüfen

Am 3. März 2015 wurde ein neuer Angriff auf verschiedene TLS-Implementierungen wie Safari und openssl bekannt, der wieder einmal deutlich macht, wie wichtig eine korrekte Konfiguration von TLS-Servern ist:

https://www.smacktls.com/#freak

http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html

Ein aktiver Man-In-The-Middle kann unter bestimmten Umständen einen Client dazu bringen, alte und vollkommen unsichere SSL-Algorithmen zu akzeptieren. Dadurch kann die Verbindung vom Angreifer sehr leicht entschlüsselt werden. Der Angriff kann nur durchgeführt werden, wenn die folgenden beiden Bedingungen zusammen erfüllt sind:

  • Der Client verwendet eine verwundbare TLS-Software
  • Der Server erlaubt veraltete Cipher Suites

Die FREAK-Attacke kann also, wie zahlreiche anderen Angriffe auf verschlüsselte Verbindungen in der letzten Zeit, von jedem Administrator eines TLS-Servers nur durch Konfigurationseinstellungen abgewehrt werden.

Wir empfehlen dringend, regelmäßig die Konfigurationseinstellungen Ihrer TLS-Server zu überprüfen und beispielsweise mit den Anleitungen von BetterCrypto.org  abzugleichen. Externe Werkzeuge wie der Test von SSL Labs können diese Arbeit deutlich erleichtern.

Bitte beachten Sie bei der Nutzung von externen Diensten, dass Sie damit Daten über Ihre Server an Dritte weitergeben.

(jbr, 04.03.2015)