[FUG-BR] Bloqueio HTTPS

[Paulo Henrique BSD Brasil]

Em 2/5/2012 09:32, Marcus Vinicius. escreveu:
>>
>> Ainda assim para bloqueio dos messengers/gtalks/skype, será necessário
>> bloquear as portas utilizadas por essas aplicações forçando elas a usarem
>> http e ai é que entra o a vez do proxy.
>>
>> Em resumo longo seria o seguinte.
>>
>> Bloquear via firewall qualquer porta utilizada pelos messengers/gtalk
>> Como resposta a indisponibilizade de conexão tais programas irão tentar
>> primeiramente encapisular os datagramas sobre mensagens do protocolo http
>> sem criptografia ( porta 80 )
>> deixei essa porta explicitamente liberada para destinos conhecidos ( redes
>> de bancos e caixa economica em especial ), e barra todo o restante, se o
>> navegar estiver com proxy configurado ele utilizará de imediato o proxy,
>> sugestão cadastre as redes acima como excessão na utilização do proxy, tive
>> problemas com aplicações bancarias sobre java.
>> Como os messengers não terão exito na porta 80 apelaram para o ultimo
>> recurso, protocolo https ( porta 443 ) quando o proxy trabalha de modo
>> transparente o mesmo não pode interferir em trafego interceptado por ser
>> inelegivel para ele, porem quando configurado no navegador ele entra em
>> cena sobre um estilo de ataque tipo man-int-the-middle, visto que na
>> realidade não é a estação do usuário que se conecta no servidor remoto mais
>> sim o proxy e para que o proxy saiba onde o usuário queira se conectar a
>> estação usuária é obrigada e permitir que o proxy compreenda a informação.
>>
>> Em resumo breve,
>> O Software não consegue estabelecer conexão sobre suas portas definidas nos
>> socket padrões da aplicação ( bloqueio via firewall )
>> O Software recorre a mensagens encapsuladas no http ( bloqueio via firewall
>> ).
>> O software apela para protocolos criptografados, enterceptação do proxy (
>> bloqueio via proxy ).
>> O Software não consegue conexão com seus gateways de autenticação, exastão
>> dos recursos por parte do softwares.
>>
>> A unica forma de bular isso tudo é utilizando software tais com o Thor e
>> ultrasurf, e um conhecimento significativo para conseguir configurar essas
>> aplicações, porem ainda é possivel dar um fim nessas aplicações atraves de
>> proxy autenticados munidos de comunicação com IDS/IPS onde se bloqueia
>> dinamicamente os proxy de interconexão utilizado por tais softwares, se a
>> rede é corporativa a maneira mais simples é configurar o anti-virus para
>> não permitir a execução desses softwares, ainda procuro um modo menos
>> intrusivo e complexo para dar cabo nisso se alguem tiver um caminho para me
>> guiar sou todo ouvidos.
>
>
> Paulo, pegando carona na sua excelente explicação (diga-se de passagem,
> muito boa) sobre o funcionamento da comunicação desses aplicativos que nos
> atormentam, queria saber como o proxy consegue ler esse conteúdo, uma vez
> que ele encontra-se criptografado, logo, ilegível pra ele.
>
> Abraços.
>
>
> PS: Se eu estiver sendo muito inconveniente, por favor, me perdoe.
>
> --
> Att,
> Marcus Vinicius.
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Perdão pela demora de respostas, só vi a mensagem agora...
Bom a informação no caso encontra-se citado na explicação acima, o 
trecho em especifico é o seguinte.

________________________________________________________________________
 >> Como os messengers não terão exito na porta 80 apelaram para o ultimo
 >> recurso, protocolo https ( porta 443 ) quando o proxy trabalha de modo
 >> transparente o mesmo não pode interferir em trafego interceptado por ser
 >> inelegivel para ele, porem quando configurado no navegador ele entra em
 >> cena sobre um estilo de ataque tipo man-int-the-middle, visto que na
 >> realidade não é a estação do usuário que se conecta no servidor 
remoto mais
 >> sim o proxy e para que o proxy saiba onde o usuário queira se conectar a
 >> estação usuária é obrigada e permitir que o proxy compreenda a 
informação.
_______________________________________________________________________

Em uma analogia mais próxima da compreensão humana, quando é definido no 
navegador para que o mesmo utilize explicitamente um serviço proxy se 
equipara com a conversa de um turista em paises que falam outra língua.

Por exemplo:
Se o turista em visita ao Brasil não souber falar o português e não quer 
pagar um tradutor ele simplesmente fica apenas como espectador de 
qualquer dialogo próximo ao mesmo ( proxy transparente ), o trafego 
criptografado passa por ele porem ele só repete o que ouviu.

Agora se o turista pagar um tradutor, ele delega confiança explicita 
para o tradutor falar em nome dele, assim confia ainda mais no que o 
tradutor fala, através da relação de confiança o turista consegue se 
comunicar ao seu redor. no caso quando se especifica no browser o proxy 
o que se esta fazendo é simplesmente dizendo para o browser ( seu 
turista ) confiar no tradutor ( seu proxy ), pois você está apresentando 
o turista ( browser ) ao tradutor ( proxy ).

Bom com essa relação de confiança que o browser delega ao proxy, a 
conexão https na verdade é originada pelo servidor proxy sobre explicita 
orientação do browser, em resumo quem de fato se conecta no servidor na 
web é o servidor proxy e o cliente obtem os dados através do proxy com 
delegação de confiança.


Espero ter ajudar a compreender o conceito.

Att.






-- 
"Quando a Morte decide contar uma historia,
A melhor ação que possa fazer é ouvi-la,
e torcer por não ser a sua própria a tal história."

Flames > /dev/null ( by Irado !! ).
RIP Irado!

Paulo Henrique.
Analista de Sistemas / Programador
BSDs Brasil.
Genuine Unix/BSD User.
Fone: (21) 9683-5433.