Redirecione TODO o tráfego da Web através do TLS sem uma VPN

Premissas:

Servidor:

• Eu tenho um servidor Debian Squeeze, roteável na Internet pública, com um endereço IPv4 estático.
• Eu tenho acesso irrestrito para modificar o software no servidor.
• O servidor pode escutar em portas arbitrárias, reconfigurar regras de firewall, basicamente não há restrições sobre o que o servidor pode fazer.

Cliente:

• Posso executar o Firefox, programas Java, programas .NET e alguns executáveis ​​nativos que não exigem acesso de administrador no meu sistema local (uma área de trabalho bloqueada do Windows sem direitos de administrador).
• Eu posso instalar Addons no Firefox.
• Eu posso ouvir em qualquer porta na interface loopback ( localhost). Portanto, os programas mencionados acima podem se conectar a uma porta local e executar E / S de rede arbitrária, sem passar por um proxy.
• Todo o acesso público à Internet é roteado através de um proxy HTTP restritivo que bloqueia muitos sites e faz uma inspeção cuidadosa e estável. Na porta 80, permite exclusivamente HTTP (sem TLS / SSL). Na porta 443, permite CONNECTSSL / TLS baseado em hosts remotos que não são bloqueados pelo nome de domínio / endereço IP.
• O proxy HTTP restritivo não executa inspeção profunda de pacotes das conexões TLS permitidas através do proxy e não executa ataques do tipo Man in the Middle nessas conexões.
• O servidor acima mencionado ao qual tenho acesso não é bloqueado pelo proxy.

Objetivo:

Desejo rotear todas as solicitações HTTP e HTTPS emitidas pelo Firefox, através do servidor acima, por SSL / TLS.

Outras notas sobre o "objetivo":

• Mesmo que o site do terminal (por exemplo http://superuser.com) não esteja usando SSL / TLS no meu servidor, ainda quero usar o SSL / TLS do meu cliente para o meu servidor e fazer com que meu servidor execute a solicitação HTTP - criptografada ou não - - para o meu destino desejado.
• Não me importo se meu servidor estiver olhando para o tráfego SSL "de forma clara". Em outras palavras, eu não exijo criptografia SSL completa de ponta a ponta do meu cliente local, até o servidor remoto, se o servidor remoto estiver sendo acessado, por exemplo https://google.com. Em outras palavras, confio no servidor para manter meus dados confidenciais.
• Estou disposto a instalar qualquer software ou complemento do Firefox que não exija direitos de administrador e possa ser executado no Windows 7 de 32 bits.
• O software de código aberto é preferido sobre o proprietário, e o freeware é preferido sobre o software que exige uma taxa de licença.
• O software existente é preferível a ter que codificar um novo software, embora eu esteja disposto a escrever código, se esse for o único caminho.

Estou procurando uma "solução" pouco descrita que descreva:

• Qual software seria necessário no cliente? Se você conhece um pacote de software específico, nomeie-o; caso contrário, descreva o que o software cliente teria que fazer .
• Qual software seria necessário no servidor? Se você conhece um pacote de software específico, nomeie-o; caso contrário, descreva o que o software do servidor teria que fazer .
• Se você citou pacotes de software específicos acima, descreva quais parâmetros de configuração seriam necessários para configurá-lo para atingir meu objetivo.
• Se, por algum motivo, você acredita que isso não é possível , descreva o motivo .

Coisas que eu tentei que não funcionam

• Instalando squidno meu servidor, tentei configurar um proxy HTTP padrão próprio no meu servidor. Isso não deu certo, porque quando solicito sites no Firefox através de HTTP normal, o Firefox tenta acessar meu servidor também através de HTTP normal! Isso não é aceitável, porque o proxy na minha rede local pode, é claro, observar e / ou bloquear o tráfego HTTP regular entre meu cliente e o servidor.
• As VPNs não funcionam , nem mesmo o OpenVPN sobre TLS escutando na porta 443, porque não tenho permissões no computador local para instalar um tunadaptador de rede que pode executar o roteamento da camada 3, nem qualquer tipo de roteamento da camada 2 (por exemplo tap). Em resumo: eu precisaria de direitos de administrador para instalar o OpenVPN e, mesmo que eu tivesse esses direitos temporariamente, a empresa não ficaria muito satisfeita se descobrisse que ele estava instalado. Um programa Java ou .NET é muito menos perceptível, especialmente quando não está instalado em Adicionar / Remover Programas e não possui nenhum componente de driver de kernel como o OpenVPN.

Eu descobri. : D Esta solução atende a todos os meus requisitos e atende perfeitamente a todos os meus objetivos. O desempenho também não é ruim, considerando o nível de indireção necessário para alcançar isso.

A abordagem geral é assim:

1. Configure uma CA (Autoridade de Certificação) local e gere uma "chave do servidor" e uma "chave do cliente" do RSA (usei criptografia de 256 bits). Para isso, usei o Easy-RSA versão 3.0.0-rc2.

2. Execute qualquer proxy HTTP padrão falso na "Debian Box" (o servidor na Internet pública), certificando-se de que ele escute apenas no host local (NÃO deve ser exposto à Internet pública). Para os meus propósitos, usei Privoxy, mas Squidteria funcionado tão bem. Como ele está apenas ouvindo no host local, a autenticação não é necessária (a menos que haja processos em execução na sua caixa em que você não confie; nesse caso, caramba ...)

3. Baixe o stunnel e instale-o no cliente e no servidor. O processo para fazer isso será específico do SO; no meu caso, escolhi compilar stunnel da fonte (paranóia ...) para Windows, que foi um processo bastante envolvido que não detalharei aqui. No lado do servidor, estava disponível no gerenciador de pacotes :)

4. A configuração do Stunnel foi bastante assustadora no começo, mas é mais simples do que parece! Basicamente, no servidor, você precisa de algo como o "stunnel.conf do servidor" abaixo. No cliente, você precisa de algo como o "stunnel.conf do cliente" abaixo.

5. Inicie o Privoxy; iniciar stunnel no servidor, apontando-o para o arquivo de configuração; iniciar stunnel no cliente, apontando-o para o arquivo de configuração. Não há realmente nada de especial na configuração do Privoxy; o padrão foi bom para mim.

6. No Firefox, seu navegador preferido no lado do cliente, defina o proxy HTTP e HTTPS para ser o mesmo da porta em que o stunnel do seu cliente está ouvindo - provavelmente algo como localhost: 8080.

Provavelmente, devo observar que, se o proxy da sua rede local exigir algum tipo de autenticação, você precisará obter o stunnel para se autenticar ou usar outro proxy de interceptação local e encadear os componentes - algo como Firefox -> stunnel -> local proxy de autenticação -> proxy / gateway da LAN -> internet -> stunnel do servidor -> privoxy.

É muita cópia, mas 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

Depois de tudo configurado, o resultado final fica mais ou menos assim:

1. Seu navegador se conecta a localhost:9020(stunnel) e o trata como um proxy que pode aceitar conexões HTTP e / ou HTTPS.
2. Quando o stunnel obtém uma conexão do navegador, ele alcança, através do proxy / gateway do firewall, para estabelecer uma sessão TLS com o servidor remoto. Nesse ponto, seu cliente verifica o certificado PKI do seu servidor e vice-versa.
3. Depois que a sessão TLS é estabelecida com o servidor remoto, o stunnel passa os dados provenientes do seu navegador, por exemplo, uma solicitação HTTP ou uma solicitação de encapsulamento SSL, através do proxy local e diretamente ao seu servidor. Esse canal é criptografado; portanto, sua rede local não pode dizer o que os dados contêm, eles só podem adivinhar fazendo uma análise de tráfego.
4. Quando a stunnelinstância em execução no servidor começa a receber dados, ela abre uma conexão para localhost:8118, por exemplo , onde seria o servidor proxy HTTP (S), no meu caso Privoxy, escutando.
5. O Privoxy age como um servidor proxy HTTP de encaminhamento normal e encaminha suas solicitações para a Internet pública através do ISP do servidor.

A quantidade de soquetes e buffers envolvidos torna esse método muito alto, especialmente se você estiver aninhando uma conexão SSL por meio do proxy, mas tem a vantagem de que sua rede local não tem como saber quais sites você está visitando por SSL. Quero dizer, ele sabe que você está visitando seu servidor, mas, além disso, não sabe se você está visitando o Gmail, o SuperUser ou o que quer. E o seu gateway local não tem como filtrar ou bloquear você.

Eu tentei essa configuração na minha máquina local e posso garantir que o "proxy restritivo" obteria um CONNECT DEBIAN_IP:443 HTTP/1.1, mas ele não verá nenhum certificado, portanto, não tenho certeza se isso funcionaria.

Vamos supor: seu Debian tem Apacheou precisa Squidfazer proxy e um servidor SSH. No PC cliente, você precisa putty, que é um programa que não precisa de privilégios de administrador para ser executado, não precisa de instalação e pode ser executado a partir de um pendrive.

Primeiro seu Debian:

Faça seu SSH escutar na porta 443, basta adicionar (ou substituir sua porta atual) a Port 443on /etc/ssh/sshd_confige também permitir o encaminhamento de TCP (adicione AllowTcpForwarding yesesse arquivo)

Configure seu Squid ou Apache para fazer proxy. Como isso será usado através de um túnel SSH, seria necessário apenas escutar na interface de loopback. Caso você use um Apache:

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

Servidor pronto, vamos configurar o seu PC cliente:

Na massa, configure o IP público do seu Debian como Hoste 443como porta. Verifique se SSHainda está selecionado. Mude para as Connection -> Proxyconfigurações, selecione HTTPe preencha as configurações de "proxy restritivo". Mude para as Connectionconfigurações e estabeleça uma keepalive de 30- 60. Mude para o Connection -> SSH -> Tunnels. Em source portestabelecer 8080, e sobre Destination, localhost:8080. Deixe Localselecionado e pressione Add. Você deve ver no espaço acima algo parecido L8080 locahost:8080. Volte para as Sessionconfigurações, anote um nome na primeira linha Saved sessionse salve todas essas configurações tediosas para ajudar a restabelecer a conexão nos dias seguintes.

Agora você pode tentar Opena conexão com o seu Debian. Se você vir a solicitação do usuário, estamos apenas a um passo de concluir isso. Caso contrário ... teremos que procurar outro caminho.

Agora, no Firefox, defina localhostna porta 8080como seu proxy.

Você está no meio do caminho com a configuração de um proxy no seu servidor. A outra metade é SSL no servidor e um proxy local no cliente usando o putty para conectar-se ao seu proxy HTTP habilitado para SSL e defina o Firefox como proxy para 127.0.0.1.

Acabei de fazer um google rápido para uma configuração de massa e descobri o seguinte: https://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-using-apache-170/