Bundesamt für Sicherheit in der Informationstechnik

M 5.177 Serverseitige Verwendung von SSL/TLS

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Transport Layer Security (TLS) ist eine Weiterentwicklung von Secure Sockets Layer (SSL) und wird dazu verwendet, Informationen während der Übertragung in Netzen, in der Regel zwischen Serverdiensten und Clients oder zwischen Serverdiensten untereinander kryptographisch abzusichern. Konfigurationshinweise, wie SSL/TLS auf Clients verwendet werden sollte, und allgemeine Informationen zur Funktionsweise von SSL/TLS sind in M 5.66 Clientseitige Verwendung von SSL/TLS zu finden. Clients können die Verschlüsselung über SSL/TLS nur dann nutzen, wenn diese von den Serverdiensten unterstützt wird. SSL/TLS kann dazu eingesetzt werden, Informationen aus der Anwendungsschicht ( z. B. HTTP , LDAP , POP3 , IMAP und SMTP ) verschlüsselt über TCP/IP zu übertragen. Überdies können mittels SSL/TLS auch sichere VPNs (Virtuelle Private Netze) aufgebaut werden. Mit OpenVPN, einer unter der GNU GPL (General Public License) frei verfügbaren Software, können VPNs mittels SSL/TLS verschlüsselte Verbindungen realisiert werden. Vertiefende Informationen zu VPNs sind in B 4.4 VPN zu finden.

In der Regel ist es bei vielen Serverdiensten nur ein geringer Mehraufwand, diese so zu konfigurieren, dass eine SSL/TLS-Verschlüsselung unterstützt wird, oder so, dass diese für einen Informationsaustausch ausschließlich genutzt wird. Daher ist für alle Serverdienste zu prüfen, ob mit vertretbarem Aufwand eine Verschlüsselung über SSL/TLS möglich und praktikabel ist. Ist dies mit vertretbarem Aufwand möglich, sollte die SSL/TLS-Verschlüsselung aktiviert werden. Generell sollte der interne und externe Nachrichtenstrom von und zu LDAP -, E-Mail- und Webservern mit SSL/TLS verschlüsselt werden.

Auswahl einer vertrauenswürdigen Zertifizierungsstelle

Zu Beginn eines neuen mit SSL/TLS abgesicherten Kommunikationsaufbaus findet ein sogenannter Handshake zwischen Client und Server statt. Hierbei verständigen sich Client und Server über die kryptographischen Algorithmen, die für Schlüsselaustausch, Verschlüsselung und Integritätssicherung eingesetzt werden. Außerdem einigen sich Client und Server über die SSL-Version, die verwendet wird. Zusätzlich dazu sendet der Server sein X.509-Zertifikat an den Client. Optional kann der Server auch so konfiguriert werden, dass auch der Client aufgefordert wird, dem Server sein X.509-Zertifikat zu übermitteln.

Die Identität der Kommunikationspartner wird hierbei über diese Zertifikate geprüft. X.509-Zertifikate enthalten die öffentlichen Schlüssel sowie eine Bestätigung einer weiteren Instanz, der Zertifizierungsstelle oder auch Trustcenter oder Certificate Authority (CA) genannt, über die korrekte Zuordnung des öffentlichen Schlüssels zu dessen "Besitzer". Der Wert eines Zertifikates hängt davon ab, welche Felder des X.509-Zertifikats von der Zertifizierungsstelle geprüft werden, bevor das Zertifikat ausgestellt wird, und wie vertrauenswürdig die Zertifizierungsstelle selbst ist. Daher spielt die Auswahl einer vertrauenswürdigen Zertifizierungsstelle eine wichtige Rolle.

Aufgrund der Vielzahl von Zertifizierungsstellen auf dem Markt sollte eine Institution die Zertifizierungsstelle sorgfältig auswählen. Es ist ratsam, die für den späteren Betrieb wesentlichen Auswahlkriterien im Vorfeld festzulegen. Zu diesen können beispielsweise gehören:

  • ob das Root-Zertifikat schon in CA-Listen der Clients, wie dem Browser, enthalten ist,
  • wo sich Sitz und Rechtsstand der Zertifizierungsstelle befinden, und auch wo der Sitz des technischen Betriebs sich befindet,
  • was die geschäftliche Ausrichtung der Zertifizierungsstelle ist (Ist CA-Betrieb ein zentrales Geschäftsfeld?), was die angebotenen CA-Dienste umfassen (z. B. OSCP, CRL),
  • welches Sicherheitsniveau die Zertifizierungsstelle nachweisen kann,
  • wie gut Umfang und Qualität des technischen Supports sind,
  • wie hoch die Zertifikatskosten sind.

Grundsätzlich sollten die Kosten eines Zertifikats jedoch keinesfalls das allein ausschlaggebende Kriterium darstellen. Wird der angebotene Serverdienst von einem beschränkten Benutzerkreis verwendet, z. B. nur innerhalb eines LAN s, kann ein Zertifikat auch ohne die Beteiligung einer Zertifizierungsstelle selbst erstellt und signiert und auf alle Clients eingespielt werden, auf denen der Serverdienst genutzt werden soll,

Extended Validation Zertifikate

Um Angriffe mit gefälschten Webseiten zu erschweren und der Problematik entgegen zu wirken, dass diverse Zertifizierungsstellen SSL/TLS-Anträge nicht immer zuverlässig prüfen, wurden Extended Validation Zertifikate zum Umgang mit Zertifikaten mit höheren Sicherheitsanforderungen eingeführt. Diese sollen verhindern, dass, wenn ein Zertifikat ausgestellt wird, eine CA nur den Domainnamen prüft. Darüber hinaus soll die CA außerdem noch eindeutig nachvollziehen, von wem die betreffende Domain registriert wurde. Im Unterschied zu den normalen X.509 SSL/TLS-Zertifikaten wird bei diesen erweiterten Zertifikaten (Extended Validation SSL-Zertifikate, EV-SSL) die Identität des Antragstellers ausführlicher überprüft. Hierbei verpflichten sich die beteiligten Zertifizierungsstellen und Browser-Hersteller, die "Guidelines for the Issuance and Management of Extended Validation Certificates" des CA/Browser Forums einzuhalten. Danach sind unter anderem folgende Kriterien vom Antragsteller zu erfüllen:

  • Identitätsnachweis und Adresse des Antragstellers,
  • Nachweis, dass der Antragsteller alleiniger Eigentümer der Domain ist,
  • Bestätigung, dass antragstellende Person überhaupt berechtigt ist, den Antrag zu stellen und
  • Hauptkontaktperson.

Zusätzlich darf der Antragsteller oder die antragstellende Person auf keiner Liste mit verbotenen Organisationen oder Personen stehen. Außerdem darf das Land, in dem sich der Sitz oder der Rechtsstand des Antragstellers befindet, weder Handelsembargos oder irgendwelchen anderen Sanktionen ausgesetzt sein, die durch dasjenige Land verhängt wurden, dessen Gesetzgebung die Zertifizierungsstelle unterliegt.

Für die Anwender sind EV-SSL-Zertifikate daran zu erkennen, dass in den unterstützten Browsern bestimmte Bereiche, wie die URL im Adressfeld oder das von vielen Browsern verwendete Vorhängeschlosssymbol, das eine verschlüsselte Seite kennzeichnet, grün hinterlegt ist. Je nach Konfiguration des Sicherheitsgateways (Firewall), hinter dem die Benutzer auf Webseiten mit EV-SSL-Zertifikaten zugreifen, kann es aber vorkommen, dass diese Markierungen in den Browsern der Clients nicht angezeigt werden. Wird beispielsweise der Nachrichtenfluss zwischen Client und Webserver von einem Proxy ent- und wieder neu verschlüsselt, wird im Browser lediglich das SSL/TLS-Zertifikat des Sicherheitsgateways angezeigt.

Neben den höheren finanziellen Kosten, die für die Ausstellung eines EV-SSL-Zertifikats entstehen können, dauert die Antragstellung in der Regel auch länger, da zusätzliche Informationen von der Zertifizierungsstelle überprüft werden. Wenn es möglich ist, wird empfohlen, diesen zusätzlichen Aufwand in Kauf zu nehmen. Insbesondere in Bereichen, in denen Informationen mit höherem Schutzbedarf bezüglich Vertraulichkeit und Integrität übertragen werden, sollten EV-SSL-Zertifikate bevorzugt eingesetzt werden.

Common Name Eintrag

Browser zeigen immer eine Sicherheitswarnung an, wenn der im Zertifikat einer Webseite eingetragene Common Name (Allgemeiner Name) nicht mit dem vollständigen DNS-Name (Fully Qualified Domain Name) übereinstimmt, über den der Server im Web erreichbar ist. Daher sollte sichergestellt sein, dass der Common Name zu der URL passt, die tatsächlich verwendet wird, um mit dem Server zu kommunizieren. Wenn es möglich ist, sollten Wildcard-Zertifikate ( z. B. *.example.de) vermieden werden. Diese werden häufig eingesetzt, um mit einem einzelnen Zertifikat mehrere Subdomains abzusichern.

Vollständige Zertifikatskette

Da für die Prüfung der hierarchischen Zertifikatskette durch den Browser auch alle Zwischen-Zertifikate benötigt werden, reicht das SSL-Zertifikat des Servers alleine nicht aus. Deshalb sollte der Server so konfiguriert werden, dass beim Verbindungsaufbau alle erforderlichen Zertifikate an den Client gesendet werden. Dazu sollte die Zertifikatskette im Webserver entsprechend hinterlegt werden.

Zu beachten ist außerdem, dass neben Zertifikate, die fehlen, auch abgelaufene oder gesperrte Zertifikate die Prüfung der Zertifikatskette fehlschlagen lassen. Nur wenn alle Zertifikate gültig sind und beim Verbindungsaufbau übertragen wurden, kann die Zertifikatskette erfolgreich geprüft werden.

Auswahl einer SSL/TLS Protokollversion

Derzeit existieren fünf SSL/TLS-Protokollversionen: SSL v2, SSL v3, TLS v1.0, TLS v1.1 und TLS v1.2. SSL v1 wurde nicht veröffentlicht. Um eine sichere Verbindung zwischen Client und Server zu gewährleisten, sollte TLS 1.2 verwendet werden. TLS 1.1 bietet ausreichende Sicherheit, aber im Vergleich zu TLS 1.2 weist es jedoch einige Schwächen auf, z. B. sind in TLS 1.1 noch Cipher-Suites vorhanden, die auf IDEA und DES basieren, in TLS 1.2 nicht mehr. TLS 1.0 kann in bestehenden Anwendungen übergangsweise weiter eingesetzt werden, falls eine sofortige Migration zu TLS 1.1 oder vorzugsweise TLS 1.2 nicht möglich ist und geeignete Maßnahmen gegen Chosen-Plaintext-Angriffe ( z. B. BEAST) auf die CBC-Implementierung getroffen werden. Generell sollte jedoch eine Migration zu TLS 1.2 schnellstmöglich erfolgen.SSL v2 und SSL v3 dürfen nicht mehr eingesetzt werden.

Sichere Cipher-Suites

SSL/TLS nutzt Cipher-Suites, die bestimmen, wie sicher eine HTTPS -Verbindung ist. Jede Suite besteht aus spezifischen Modulen. Wenn ein bestimmtes Modul als unsicher oder schwach eingestuft wird, kann durch die Veränderung der Cipher Suite zu einem sichereren Modul gewechselt werden.

Da die Verwendung schwacher Cipher Suites clientseitig erzwungen werden kann, ist es erforderlich, serverseitig nur solche anzubieten, die Authentisierung und Verschlüsselung mit einer ausreichenden Stärke einsetzen. Darüber hinaus sollten die verwendeten Cipher-Suites Perfect Forward Secrecy (PFS) unterstützen (siehe TR-02102-2).

Weitere Hinweise zu kryptografischen Algorithmen und Schlüssellängen sind in der Technischen Richtlinie des BSI Kryptographische Verfahren: Empfehlungen und Schlüssellängen - Teil 2 Verwendung von TLS (TR-02102-2) und M 2.164 Auswahl eines geeigneten kryptographischen Verfahrens enthalten.

Session Renegotiation/TLS-Kompression

Mittels der sogenannten Session Renegotiation (Session-Neuverhandlung) können sowohl Client als auch Server die Parameter einer bestehenden HTTPS-Sitzung neu aushandeln. Aufgrund eines Fehlers in der Spezifikation des TLS-Protokolls (RFC 5246) ist es einem Man-in-the-Middle-Angreifer möglich, die Session Renegotiation zu missbrauchen, um beliebige Inhalte in eine existierende HTTPS-Sitzung einzufügen. Mittlerweile wurde das TLS-Protokoll erweitert (RFC 5746) und dieser Designfehler behoben. Generell sollte überlegt werden, ob serverseitig die Session Renegotiation erforderlich ist. Ist dies der Fall, dann sollte diese sicher konfiguriert werden, also auf Basis des RFC 5746. Eine Renegotiation, die durch den Client initiiert wird, sollte vom Server abgelehnt werden.

Darüber hinaus sollte die TLS-Kompression deaktiviert werden.

Webserverspezifische Aspekte

Generell wird empfohlen, die auf Webservern zur Verfügung gestellten Inhalte bei der Übertragung vom Server zum Client und umgekehrt mittels SSL/TLS zu schützen.

Wenn möglich, sollte darauf verzichtet werden, Webseiten mit gemischten Inhalten anzubieten. Als Webseite mit gemischtem Inhalt wird eine Seite bezeichnet, die zwar Verschlüsselung nutzt, dabei aber auch unverschlüsselte Inhalte ( z. B. JavaScript-, CSS-Dateien oder Bilder) einbindet. Ein Man-in-the-Middle-Angreifer kann die Übertragung einer einzelnen unverschlüsselten Datei ausnutzen, um eine HTTPS-Session zu übernehmen. Da Webseiten mit gemischten Inhalten zudem üblicherweise Browser-Warnungen erzeugen, wird dadurch die Benutzerfreundlichkeit verschlechtert.

HTTP Strict Transport Security (HSTS) ist eine weitere Methode, die gegen bekannte Schwächen von SSL schützt. Damit wird erschwert, dass ein Besucher durch einen Angriff oder serverseitige Konfigurationsprobleme von einer gesicherten auf eine ungesicherte Seite umgeleitet wird. Befindet sich ein Angreifer beispielsweise in demselben WLAN wie das Opfer, könnte er so die Session Cookies mitlesen und die HTTPS-Session übernehmen. Um HSTS zu aktivieren, muss der HSTS-Header auf dem Server konfiguriert werden.

Schutz des privaten Serverschlüssels

Ein besonders wichtiger Sicherheitsaspekt beim Einsatz von SSL/TLS ist der Schutz des privaten Serverschlüssels. Daher ist es ratsam, den Server so zu konfigurieren, dass der private Serverschlüssel beim Start des Servers durch Passworteingabe freigegeben werden muss. Besteht der Verdacht, dass der private Schlüssel kompromittiert wurde, so muss das zugrunde liegende Zertifikat widerrufen werden. Weitere Hinweise zum Umgang mit kryptografischen Schlüsseln sind in M 2.46 Geeignetes Schlüsselmanagement zu finden.

Validierung

Die Auswirkungen von Konfigurationsänderungen auf dem Server lassen sich nicht immer mit Bestimmtheit vorhersagen. Auch Software Updates können mitunter zu überraschenden Änderungen führen. Es wird daher empfohlen, die SSL/TLS Konfiguration vor der Freigabe zur Nutzung auf Fehler zu prüfen und den Status in periodischen Abständen (regelmäßig) zu validieren.

Prüffragen:

  • Bieten alle Serverdienste, bei denen es sinnvoll und möglich ist, die Informationen verschlüsselt über SSL/TLS an?

  • Wurde sorgfältig eine Zertifizierungsstelle ausgewählt?

  • Wurde der Common Name sorgfältig ausgewählt?

  • Wurde die vollständige Zertifikatskette im Webserver hinterlegt?

  • Unterstützen die eingesetzten Server-Produkte eine sichere Version von SSL/TLS?

  • Ist sichergestellt, dass die eingesetzten Server kryptographische Algorithmen und Schlüssellängen verwenden, die dem Stand der Technik und den Sicherheitsanforderungen der Institution entsprechen?

  • Wurde die Session Renegotiation deaktiviert oder erfolgt diese auf Basis des RFC 5746? Wurde die clientseitige Renegotiation deaktiviert?

  • Wird bei Webseiten auf gemischten Inhalten verzichtet?

  • Wurde die TLS-Kompression deaktiviert?

  • Wird der private Serverschlüssel durch ein Passwort geschützt?

  • Wurde die SSL/TLS Konfiguration vor der Freigabe zur Nutzung auf Fehler geprüft und wird der Status in periodischen Abständen validiert?

Stand: 14. EL Stand 2014

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK