Übersicht über TLS-Beendigung und End-to-End-TLS mit Application Gateway

Transport Layer Security (TLS), zuvor bekannt als Secure Sockets Layer (SSL), ist die standardmäßige Sicherheitstechnologie, mit der eine verschlüsselte Verbindung zwischen einem Webserver und einem Browser hergestellt wird. Über diese Verbindung wird sichergestellt, dass alle Daten privat und verschlüsselt zwischen dem Webserver und dem Browser übertragen werden. Application Gateway unterstützt sowohl die TLS-Terminierung am Gateway als auch die End-to-End-TLS-Verschlüsselung.

TLS-Terminierung

Application Gateway unterstützt die TLS-Beendigung am Gateway, wonach der Datenverkehr in der Regel unverschlüsselt zu den Back-End-Servern gelangt. Die TLS-Terminierung am Application Gateway bietet zahlreiche Vorteile:

• Verbesserte Leistung: Der größte Leistungsabfall bei der TLS-Entschlüsselung entsteht beim anfänglichen Handshake. Der Entschlüsselungsserver verbessert die Leistung durch das Zwischenspeichern von TLS-Sitzungs-IDs und das Verwalten von TLS-Sitzungstickets. Wenn dieser Vorgang am Application Gateway erfolgt, können alle Anforderungen vom gleichen Client die zwischengespeicherten Werte verwenden. Wenn dies auf den Backend-Servern geschieht, muss sich der Client jedes Mal neu authentifizieren, wenn seine Anforderungen an einen anderen Server gerichtet sind. Sie können dieses Problem durch die Verwendung von TLS-Tickets beheben, diese werden jedoch nicht von allen Clients unterstützt und können das Konfigurieren und Verwalten erschweren.
• Bessere Auslastung der Back-End-Server: Die SSL/TLS-Verarbeitung bringt eine hohe CPU-Intensität mit sich, die sich mit steigenden Schlüsselgrößen weiter verstärkt. Wenn Sie die Back-End-Server von dieser Aufgabe befreien, können diese für ihren effizientesten Zweck eingesetzt werden: das Bereitstellen von Inhalten.
• Intelligentes Routing: Durch die Entschlüsselung des Datenverkehrs erhält das Anwendungsgateway Zugriff auf Anforderungsinhalte wie Header, URI etc. und kann diese Daten dann zum Weiterleiten von Anforderungen verwenden.
• Zertifikatverwaltung: Zertifikate müssen nicht für alle Back-End-Server, sondern nur für das Anwendungsgateway erworben und installiert werden. Das spart Zeit und Geld.

Zum Konfigurieren der TLS-Terminierung muss dem Listener ein TLS/SSL-Zertifikat hinzugefügt werden. Dadurch kann der Application Gateway eingehenden Datenverkehr entschlüsseln und den Antwortdatenverkehr an den Client verschlüsseln. Das Zertifikat für die Application Gateway muss im PFX-Format (Personal Information Exchange) vorliegen, das sowohl die privaten als auch die öffentlichen Schlüssel enthält. Die unterstützten PFX-Algorithmen sind unter PFXImportCertStore-Funktion aufgeführt.

Zum Hersteller der TLS-Verbindung müssen Sie sicherstellen, dass das TLS/SSL-Zertifikat die folgenden Bedingungen erfüllt:

• Das aktuelle Datum und die aktuelle Uhrzeit entsprechen den Datumsbereichen „Gültig ab“ und „Gültig bis“ im Zertifikat.
• Der allgemeine Name (Common Name, CN) des Zertifikats entspricht dem Hostheader in der Anforderung. Wenn der Client eine Anforderung beispielsweise an https://www.contoso.com/ richtet, muss der CN www.contoso.com lauten.

Wenn Fehler mit dem gemeinsamen Back-End-Zertifikatnamen (Common Name, CN) auftreten, lesen Sie unsere Anleitung zur Problembehandlung.

Unterstützte Zertifikate für die TLS-Beendigung

Das Anwendungsgateway unterstützt die folgenden Arten von Zertifikaten:

• ZS (Zertifizierungsstellen)-Zertifikat: Ein ZS-Zertifikat ist ein digitales Zertifikat, das von einer Zertifizierungsstelle (Certificate Authority, ZS) ausgestellt wurde.
• EV (Extended Validation)-Zertifikat: Ein EV-Zertifikat ist ein Zertifikat, das den Branchen-Standardzertifikatrichtlinien entspricht. Die Locator-Leiste des Browsers wird dadurch grün, und auch der Firmennamen wird veröffentlicht.
• Platzhalterzertifikat: Dieses Zertifikat unterstützt eine beliebige Anzahl von untergeordneten Domänen basierend auf *.site.com., wobei Ihre Subdomäne das * ersetzen würde. Es unterstützt jedoch nicht site.com. Falls Ihre Benutzer*innen auf Ihre Website zugreifen, ohne die führende Zeichenfolge „www“ einzugeben, wird das Platzhalterzertifikat diese Eingabe nicht berücksichtigen.
• Selbstsignierte Zertifikate: Clientbrowser vertrauen diesen Zertifikaten nicht und warnen den Benutzer, dass das virtuelle Zertifikat des Diensts keiner Vertrauenskette angehört. Selbstsignierte Zertifikate eignen sich gut für Tests oder Umgebungen, in denen Administratoren die Clients kontrollieren und Sicherheitswarnungen des Browsers sicher umgehen können. Produktionsworkloads sollten niemals selbstsignierte Zertifikate verwenden.

Weitere Informationen finden Sie im Artikel zum Konfigurieren der TLS-Terminierung mit Application Gateway.

Größe des Zertifikats

Lesen Sie den Abschnitt Application Gateway-Grenzwerte durch, um die maximal unterstützte Größe von TLS/SSL-Zertifikaten zu erfahren.

End-to-End-TLS-Verschlüsselung

Möglicherweise möchten Sie keine unverschlüsselte Kommunikation mit den Back-End-Servern verwenden. Möglicherweise sollen Sicherheits- oder Complianceanforderungen erfüllt werden, oder in der Anwendung wird nur eine sichere Verbindung akzeptiert. Im Hinblick auf diese Anforderungen unterstützt Azure Application Gateway die End-to-End-TLS-Verschlüsselung.

End-to-End-TLS ermöglicht Ihnen die Verschlüsselung und sichere Übertragung vertraulicher Daten an das Back-End bei Verwendung der Lastenausgleichsfunktionen von Schicht 7 von Application Gateway. Zu diesen Funktionen zählen unter anderem cookiebasierte Sitzungsaffinität, URL-basiertes Routing, Unterstützung von standortbasiertem Routing und die Möglichkeit zum Umschreiben oder Einfügen von Headern vom Typ „X-Forwarded-*“.

Bei der Konfiguration mit dem End-to-End-TLS-Kommunikationsmodus beendet Application Gateway die TLS-Sitzungen am Gateway und entschlüsselt den Benutzerdatenverkehr. Anschließend werden die konfigurierten Regeln angewendet, um eine geeignete Instanz des Back-End-Pools auszuwählen, an die der Datenverkehr geroutet werden soll. Application Gateway initiiert anschließend eine neue TLS-Verbindung mit dem Back-End-Server und verschlüsselt die Daten mit dem öffentlichen Schlüssel des Back-End-Serverzertifikats erneut, bevor die Anforderung an das Back-End übertragen wird. Antworten vom Webserver durchlaufen denselben Prozess zurück an den Endbenutzer. End-to-End-TLS wird aktiviert, indem Sie die Protokolleinstellung in der Back-End-HTTP-Einstellung auf „HTTPS“ festlegen. Diese Einstellung wird anschließend auf einen Back-End-Pool angewandt.

In Anwendungsgateway v1-SKU-Gateways wendet die TLS-Richtlinie die TLS-Version nur auf Frontend-Datenverkehr und die definierten Verschlüsselungsverfahren auf Frontend- und Back-End-Ziele an. In Anwendungsgateway v2-SKU-Gateways gilt TLS-Richtlinie nur für Front-End-Datenverkehr, Back-End-TLS-Verbindungen werden immer über TLS 1.0 zu TLS 1.2-Versionen ausgehandelt.

Application Gateway kommuniziert nur mit den Back-End-Servern, deren Zertifikat in der Zulassungsliste von Application Gateway enthalten ist oder deren Zertifikate von bekannten Zertifizierungsstellen signiert wurden und deren CN mit dem Hostnamen in den HTTP-Einstellungen auf dem Back-End übereinstimmt. Dazu zählen vertrauenswürdige Azure-Dienste wie Azure App Service oder Azure App Service-Web-Apps und Azure API Management.

Wenn die Zertifikate der Mitglieder im Back-End-Pool nicht von bekannten Zertifizierungsstellen signiert wurden, muss jede Instanz im Back-End-Pool mit aktiviertem End-to-End-TLS mit einem Zertifikat konfiguriert werden, um die sichere Kommunikation zu ermöglichen. Durch das Hinzufügen des Zertifikats wird sichergestellt, dass das Anwendungsgateway nur mit bekannten Back-End-Instanzen kommuniziert. Außerdem wird auf diese Weise die End-to-End-Kommunikation gesichert.

In diesem Beispiel werden Anforderungen, für die TLS 1.2 verwendet wird, an Back-End-Server in Pool1 geleitet, indem End-to-End-TLS genutzt wird.

End-to-End-TLS und Zulassungslisten für Zertifikate

Application Gateway kommuniziert nur mit den Back-End-Servern, deren Zertifikat in der Zulassungsliste von Application Gateway enthalten ist oder deren Zertifikate von bekannten Zertifizierungsstellen signiert wurden und deren CN mit dem Hostnamen in den HTTP-Einstellungen auf dem Back-End übereinstimmt. In Bezug auf die verwendete Version von Application Gateway gibt es einige Unterschiede beim Prozess zum Einrichten von End-to-End-TLS. Im folgenden Abschnitt werden die Versionen einzeln erläutert.

End-to-End-TLS mit der v1-SKU

Zum Aktivieren von End-to-End-TLS mit den Back-End-Servern und zum Weiterleiten von Anforderungen durch Application Gateway an die Back-End-Server müssen die Integritätstests erfolgreich durchgeführt werden und eine fehlerfreie Antwort zurückgeben.

Bei HTTPS-Integritätstests verwendet die Application Gateway v1-SKU eine genaue Entsprechung des Authentifizierungszertifikats (öffentlicher Schlüssel des Back-End-Serverzertifikats anstelle des Stammzertifikats), das in die HTTP-Einstellungen hochgeladen werden soll.

Es sind dann nur Verbindungen mit bekannten und zulässigen Back-Ends gestattet. Die übrigen Back-End-Server werden in den Integritätstests als fehlerhaft eingestuft. Selbstsignierte Zertifikate dienen nur zu Testzwecken und werden für Produktionsworkloads nicht empfohlen. Solche Zertifikate müssen, wie unter den obigen Schritten beschrieben, in der Zulassungsliste des Anwendungsgateways enthalten sein, damit sie verwendet werden können.

End-to-End-TLS mit der v2-SKU

Authentifizierungszertifikate wurden als veraltet markiert und durch Trusted Root-Zertifikate in der v2-SKU von Application Gateway ersetzt. Sie funktionieren auf ähnliche Weise wie Authentifizierungszertifikate mit einigen wichtigen Unterschieden:

• Zertifikate, die von bekannten Zertifizierungsstellen, deren CN dem Hostnamen in den HTTP-Einstellungen des Back-Ends entspricht, zertifiziert wurden, erfordern keinen zusätzlichen Schritt, damit End-to-End-TLS funktioniert.

  Wenn beispielsweise die Back-End-Zertifikate von einer bekannten Zertifizierungsstelle ausgestellt wurden, der CN „contoso.com“ lautet und in der HTTP-Einstellung des Back-Ends das Feld „Host“ ebenfalls auf „contoso.com“ festgelegt wurde, sind keine weiteren Schritte erforderlich. Sie können das Protokoll in der HTTP-Einstellung des Back-Ends auf HTTPS festlegen. In diesem Fall ist TLS sowohl für den Integritätstest als auch für den Datenpfad aktiviert. Wenn Sie Azure App Service oder andere Azure-Webdienste als Back-End verwenden, gelten diese ebenfalls als implizit vertrauenswürdig, und für End-to-End-TLS sind keine weiteren Schritte erforderlich.

• Wenn das Zertifikat des Back-End-Servers selbstsigniert ist oder von einer unbekannten Zertifizierungsstelle oder einem unbekannten Vermittler signiert wurde, müssen Sie zum Aktivieren von End-to-End-TLS in Application Gateway v2 ein vertrauenswürdiges Stammzertifikat hochladen. Application Gateway kommuniziert nur mit Back-Ends, bei denen das Stammzertifikat des Serverzertifikats mit einem der vertrauenswürdigen Stammzertifikate in der Liste der HTTP-Einstellung für das Back-End übereinstimmt, das dem Pool zugeordnet ist.

• Zusätzlich zur Übereinstimmung des Stammzertifikats überprüft Application Gateway v2 auch, ob die Einstellung „Host“ in der HTTP-Einstellung des Back-Ends mit dem allgemeinen Namen (Common Name, CN) übereinstimmt, der vom TLS/SSL-Zertifikat des Back-End-Servers angegeben wird. Beim Herstellen einer TLS-Verbindung mit dem Back-End legt Application Gateway v2 die SNI-Erweiterung (Server Name Indication, Servernamensanzeige) auf den Host fest, der in der HTTP-Einstellung des Back-Ends angegeben wurde.

• Wenn Hostname aus Back-End-Ziel auswählen anstelle des Felds Host in der Back-End-HTTP-Einstellung ausgewählt wird, wird der SNI-Header immer auf den FQDN des Back-End-Pools gesetzt und der CN auf dem TLS/SSL-Zertifikat des Back-End-Servers muss übereinstimmen seinen FQDN. Mitglieder des Back-End-Pools mit IP-Adressen werden in diesem Szenario nicht unterstützt.

• Das Stammzertifikat ist ein Base64-codiertes Stammzertifikat aus den Zertifikaten des Back-End-Servers.

SNI-Unterschiede in der v1- und v2-SKU

Wie zuvor erwähnt, beendet Application Gateway den TLS-Datenverkehr vom Client beim Application Gateway-Listener (d. h. die Front-End-Verbindung), entschlüsselt den Datenverkehr, wendet die erforderlichen Regeln an, um den Back-End-Server zu ermitteln, an den die Anforderung weitergeleitet werden muss, und stellt eine neue TLS-Sitzung mit dem Back-End-Server her (die Back-End-Verbindung).

In den folgenden Tabellen werden die SNI-Unterschiede zwischen der v1-SKU und der v2-SKU hinsichtlich der Front-End- und der Back-End-Verbindung beschrieben.

Front-End-TLS-Verbindung (Client zu Application Gateway)

Back-End-TLS-Verbindung (Application Gateway zum Back-End-Server)

Beim Testdatenverkehr

Beim Livedatenverkehr

Nächste Schritte

Nachdem Sie sich über End-to-End-TLS informiert haben, fahren Sie mit dem Konfigurieren von End-to-End-TLS mit Application Gateway und PowerShell fort, um ein Anwendungsgateway mit End-to-End-TLS zu erstellen.