☰

Stunnel: ssl a ssl

tag-icon • tag-icon windows ssl stunnel
Stunnel: ssl a ssl

Tengo un pequeño servicio que escucha solo enhttps://localhost:41952y comprueba el nombre del host de origen (debe ser localhost). Quiero conectarme en "listen:1988" y redirigir las solicitudes con stunnel a "localhost:41952"

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

configuración actual:

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

registro de openssl_client:

http://pastebin.com/7bg3sf7J

Tenga en cuenta que este certificado es diferente al de localhost:41952.

prueba de rizo:

$ 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: */*
>

esperando para siempre.

¿Quizás necesito client = yes? Pero no tengo ningún certificado, a menos que lo haya exportado desde Firefox en el sitio del servicio.https://localhost:41952

Mi pregunta original:

Proxy inverso gratuito con SSL para Windows

Respuesta1

stunnel es un programa para crear una puerta de enlace entre SSL y no SSL. Desde eldescripción en la página de inicio:

Stunnel es un proxy diseñado para agregar funcionalidad de cifrado TLS a clientes y servidores existentes sin ningún cambio en el código de los programas.

Esta herramienta no está diseñada para crear una puerta de enlace de SSL a SSL. Lo que necesita en su caso es simplemente un reenviador TCP simple que se puede hacer consocat:

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

Con este reenviador, la conexión a 192.168.1.17:1988 se reenvía a 127.0.0.1:41952. El cliente obtendrá el certificado original del servidor porque el reenvío se realiza en el nivel TCP. El servidor verá la conexión procedente de 127.0.0.1.

EDITAR: después de mucha comunicación, ahora está claro que el objetivo no es tener el nombre de host de origen correcto en la pregunta y no el referente correcto como se afirma en una respuesta, sino que el encabezado de solicitud HTTP del host tiene el valor esperado 'localhost '. Dado que el encabezado del host se establece a partir de la URL, deberá asegurarse de que la solicitud se reenvíe al sistema remoto y que el navegador no intente resolver la URL por sí solo, porque de lo contrario intentaría conectarse al servidor en la máquina donde el navegador se está ejecutando. Para diferir la resolución de la URL al sistema de destino, necesita ejecutar un proxy allí, es decir, algo como Charles Proxy que haya probado o algún proxy SOCKS.

Respuesta2

Entonces para conectarse ahttps://192.168.1.10:1988y acceda al servicio SSL que escucha en el puerto 4952 de la interfaz loopback en el host con IP 192.168.1.10:

Necesitamos 2 estrofas de stunnel para lograr lo que queremos.

[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

Lo único que no puedo lograr es modificar el encabezado del host a localhost para todas las solicitudes en stunnel.

Desde curl está funcionando perfectamente:

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

Respuesta3

He resuelto un HTTPS-TO-HTTPSproblema similar enventanascon este comando:

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

información relacionada