Hierbei handelt es sich um HTTP-Keep-Alive, bei dem mehrere Ressourcenanforderungen über eine einzelne TCP-Sitzung (und mit SSL über eine einzelne SSL-Sitzung) eingehen können. Dies ist für die Leistung einer SSL-Site von großer Bedeutung, da ohne Keep-Alive ein SSL-Handshake für jede angeforderte Ressource erforderlich wäre.
Hier geht es also um eine große Keep-Alive-Sitzung vom Client bis zum Backend-Server. Es ist eine wichtige Sache für die Leistung und für moderne HTTP-Server selbstverständlich, aber dieser Patch sagt, dass er es nicht unterstützt. Schauen wir uns an, warum ..
Eine Keep-Alive-Sitzung besteht nur aus mehreren Anfragen nacheinander. Sobald der Server seine Antwort auf eine Anfrage beendet hat, sendet der Server kein FINPaket, um die TCP-Sitzung zu beenden. Der Client kann einfach einen weiteren Stapel von Headern senden.
Um zu verstehen, was dieser Patch tut, ist hier ein Beispiel für ein Keep-Alive-Gespräch:
Klient:
GET / HTTP/1.1
Connection: keep-alive
Host: domain.com
...
Server:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Apache
Content-Length: 34
.... (other headers)
<html><head>content!</head></html>
Hier würde eine Nicht-Keep-Alive-Verbindung aufhören. Mit Keep-Alive kann der Client jedoch einfach einen anderen abfeuern:
GET /images/some/image.on.the.page.jpg HTTP/1.1
Connection: keep-alive
Host: domain.com
...
Für die Client-ID beim Proxying können einige Reverse-Proxys im X-Forwarded-ForHeader jeder Client-Anforderung hinzugefügt werden . Dadurch wird dem Upstream-Server mitgeteilt, woher die Anforderung stammt (anstelle jeder Anforderung, die von der IP des Reverse-Proxys initiiert wird), um die Protokollierung und andere Anwendungsanforderungen zu gewährleisten.
Der X-Forwarded-ForHeader muss in jede Client-Ressourcenanforderung eingefügt werden, die über die Keep-Alive-Verbindung gesendet wird, da jedes Mal die vollständigen Header gesendet werden. Die Behandlung des X-Forwarded-ForHeaders und die Übersetzung in die "echte" Anforderungs-IP erfolgt pro Anforderung und nicht pro TCP-Keep-Alive-Sitzung. Und hey, vielleicht gibt es da draußen eine großartige Reverse-Proxy-Software, die eine einzige Keep-Alive-Sitzung verwendet, um Anfragen von mehreren Clients zu bearbeiten.
Hier schlägt dieser Patch fehl.
Der Patch an dieser Site überwacht den Puffer der TCP-Sitzung auf das Ende des ersten Satzes von HTTP-Headern im Stream und fügt den neuen Header nach dem Ende dieses ersten Satzes von Headern in den Stream ein. Danach wird der X-Forwarded-ForJob als erledigt betrachtet und das Scannen nach dem Ende neuer Headersätze beendet. Diese Methode kennt nicht alle zukünftigen Header, die über nachfolgende Anforderungen eingehen.
Kann ihnen nicht wirklich die Schuld geben; stunnel war nicht wirklich dafür gebaut, den Inhalt seiner Streams zu verarbeiten und zu übersetzen.
Dies hätte Auswirkungen auf Ihr System, dass bei der ersten Anforderung eines Keep-Alive-Streams der X-Forwarded-ForHeader ordnungsgemäß injiziert wird und alle nachfolgenden Anforderungen einwandfrei funktionieren - der Header jedoch nicht.
Sofern es keinen anderen Header-Injection-Patch gibt, der mehrere Client-Anforderungen pro Verbindung verarbeiten kann (oder diesen mithilfe unserer Freunde bei Stack Overflow optimieren kann), müssen Sie möglicherweise andere Optionen für Ihre SSL-Beendigung prüfen.