[GTER] RES: PeerApp 5.6 - Atualizacaoo com HTTPS

Thu Feb 12 00:18:13 -02 2015

o sistema de mudança do google tem uma falha grave, se vc mudar o seu
navegador e colocar ele como "NAVEGADOR XINGLING/gogglebot..." ele
automaticamente migra pra http, mesmo autenticado.

Mais detalhes aqui  -> https://under-linux.org/showthread.php?t=178163

------------------------------------------------------
Atenciosamente,
Marcus Roberto
ISPRJ | INFOSMART
CLARO/WhatsApp (21) 96817-2025 / OI (21) 98510-4261

Esta mensagem, incluindo seus anexos, pode conter informação confidencial
e/ou privilegiada. Se você recebeu este e-mail por engano, não utilize,
copie ou divulgue as informações nele contidas. Por favor, avise
imediatamente o remetente, respondendo ao e-mail, e em seguida apague-o.
Caso necessite de atendimento imediato, recomendamos utilizar um dos canais
disponíveis: http://www.infosmart.com.br ou telefone (21) 3527-0712.
Agradecemos sua colaboração.

Em 11 de fevereiro de 2015 22:41, Marcus Grando <marcus at sbh.eng.br>
escreveu:

> O que eles podem provávelmente fazer é tentar otimizar o que não veio por
> HTTPS. Podem por exemplo um blog ou páginas onde acessaram por HTTP e
> dentro do html existe um link HTTPS para o YouTube, eles reescreverem esse
> html e apontam para HTTP.
>
> A otimização depende muito por onde vem esses links. Não sei também se já
> não fazem isso por debaixo dos panos.
>
> Abraços
>
> --
> Marcus Grando
> marcus (at) sbh.eng.br
> mnag (at) FreeBSD.org
> fb.com/marcus.grando
> @marcusgrando
>
> 2015-02-11 21:23 GMT-02:00 Rafael Koike <koike.rafael at gmail.com>:
>
> > Márcio,
> >
> > Para a Peerapp fazer uma interceptação do HTTPs ela precisaria agir como
> um
> > MITM (Man-In-The-Middle) interceptando o handshake SSL e enviando para o
> > usuário um certificado assinado por ela.
> >
> > Só ai já começa um problema difícil de resolver pois cada computador ou
> > dispositivo móvel do usuário possui uma lista de CA (Autoridades
> > Certificadoras) confiáveis e quando um site como YouTube, Google,
> > Microsoft, Itau, etc. é acessado a autoridade certificadora é confiável
> por
> > parte da estação e a comunicação é estabelecida.
> > Se a Peerapp interceptar a comunicação e enviar um certificado próprio o
> > navegador do usuário já iria acusar como pagina não confiável.
> > Também você não consegue comprar de uma Certsign, COMODO ou SERASA um
> > certificado desse porque esse não é um certificado de servidor, mas sim
> um
> > certificado de CA!
> >
> > Então a unica situação viável em que se intercepta HTTPS/SSL é em
> empresas
> > onde o equipamento usa um certificado auto-assinado ou assinado por uma
> CA
> > interna e ai a empresa distribui isso em todas as estações dentro da
> pasta
> > de Autoridades Certificadores Raiz (Root Certificate Authorities)
> >
> > Fora isso em muitos casos o usuário utiliza navegadores como Firefox que
> > tem uma base de dados de CA separada o que aumenta ainda mais a
> dificuldade
> > de se configurar uma solução de interceptação SSL.
> >
> >
> > Em resumo, as chances de você instalar um cache transparente com
> > interceptação SSL são nulas!
> > Só funcionaria se você tivesse condição de distribuir a CA do appliance
> > para todas as maquinas de forma que elas confiassem nesse certificado e
> > isso só vejo acontecer dentro de empresas.
> >
> > Obs: Se a Peerapp fizer isso o usuário irá saber disso quando ele acessar
> > site X ou Y via HTTPS e o certificado tiver sido emitido por uma CA
> > diferente.
> >
> >
> > Abs,
> > Rafael M. Koike
> >
> >
> > Em 10 de fevereiro de 2015 22:57, Márcio Elias Hahn do Nascimento <
> > marcio at sulonline.net> escreveu:
> >
> > >
> > >
> > > Quem começou esse tópico foi eu a um bom tempo, e foi baseado
> > > exatamente em uma publicação em outro fórum de uma suposta
> representante
> > > de vendas (ninguém sai anunciando um produto se não quiser vendê-lo
> > > certo?) publicando explicitamente que a dita versão teria "cache de
> > > HTTPS".
> > >
> > > Justamente por achar um tanto quanto absurda essa afirmação,
> > > ainda mais por parte de uma empresa como a PeerApp é que abri este
> > > tópico, buscando justamente a veracidade destas informações.
> > >
> > > Mais pelo
> > > decorrer do assunto ficou claro que eles não farão isso (pelo menos não
> > > agora), mais sim como o Rubens citou, provavelmente tentarão forçar o
> > > tráfego iniciado em HTTP no youtube a continuar em HTTP não
> > > transformando-se em HTTPS.
> > >
> > > Somente para reforçar o que o colega falou,
> > > também não seria cliente de um provedor que fizesse cache de protocolo
> > > HTTPS.
> > >
> > > ---
> > >
> > > Att
> > >
> > > Márcio Elias Hahn do Nascimento
> > > (48) 8469-1819 /
> > > 3524-0700 - marcio at sulinternet.net
> > > GERÊNCIA DE RECURSOS DE TIC - Sul
> > > Internet [2]
> > >
> > >  [2]
> > >
> > > Em 10/02/2015 19:54, Rubens Kuhl escreveu:
> > >
> > > >
> > > 2015-02-11 1:33 GMT+08:00 Soares <soares at tecnetce.com.br>:
> > > >
> > > >> Eu não
> > > quero ser cliente de uma provedor que tem este função no HTTPS. FAKE no
> > > certificado
> > > >
> > > > Notar que o rumor é de apenas evitar o redirecionamento
> > > do Youtube para
> > > > HTTPS, e não de interceptar o HTTPS.
> > > >
> > > > Rubens
> > > >
> > > --
> > > > gter list https://eng.registro.br/mailman/listinfo/gter [1]
> > >
> > >
> > >
> > > Links:
> > > ------
> > > [1] https://eng.registro.br/mailman/listinfo/gter
> > > [2]
> > > http://www.sulinternet.net
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>