Verwenden von HTTP / 2 unter Windows Server 2016 mit TLS / SSL-Terminierung

1360
Dan Atkinson

Ich untersuche die Möglichkeit der Verwendung von Windows Server 2016 für eine Gruppe von Webservern, die sich hinter einem Load Balancer befinden, der SSL-Offloading verwendet.

Der größte Vorteil von Windows Server 2016 gegenüber 2012 besteht für mich darin, dass das HTTP / 2-Protokoll verwendet werden kann. Da HTTP / 2 jedoch generell gegen HTTPS implementiert wird, befürchte ich, dass Anforderungen nicht als HTTPS erkannt werden, da sie als HTTP (wenn auch mit einem x-forwarded-protoHeader) ankommen . Ich habe nach ein paar Ressourcen gesucht, aber es gibt nicht viele konkrete Beweise.

Weiß jemand, ob IIS dieses Setup unterstützt und die Antwort trotzdem über HTTP / 2 sendet, oder wird der gesamte Datenverkehr einfach auf HTTP / 1.1 zurückfallen? Gibt es eine Möglichkeit, IIS für die Verwendung von HTTP / 2 auf einer Anforderung, die möglicherweise unsicher aussieht, zu konfigurieren (!)?

Vielen Dank.

Bearbeiten: Zur Klarstellung wird der Lastausgleich x-forwarded-proto:httpsan den Server gesendet. Die anfragende Anwendung sieht dies jedoch aufgrund der SSL-Verschiebung als unsicher an.

1
Dies ist etwas unklar. Anscheinend möchten Sie einen Aufruf "http:" ausstellen, der "X-Forwarded-Protocol: https" enthält, und ihn als "https:" behandeln lassen. Dies ist zweifelhaft, da in der von Ihnen zitierten Ressource angegeben ist: "IIS unterstützt derzeit HTTP / 2 nur über TLS". Es sollte jedoch leicht genug sein, dies auf einer WS2016-VM zu testen. harrymc vor 6 Jahren 0
Wenn Windows Server 2012 HTTP / 2 unterstützt, wird dies von 2016 unterstützt. Nur TLS 1.2+ gilt als sicher. Dies ist die einzige Verschlüsselungssuite, die Sie verwenden sollten. Ramhound vor 6 Jahren 0
@harrymc Nein, der Header "x-forwarded-proto" hat den Wert "https", was darauf hinweist, dass die Ursprungsanforderung "HTTPS" ist. Wenn der Webserver die Anfrage sieht, hat die anfragende URL jedoch das HTTP-Protokoll. Dan Atkinson vor 6 Jahren 0
@ Ramhound Das ist nicht korrekt. Windows Server 2012 unterstützt ** nicht HTTP / 2. Sie ist nur mit Windows 10 und Server 2016 verfügbar. Sie können die Liste der unterstützten Windows-Plattformen für HTTP / 2 [hier] (https://en.wikipedia.org/wiki/HTTP/2#Software_and_services_supporting_HTTP.2F2) sehen. Dan Atkinson vor 6 Jahren 0
Sie wiederholen erneut, dass Sie eine "http:" - URL mit "X-Forwarded-Protocol: https" ausgeben. Ich wiederhole, dass dies zweifelhaft ist und nur ein Test zeigt. harrymc vor 6 Jahren 0
@harrymc Wenn mein Test fehlschlägt, bedeutet das nicht, dass es definitiv keine Möglichkeit gibt, es zu tun, sondern dass er den Test nicht sofort unterstützt. Möglicherweise gibt es eine andere Methode, die mein Test nicht zeigen würde , weshalb ich hier bin und diese Frage stelle! Dan Atkinson vor 6 Jahren 0
Und wenn es gelingt? Ich muss sagen, dass das "X-Forwarded-Protocol" wie eine Sicherheitslücke aussieht, im Grunde nur eine "Vertrau mir" -Fahne. Möglicherweise müssen Sie einige Sicherheitsmaßnahmen ausschalten ([Beispiel] (https://social.msdn.microsoft.com/Forums/azure/en-US/c3861a4e-67e7-4f59-b8f9-e27e9534fa01/azure-web-app-overriding -xforwardedfor-header-from-reverse-proxy-server? forum = windowsazurewebsitespreview)). harrymc vor 6 Jahren 1
@harrymc Verzeihen Sie, wenn ich falsch liege, aber Ihr Beispiel bezieht sich auf den MitM-Angriff, der mit "x-forwarded-for" verwendet wird, und hat nichts mit "x-forwarded-proto" zu tun. Ich bin mir auch nicht sicher, was ein solcher Angriffsvektor dafür wäre? Könnten Sie mich bitte aufklären? Dan Atkinson vor 6 Jahren 0
Das war nur ein Beispiel. Ich habe keine Erfahrung damit und es gibt absolut keine Dokumentation. Sie beschreiten dort neue Wege. harrymc vor 6 Jahren 0
** Err ... Ich habe nicht erwartet, diese Nachricht zu sehen. Keine Ursache. Keine Notwendigkeit, mit mir im Chat zu spielen! ** Lassen Sie uns [diese Diskussion im Chat fortsetzen] (http://chat.stackexchange.com/rooms/63333/discussion-between-dan-atkinson-and-harrymc). Dan Atkinson vor 6 Jahren 0

1 Antwort auf die Frage

1
Mike Schenk

Wie in dem von Ihnen verlinkten Blogbeitrag darauf hingewiesen (und bestätigt, wenn er hier in offizielle Dokumente umgewandelt wurde ), verwendet IIS das HTTP / 2-Protokoll nur, wenn eine TLS-Verbindung zum IIS-Server hergestellt wurde.

Wie heute in IIS 10 implementiert, wird HTTP / 2 während des TLS-Handshakes mithilfe von ALPN identifiziert. Wenn es weder ein ALPN noch ein TLS gibt, wird kein HTTP / 2 verwendet. Sehen Sie sich diesen BUILD-Vortrag ab 2015 ab etwa 5'06 "an und denken Sie daran, dass IIS den HTTP / 1.1-Aktualisierungsmechanismus nicht implementiert (wie im Video bei 8'46" angegeben).

In Ihrem Szenario ist es höchstwahrscheinlich der Fall, dass der Load Balancer klare TCP-Verbindungen herstellt und HTTP / 1.1-Anforderungen an die Back-End-Server sendet. Zu dem Zeitpunkt, an dem IIS den x-forwarded-protoHeader sogar sehen kann, wurde die Verbindung bereits hergestellt und das Protokoll HTTP / 1.1 wurde bereits identifiziert.

Jetzt ist es möglich, dass Ihr Load Balancer HTTP / 2 selbst unterstützen kann, sodass die Browser der Endbenutzer Anforderungen und Antworten mit dem Load Balancer multiplexen können, während diese Anforderungen in HTTP / 1.1-Anforderungen und Antworten auf Ihre Back-End-Server übersetzt werden .

Es ist auch möglich, dass Ihr Lastenausgleichsnetzwerk TLS-Verbindungen zu den Back-End-Servern herstellen und HTTP / 2 verwenden kann. Dies würde jedoch meistens den Punkt der SSL-Abladung übergehen.

Verwandte Probleme