SAP NetWeaver Cipher Suite Konfiguration: Empfehlungen

(Last Updated On: 20. Oktober 2017)

Wenn Sie meinen Post über unsichere und geknackte Cipher Suites / Verschlüsselungs-Bibliotheken gelesen haben, ist Ihnen die Problematik von der Verwendung unsicherer Verschlüsselungsbilbiotheken bewusst. Da dieser Blog sich insbesondere auf die Thematiken SAP und IT Security spezialisiert hat, kamen darauf hin einige Anfragen bezüglich der Konfiguration von SAP Systemen herein. In diesem Beitrag widmen wir uns daher der Security Konfiguration von SAP NetWeaver ABAP Systemen. Hierbei gehe ich aber auch auf die Thematiken zur Abwärtskompatibilität ein, um auch den Administration von Systemen im Legacy-Umfeld einen Anhaltspunkt zu geben.

Was ist denn die aktuelle Empfehlung der SAP?

Das ist die erste Frage, die bei Kunden auf taucht, wenn es um die Cipher-Konfiguration von SAP Systemen geht: Welche Konfiguration empfiehlt denn aktuell die SAP? Und grundsätzlich muss man dazu sagen, dass es mehrere Quellen gibt, die sich uneins sind.

  • SAP Note 510007 berücksichtigt zwar bereits die aktuellen Parameter der aktuellen Version der Common Crypto Lib, gibt meiner Meinung nach jedoch keine repräsentativen Empfehlungen für Unternehmen ab. Grund hierfür ist, dass diese Note bewusst sehr vorsichtig gewählte Parameter wählt, um die Abwärtskomaptibilität mit Legacy-Systemen zu gewährleisten.
  • Die wesentlich Pontentere SAP Note in diesem Bereich ist meiner Meinung nach SAP Note 2359837. Diese lässt jedoch aktuell noch TLS 1.0 und TLS 1.1 aktiviert. Warum, werden wir weiter unten erörtern. Die wenigsten SAP-Kunden stoßen jedoch auf diesen SAP-Hinweis in diesem Zusammenhang, weil diese in ihrer Hauptthematik nicht das eigentliche Problem der sicheren Cipher-Konfiguration adressiert, sondern eigentlich zum Troubleshooting von Problemen mit dem SAP Support Hub im Solution Manager 7.2 gedacht ist. Hier bringt der Hersteller jedoch eine aus meiner Sicht sehr angebrachte Konfigurationsempfehlung für den SAP Solution Manager 7.2 an, die meiner Meinung nach für die meisten SAP NetWeaver ABAP Systeme Anwendung finden sollte.

Warum empfiehlt SAP im Haupt-Hinweis nicht die stärkste Cipher-Konfiguration?

Um diese Frage zu beantworten, müssen wir uns selbst einige Gedanken machen.

Nicht alle Kunden verwenden bereits eine aktuelle Version der Common Crypto Lib

Um das volle Spektrum der Konfigurationsbibliotheken in einem SAP NetWeaver ABAP System zu erhalten, benötigen Sie die Common Crypto Lib > 8.4.48. Zur Installation der neuesten Version konsultieren Sie SAP Note 2390726. Erst ab dieser Version erhalten Sie den vollen Funktionsumfang, einschließlich der Unterstützung für Perfect Forward Secrecy (PFS) Cipher. Kunden sollten sich grundsätzlich angewöhnen, beim Patch Day die aktuelle Version der Common Crypto Lib mit einzuspielen. Ältere Systeme mit NetWeaver Kernel 7.0X, 7.1X oder 7.2X benötigen zusätzlich den Kernel Patch aus SAP Hinweis 1433874.

PFS-Cipher sind grundsätzlich empfehlenswert

Der Grundsatz der Perfect Forward Secrecy (PFS) bezeichnet die Tatsache, dass die Kompromittierung eines Schülssels es dem Angreifer nicht ermöglicht, den in der Vergangenheit aufgezeichneten TLS-Verkehr nachträglich zu entschlüsseln. Für das bessere Verständnis, die Verwendung von PFS-Ciphern schützt Sie gegen das folgende Szenario:

·        Ein Angreifer zeichnet mit einem Sniffer TLS-Verkehr zwischen einem Anwender/Entwickler und dem SAP Frontend System auf

·        Die symmetrischen Schlüssel, mit dem dieser TLS-Verkehr gesichert ist, sind wiederum mit einem asymmetrischen Schlüssel gesichert.

·        Diese asymmetrischen Schlüssel sind sogenannte long-term keys. Sie heißen so, weil sie für eine lange Zeit gültig sind.

·        Das bringt wiederum die Problematik mit sich, dass es bei der Kompromittierung dieses Schlüssels in der ferneren Zukunft (beispielsweise Offenlegung des Zertifikat-Passworts) gelingt, alle in der Vergangenheit abgesnifften Nachrichten nun rückwirkend entschlüsseln zu können.

Damit dieses Szenario nicht mehr möglich wird, bedienen sich PFS-Cipher-Suites dem Diffie-Hellmann-Verfahren. Hierbei bekommt der Long Term Key bei jeder neuen Sitzung neue Parameter und ist somit nicht mehr für die Entschlüsselung älterer Nachrichten geeignet.

Cipher mit 3DES

Wie bereits in dem weiter oben verlinkten Post erwähnt, sollte der 3DES-Cipher nicht mehr verwendet werden. Jedoch benötigten Clients unter Windows XP oder Windows Server 2003 häufig noch diesen Cipher. Daher gehen viele Webserver heutzutage dazu über, den Cipher 3DES_EDE_CBC zwar noch anzubieten, diesen jedoch am letzten Platz in der Prioritätsliste zu halten. Cloud-Anbieter wie SAP, Openstack, Amazon, Google und SalesForce gehen diesen Kurs jedoch aktuell schon nicht mehr mit. Hier wird 3DES meist rigoros deaktiviert, da unter Anderem das Betriebssystem Windows XP aus dem offiziellen Support des Betriebssystemherstellers Microsoft gefallen ist. Grundsätzlich empfehle ich Ihnen, 3DES-Cipher zu deaktivieren, wenn Sie ausschließen können, dass Business Partner oder Kunden noch mit einem der beiden anfälligen Betriebssysteme arbeiten.

Nicht jede Software oder jeder Business Partner ist schon TLS 1.2 fähig

Leider kann man einigen Kunden nicht grundsätzlich empfehlen, TLS 1.0 und TLS 1.1 gänzlich zu deatkivieren. Grund hierfür sind ältere TLS-Server oder Load Balancer, die entweder in der eigenen IT-Landschaft, oder in der Umgebung von Business Partnern und Kunden, noch verwendet werden. Grundsätzlich sprechen einige Argumente gegen die Unterstützung von TLS 1.0 und TLS 1.1. Denn für diese gibt es theoretisch Angriffsszenarien, etwa das 1/(n-1) TLS Record Splitting. Viele Cloud Anbieter deaktivieren TLS 1.0 und TLS 1.1 heutzutage aus diesen Gründen gänzlich. Während dies bei Client-Verbindungen über Webbrowser grundsätzlich problemlos abläuft, kann es Probleme geben, wenn diese Cloud Dienste etwa mit einem Server aus Ihrer eigenen IT-Landschaft sprechen müssen, und vor diesem ein Load Balancer geschalten ist, der schon einige Jahre auf dem Buckel hat. Eventuell bringt diese Lösung dann noch keinen TLS 1.2 Support mit. Dann haben Sie die Qual der Wahl: Entweder Sie lösen die veraltete Load Balancer Komponente ab, oder Sie arbeiten weiterhin mit TLS 1.0 und TLS 1.1.

Sobald sich heraus stellt, dass Sie oder Ihre Partner noch Komponenten im Haus haben, die kein TLS 1.2 unterstützen, müssen Sie zwangsläufig den TLS 1.1 und TLS 1.0 Support auch serverseitig aktiviert lassen. Es kann Ihnen unter Umständen sogar passieren, dass Sie TLS 1.1 oder TLS 1.0 alleinstehend aktivieren müssen, da der TLS 1.2 Handshake grundsätzlich nicht abwärtskompatibel ist. So kann es Ihnen passieren, dass Sie mit einem Business Partner unter aktivierter TLS 1.2-Verschlüsselung keine verschlüsselte Verbindung ausgehandelt bekommen, während der Handshake mit TLS 1.0 funktioniert. Webbrowser umgehen dieses Problem mit dem sogenannten Downgrade Dancing Verfahren. Dies führte jedoch in der Vergangenheit dazu, dass viele Webbrowser für die damalige Poodle-Sicherheitslücke anfällig waren. Ohne Downward Dancing wäre der Angriffsvektor hier wesentlich kleiner gewesen.

Blind Sending von SSL Zertifikaten auf Clientseite

Auf Clientseite kann es vorkommen, dass Sie aus Gründen der Abwärtskompatiblität zu älteren Load Balancern das sogenannte „Blind Sending“ von SSL Zertifikaten aktiviert müssen. Dieses Verfahren bietet grundsätzlich einen Angriffsvektor durch das Senden von deformierten TLS Handshake Nachrichten. Jedoch ist dieses Verfahren häufig bei Partnern notwendig, die nur mit TLS 1.0 Hände schütteln und die neueren Protokolle nicht verwenden.

Senden von SSLv2 Client Hello Paketen

Da unter Windows XP und Windows Server 2003 mit vorinstalliertem Internet Explorer 6 sowie mit Firefox 3.0 und JavaSE 6 und älter nur SSLv2 aktiviert ist, müssen Sie eventuell das Senden dieser Pakete ebenfalls aktivieren. Dies gilt jedoch nur, wenn Sie als TLS-Client mit einem TLS-Partner sprechen, der auf einem (ungepatchten) Windows XP bzw. Windows Server 2003 System sprechen wollen. Das sollten Sie sich zweimal überlegen.

Die aktuellen BitFlags der SAP NetWeaver ABAP Cipher Konfiguration

Die beiden Profilparameter

  • ssl/ciphersuites – Serverseite
    und
  • ssl/client_ciphersuites (Clientseite)

sind im Wesentlichen verantwortlich für die Konfiguration der verfügbaren Cipher Suites, die bei einer Verbindung mit einem TLS-Partner ausgehandelt werden können.

Allen Voran steht diesen Parametern häufig ein Zahlenwert. Dieser wird nach dem Bitflag-Prinzip zusammengebaut, das heißt die Dezimalzahl – umgeerechnet in das Binärsystem, bestimmt, welche der folgenden Bitwerte (entnommen aus SAP Note 510007) aktiviert werden.

ValueDescription
1„BC“– Option (allow SSL Version 2.0 CLIENT-HELLO / SSLv2Hello)
2„Best“– Option (activate highest available TLS protocol version)
4„NO_GAP“– Option (no gaps between TLS protocol versions; is forced to date)
16        Allow blind sending of a client certificate (5.5.5pl36+ and all CCL 8.4.xx)
32„Strict protocol version configuration“ option–do not automatically enable TLSv1.0
(recognized/supported only by CommonCryptoLib (CCL) 8.4.48 or higher)
64SSLv3
128TLSv1.0
256TLSv1.1  (only with CommonCryptoLib (CCL) 8.4.31 or higher)
512TLSv1.2  (only with CommonCryptoLib (CCL) 8.4.31 or higher)

Fazit: Empfehlenswerte Cipher Suite Konfiguration für SAP Systeme

Hinweis: Diese Empfehlung gilt nur frü Kunden, die CommonCryptoLib 8.4.48 oder neuer einsetzen.

Meine Empfehlung: Konfigurieren Sie zuerst Ihre Cipher Suites nach einem hohen Standard, das bedeutet:

  • Nur TLS 1.2 wird unterstützt
  • 3DES- und RC4-Cipher werden nicht mehr verwendet
  • Cipher mit CBC-Verfahren deaktiviert
  • Es werden bevorzugt Perfect Forward Secrecy (PFS)-Cipher eingesetzt
  • SSLv2 Client Hello Pakete werden nicht gesendet
  • Das Blind Sending von SSL Zertifikaten wird nicht erlaubt.
  • Aktivieren Sie das BitFlag 32 „Strict protocol version configuration“. Nur wenn Sie dieses BitFlag setzen, arbeitet das SAP System nicht mehr mit TLS 1.0 oder TLS 1.1. Lassen Sie dieses BitFlag auf 0, aktiviert das SAP System unter Umständen TLS 1.0 oder TLS 1.1, obwohl Sie die BitFlags 128 und 256 ausgeschaltet haben.

Demnach sollte bei Ihnen der erste Konfigurationsschritt sein

550:PFS:HIGH::EC_P256:EC_HIGH

Sollten Sie die Abwärtskomaptbilität Ihrer Lösung erhöhen wollen und müssen daher im Gegensatz zur oberen Konfiguration

  • TLS 1.1 und TLS 1.0 weiterhin anbieten, wollen aber bevorzugt immter mit TLS 1.2 arbeiten
  • 3DES-, CBC- und RC4-Cipher immer noch deaktivierten
  • SSLv2 Client Hello Pakete nicht senden
  • Blind Sending von SSL Zertifikaten deaktivieren

So lautet meine Empfehlung an Sie

902:PFS:HIGH::EC_P256:EC_HIGH

Bekommen Sie daraufhin immer noch Probleme auf der Clientseite, sollten Sie auf der Clientseite (ssl/client-ciphersuites), nicht jedoch auf der Serverseite (ssl/ciphersuites) zunächst das BitFlag 16 und somit das Blind Sending aktivieren

ssl/client_ciphersuites=918:PFS:HIGH::EC_P256:EC_HIGH

Wenn Sie zu guter letzt noch Probleme bekommen, weil Sie Partner mit installierter JavaSE 6 oder mit installiertem Windows XP / Windows Server 2003-Betriebssystem kommunizieren müssen, müssen Sie zusätzlich entweder client- und/oder server-seitig noch das BitFlag 1 und somit das Senden von SSLv2 Client Hello Paketen aktivieren

ssl/ciphersuites=903:PFS:HIGH::EC_P256:EC_HIGH

ssl/client_ciphersuites=919:PFS:HIGH::EC_P256:EC_HIGH

Prüfen, welche Cipher Suiten aktiviert sind.

Wenn Sie prüfen wollen, welche Cipher Suiten mit einer bestimmten ciphersuites-Konfiguration überhaupt angeboten werden, können sie mit neueren Versionen der CommonCryptoLib den Kommandozeilenbefehl sapgenpse tlsinfo [optionen] <TLS Konfiguration> nutzen, also beispielsweise

sapgenpse tlsinfo 902:PFS:HIGH::EC_P256:EC_HIGH

Wenn Ihnen ein Cipher aus der Liste nicht gefällt, können Sie diesen zusätzlich entfernen, indem Sie über den Befehl

sapgenpse tlsinfo -H

den sogenannten Cipher Suite Configuration String des Ciphers heraussuchen. Die Cipher Suite TLS_RSA_WITH_AES256_CBC_SHA hat besispielsweise den String  eAES256_CBC. Wenn Sie die Konfiguration so umgestalten

902:PFS:HIGH::EC_P256:EC_HIGH:!eAES256_CBC

wir dieser Cipher explizit entfernt.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

Das könnte Dich auch interessieren...

Kommentar verfassen