[FUG-BR] Bloqueio HTTPS

Quinta Maio 3 09:24:51 BRT 2012

Em 2 de maio de 2012 20:39, Paulo Henrique BSD Brasil <
paulo.rddck em bsd.com.br> escreveu:

>
>
> 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.
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>

Bom pessoal.

Paulo, impecável a sua explicação. Muito obrigado mesmo!!! Você já foi
professor? rs..
Brincadeiras a parte, terei de ver alguma solução que automatize a
descoberta do proxy (como o WPAD faz), já que não posso fazer isso em quase
400 equipamentos. rs.. No mais, a lógica de funcionamento é sensacional, só
dará trabalho pra configurar.

Uma ideia me veio a cabeça enquanto eu digitava a frase de cima: como o
proxy vai sair pela 3128, eu poderia redirecionar qualquer pessoa que
tentasse sair pela porta 80 para uma página qualquer e que nessa página
tivesse um "redir" em html que a fizesse baixar o script de configuração de
proxy? Desse modo, a opção "detectar automaticamente as configurações" na
área de proxy do navegador agiria?

Enfim, idéias!

Abraços.

--
Att,
Marcus Vinicius.