☰

Stunnel: SSL zu SSL

tag-icon • tag-icon windows ssl stunnel
Stunnel: SSL zu SSL

Ich habe einen kleinen Dienst, der nur zuhörthttps://localhost:41952und prüft den Quellhostnamen (es muss localhost sein). Ich möchte mich mit „listen:1988“ verbinden und Anfragen mit stunnel an „localhost:41952“ umleiten.

https://192.168.1.10:1988 -> redirect https://localhost:41952

aktuelle Konfiguration:

[myservice]
cert = stunnel.pem
accept = 0.0.0.0:1988
connect = localhost:41952

openssl_client-Protokoll:

http://pastebin.com/7bg3sf7J

Bitte beachten Sie, dass dieses Zertifikat anders ist als das auf localhost:41952.

Lockentest:

$ curl https://192.168.1.17:1988/DYMO/DLS/Printing/Check -vk
*   Trying 192.168.1.17...
* Connected to 192.168.1.17 (192.168.1.17) port 1988 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: localhost
> GET /DYMO/DLS/Printing/Check HTTP/1.1
> Host: 192.168.1.17:1988
> User-Agent: curl/7.43.0
> Accept: */*
>

für immer warten.

Vielleicht brauche ich client = yes? Aber ich habe kein Zertifikat, es sei denn, ich habe es aus Firefox auf der Website des Dienstes exportierthttps://localhost:41952

Meine ursprüngliche Frage:

Kostenloser Reverseproxy mit SSL für Windows

Antwort1

stunnel ist ein Programm zum Erstellen eines Gateways zwischen Nicht-SSL und SSL. Von derBeschreibung auf der Homepage:

Stunnel ist ein Proxy, der dazu dient, TLS-Verschlüsselungsfunktionen zu bestehenden Clients und Servern hinzuzufügen, ohne den Programmcode zu ändern.

Dieses Tool ist nicht dafür gedacht, ein Gateway von SSL zu SSL zu erstellen. Was Sie in Ihrem Fall benötigen, ist nur ein einfacher TCP-Forwarder, der mitsocat:

socat TCP4-LISTEN:1988,fork TCP4:127.0.0.1:41952

Mit diesem Forwarder wird die Verbindung zu 192.168.1.17:1988 an 127.0.0.1:41952 weitergeleitet. Der Client erhält das Originalzertifikat vom Server, da die Weiterleitung auf TCP-Ebene erfolgt. Der Server erkennt, dass die Verbindung von 127.0.0.1 kommt.

EDIT: Nach viel Kommunikation ist nun klar, dass es nicht darum geht, den richtigen Quell-Hostnamen in der Frage und nicht den richtigen Referrer in der Antwort zu haben, sondern dass der Host-HTTP-Anforderungsheader den erwarteten Wert „localhost“ hat. Da der Host-Header aus der URL festgelegt wird, müssen Sie sicherstellen, dass die Anforderung an das Remote-System weitergeleitet wird und der Browser nicht versucht, die URL selbst aufzulösen, da er sonst versuchen würde, eine Verbindung zum Server auf dem Computer herzustellen, auf dem der Browser ausgeführt wird. Um die Auflösung der URL auf das Zielsystem zu verschieben, müssen Sie dort einen Proxy ausführen, also entweder etwas wie Charles Proxy, das Sie ausprobiert haben, oder einen SOCKS-Proxy.

Antwort2

Um eine Verbindung herzustellen mithttps://192.168.1.10:1988und erreichen Sie den SSL-Dienst, der auf Port 4952 der Loopback-Schnittstelle auf dem Host mit der IP 192.168.1.10 lauscht:

Wir benötigen zwei Stunnel-Strophen, um unser Ziel zu erreichen.

[myservice]
cert = stunnel.pem
client = no
accept = 0.0.0.0:1988
connect = localhost:1987

[myserviceaux]
cert = stunnel.pem
client = yes
accept = localhost:1987
connect = localhost:4952

Das Einzige, was ich nicht erreichen kann, ist, den Header-Host für alle Anfragen im Stunnel auf „localhost“ zu ändern.

Von curl aus funktioniert es perfekt:

$ curl https://192.168.1.10:41951/DYMO/DLS/Printing/Check -k -H "Host: localhost"

Antwort3

Ich habe ein ähnliches HTTPS-TO-HTTPSProblem gelöst aufWindowsmit diesem Befehl:

netsh interface portproxy add v4tov4 listenport=443 listenaddress=127.0.0.1 connectport=[remote-https-port] connectaddress=[remote-ip]

verwandte Informationen