Redireccionar TODO el tráfico web a través de TLS sin una VPN

Suposiciones

Servidor:

• Tengo un servidor Debian Squeeze, enrutable en Internet público, con una dirección IPv4 estática.
• Tengo acceso sin restricciones para modificar el software en el servidor.
• El servidor puede escuchar en puertos arbitrarios, reconfigurar las reglas del cortafuegos, básicamente no hay restricciones sobre lo que el servidor puede hacer.

Cliente:

• Puedo ejecutar Firefox, programas Java, programas .NET y algunos ejecutables nativos que no requieren acceso de administrador en mi sistema local (un escritorio de Windows bloqueado sin derechos de administrador).
• Puedo instalar complementos en Firefox.
• Puedo escuchar en cualquier puerto de la localhostinterfaz loopback ( ). Por lo tanto, los programas antes mencionados pueden unirse a un puerto local y realizar E / S de red arbitrarias, sin pasar por un proxy.
• Todo el acceso público a Internet se enruta a través de un proxy HTTP restrictivo que bloquea muchos sitios y realiza una cuidadosa inspección de estado. En el puerto 80, permite exclusivamente HTTP (sin TLS / SSL). En el puerto 443, permite CONNECTSSL / TLS basado en hosts remotos que no están bloqueados por nombre de dominio / dirección IP.
• El proxy HTTP restrictivo no realiza una inspección profunda de paquetes de conexiones TLS que están permitidas a través del proxy, y no realiza ataques Man in the Middle en esas conexiones.
• El servidor al que tengo acceso no está bloqueado por el proxy.

Gol:

Quiero enrutar todas las solicitudes HTTP y HTTPS emitidas por Firefox, a través del servidor anterior, a través de SSL / TLS.

Otras notas sobre el "Objetivo":

• Incluso si el sitio de punto final (por ejemplo http://superuser.com) no está usando SSL / TLS en mi servidor, todavía quiero usar SSL / TLS de mi cliente a mi servidor y hacer que mi servidor realice la solicitud HTTP, ya sea encriptada o no, - a mi destino deseado.
• No me importa si mi servidor está mirando el tráfico SSL "en claro". En otras palabras, no necesito un cifrado SSL completo de extremo a extremo desde mi cliente local, hasta el servidor remoto, si se accede al servidor remoto, por ejemplo https://google.com. En otras palabras, confío en el servidor para mantener mis datos confidenciales.
• Estoy dispuesto a instalar cualquier software o complemento de Firefox que no requiera derechos de administrador y pueda ejecutarse en Windows 7 de 32 bits.
• Se prefiere el software de código abierto al propietario, y el software gratuito se prefiere al software que requiere una tarifa de licencia.
• Se prefiere el software existente a tener que codificar un nuevo software, aunque estoy dispuesto a escribir código si esa es la única forma.

Estoy buscando una "solución" descrita libremente que describe:

• ¿Qué software se requeriría en el cliente? Si conoce un paquete de software específico, asígnele un nombre; de lo contrario, describa lo que el software del cliente tendría que hacer .
• ¿Qué software se requeriría en el servidor? Si conoce un paquete de software específico, asígnele un nombre; de lo contrario, describa lo que el software del servidor tendría que hacer .
• Si mencionó paquetes de software específicos arriba, describa qué parámetros de configuración serían necesarios para configurarlo para cumplir mi objetivo.
• Si por alguna razón cree que esto no es posible , describa por qué .

Cosas que he probado que no funcionan

• Instalando squiden mi servidor, intenté configurar un proxy HTTP estándar propio en mi servidor. Esto no funcionó, porque cuando solicito sitios web en Firefox a través de HTTP normal, ¡ Firefox también intenta acceder a mi servidor a través de HTTP normal! Esto no es aceptable, porque el proxy en mi red local puede, por supuesto, observar y / o bloquear el tráfico HTTP normal entre mi cliente y el servidor.
• Las VPN no funcionan , ni siquiera OpenVPN sobre TLS escucha en el puerto 443, porque no tengo los permisos en la computadora local para instalar un tunadaptador de red que pueda realizar el enrutamiento de capa 3, ni puedo hacer ningún tipo de enrutamiento de capa 2 (por ejemplo tap) En resumen: necesitaría derechos de administrador para instalar OpenVPN, e incluso si tuviera esos derechos de administrador temporalmente, la compañía no estaría muy contenta si descubrieran que está instalada. Un programa Java o .NET es mucho menos notable, especialmente cuando no está instalado en Agregar o quitar programas y no tiene un componente de controlador de kernel como OpenVPN.

Me lo imaginé. : D Esta solución satisface todos mis requisitos y cumple todos mis objetivos perfectamente. El rendimiento tampoco es tan malo, considerando el nivel de indirección que es necesario para lograr esto.

El enfoque general es así:

1. Configure una Autoridad de certificación (CA) local y genere una "clave de servidor" y una "clave de cliente" de RSA (utilicé un cifrado de 256 bits). Para esto, utilicé Easy-RSA versión 3.0.0-rc2.

2. Ejecute cualquier proxy HTTP estándar falso en el "Debian Box" (el servidor en Internet público), asegurándose de que escuche solo en localhost (NO debe estar expuesto a Internet público). Para mis propósitos solía Privoxy, pero Squidhabría funcionado igual de bien. Dado que solo está escuchando en localhost, la autenticación no es necesaria (a menos que haya procesos que se ejecutan en su caja en los que no confía; en cuyo caso, yikes ...)

3. Descargue stunnel e instálelo tanto en el cliente como en el servidor. El proceso para hacer esto va a ser específico del sistema operativo; en mi caso, elegí compilar stunnel desde la fuente (paranoia ...) para Windows, que fue un proceso bastante complicado que no detallaré aquí. En el lado del servidor, estaba disponible en el administrador de paquetes :)

4. La configuración de Stunnel fue bastante desalentadora al principio, ¡pero es más simple de lo que parece! Básicamente, en el servidor, necesita algo como el siguiente "server's stunnel.conf". En el cliente, necesita algo como el siguiente "cliente's stunnel.conf".

5. Iniciar Privoxy; iniciar stunnel en el servidor, apuntándolo al archivo de configuración; iniciar stunnel en el cliente, apuntando al archivo de configuración. Realmente no hay nada tan especial sobre la configuración de Privoxy; El valor predeterminado estaba bien para mí.

6. En Firefox, su navegador de elección en el lado del cliente, configure el proxy HTTP y HTTPS para que sea el mismo que el puerto en el que está escuchando el stunnel de su cliente, probablemente algo así como localhost: 8080.

Probablemente debería tener en cuenta que si el proxy de su red local exige algún tipo de autenticación, tendrá que obtener un stunnel para autenticarse por usted, o bien usar otro proxy de interceptación local y encadenarlos, algo como Firefox -> stunnel -> local autenticación de proxy -> proxy / puerta de enlace LAN -> internet -> el stunnel de su servidor -> privoxy.

Eso es mucha copia, ¡pero funciona!

;This is the *client's* stunnel.conf.
[https]
accept = localhost:9020
connect = your.lan.proxy:80
client = yes
protocol = connect
;protocolHost should be the same as the "accept" for the server
protocolHost = 1.2.3.4:443
;Same CAfile, different cert and key pair
CAfile = ca.crt
cert = client.crt
key = client.key
;VERY IMPORTANT!!! Make sure it's really your server and not a MITM attempt by your local network by making sure that the certificate authority "ca.crt" really signed the server's cert
verify = 2
;More performance tweaks...
sessionCachetimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

.

;This is the *server's* stunnel.conf.
[https]
;1.2.3.4 is a publicly-routable, static IP address that can be connected to by your box that's under the firewall
accept = 1.2.3.4:443
;localhost:8118 is an example of where your local forwarding HTTP(S) proxy might reside.
connect = localhost:8118
CAfile = ca.crt
cert = server.crt
key = server.key
;VERY IMPORTANT!!! Without this, anyone in the world can use your public stunnel port as an open proxy!
verify = 2
;Set some timeouts higher for performance reasons
sessionCacheTimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

Una vez que todo está configurado, el resultado final termina luciendo así:

1. Su navegador web se conecta a localhost:9020(stunnel) y lo trata como un proxy que puede aceptar conexiones HTTP y / o HTTPS.
2. Una vez que Stunnel obtiene una conexión de su navegador, se extiende, a través del proxy / puerta de enlace de su firewall, para establecer una sesión TLS con su servidor remoto. En este punto, su cliente verifica el certificado PKI de su servidor y viceversa.
3. Una vez que se establece la sesión TLS con su servidor remoto, Stunnel pasa los datos que provienen de su navegador, por ejemplo, una solicitud HTTP o una solicitud de túnel SSL, a través del proxy local y directamente a su servidor. Este canal está encriptado, por lo que su red local no puede decir qué contienen los datos, solo pueden adivinar haciendo un análisis de tráfico.
4. Una vez que la stunnelinstancia que se ejecuta en su servidor comienza a recibir datos, abre una conexión a localhost:8118, por ejemplo , donde estaría su servidor proxy HTTP (S), en mi caso, Privoxy.
5. Privoxy actúa como un servidor proxy HTTP de reenvío normal y reenvía sus solicitudes a Internet público a través del ISP del servidor.

La cantidad de sockets y buffers involucrados hace que este método sea muy elevado, especialmente si está anidando una conexión SSL a través del proxy, pero tiene la ventaja de que su red local no tiene forma de saber qué sitios está visitando a través de SSL. Quiero decir, sabe que estás visitando tu servidor, pero aparte de eso, no sabe si estás visitando Gmail o SuperUser o lo que sea. Y su puerta de enlace local no tiene forma de filtrarlo o bloquearlo.

He intentado esta configuración en mi máquina local, y puedo asegurar que el "proxy restrictivo" obtendrá un CONNECT DEBIAN_IP:443 HTTP/1.1, pero no verá ningún certificado, por lo que no estoy seguro de si esto funcionaría.

Asumamos: su Debian tiene Apacheo Squidpara hacer el proxy y un servidor SSH. En su PC cliente, necesita putty, que es un programa que no necesita privilegios de administrador para ejecutarse, no necesita instalación y podría ejecutarse desde un pendrive.

Primero tu Debian:

Haga que su SSH escuche en el puerto 443, simplemente agregue (o reemplace su puerto actual) Port 443a /etc/ssh/sshd_configy también permita el reenvío TCP (agregue AllowTcpForwarding yesese archivo)

Configure su Squid o Apache para hacer proxy. Como esto se utilizará a través de un túnel SSH, solo necesitaría escuchar en la interfaz de bucle invertido. En caso de que use un Apache:

Listen 127.0.0.1:8080
ProxyRequests On
<Proxy *>
  Order deny,allow
</Proxy>

Servidor listo, configuremos su PC cliente:

En masilla, configure la IP pública de su Debian como Hosty 443como puerto. Asegúrese de que SSHtodavía esté seleccionado. Cambie a la Connection -> Proxyconfiguración, seleccione HTTPy complete su configuración de "proxy restrictivo". Cambie a la Connectionconfiguración y establezca un keepalive de 30- 60. Cambiar a la Connection -> SSH -> Tunnels. En source portSTABLECER 8080, y en Destination, localhost:8080. Deje Localseleccionado y presione Add. Deberías ver en el espacio de arriba algo así L8080 locahost:8080. Vuelva a la Sessionconfiguración, escriba un nombre en la primera fila Saved sessionsy guarde todas estas configuraciones tediosas para ayudar a restablecer la conexión en los días siguientes.

Ahora puede intentar Openla conexión a su Debian. Si ve el mensaje del usuario, estamos a solo un paso de terminar con esto. Si no ... tendremos que buscar otra forma.

Ahora, en Firefox, configúralo localhosten el puerto 8080como tu proxy.

Estás a mitad de camino con la configuración de un proxy en tu servidor. La otra mitad es SSL en el servidor, y un proxy local en el cliente que usa masilla para conectarse a su proxy HTTP habilitado para SSL, y configura Firefox para que proxy todo a 127.0.0.1.

Acabo de hacer un google rápido para una configuración de masilla y encontré esto: https://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-using-apache-170/