[GTER] PeerAPP Brigde x PBR

[Márcio Elias Hahn do Nascimento]

É Rubens, o que mais me intriga é ver frases como "solução para
cache HTTPS". 

Ao meu ver a "solução" está em PTT, aumento de trânsito
IP, interconexão com parceiros, GGC, Caches próprios como da Akamai,
Netflix se não me falhe a memória também tem alguma coisa, e por ai vai.


Por que diferentemente de vc se colocar entre o client e o server e
manipular/armazenar o conteúdo, é vc ter um peer com o provedor do
conteúdo instalado em sua infra. 

Sobre a autenticidade e
confiabilidade de acesso, é o que justifica a necessidade de instalação
de certificados criados e assinados pelo próprio cache em clientes, por
que sem isso o browser do usuário vai dar tanto aviso á ele na tela que
a navegação vai ficar impossível. 

Não me canso de ver este tipo de
tópico em todos os tipos de listas, e acho que estamos longe de isso
acabar. A menos que todos procurem entender o funcionamento do protocolo
com a criptografia de chaves assimétricas empregada no HTTPS antes de
pensar que isso é um problema e começar a procurar por "soluções".


---

Att 

Márcio Elias Hahn do Nascimento
(48) 8469-1819 / 3524-0700
- marcio at sulinternet.net
GERÊNCIA DE RECURSOS DE TIC - Sul Internet [1]


 [1] 

Em 15/01/2015 00:51, Rubens Kuhl escreveu: 

> 2015-01-15 0:21
GMT-02:00 Márcio Elias Hahn do Nascimento <
> marcio at sulonline.net>:
>

>> Gostaria de uma opinião dos mais experientes. HTTPS. Nunca um mísero
"S" fez tanta diferença, o dito S que praticamente matou, ou está
matando todas as soluções de cache. Pergunto aos mais entendidos, estou
muito equivocado ao afirmar que não existe "solução" para contornar
isso?
> 
> Esse "S" veio por um caso de outro S, o Snowden. Antes dele,
HTTPS era
> exceção; agora, irá se tornar regra.
> 
>> No meu modo mais
simples de ver, o "S" de SSL é justamente para evitar que terceiros
(soluções de cache por exemplo, mais não originalmente com esse
propósito) de interceptarem, e principalmente terem acesso ao conteúdo
trafegado?
> 
> Isso que você descreveu é confidencialidade, mas ele
também dá integridade
> (ao verificar que o tráfego que chegou veio do
emissor) e autenticidade
> (identidade do emissor).
> 
> Ou seja, a
menos que se faça um
> "man-in-the-middle" com o cache
> 
>> nsagens de
advertência sobre o certificado em uso ser diferente do site sendo
acessado, não há como interagir com o conteúdo criptografado. É isso?

>> 
>> Sim, é isso. E ao fazê-lo, você está assumindo para si uma
imensa responsabilidade sobre tr&a
> ensíveis com valor financeiro, como
o acesso a bancos. Vejo em outras listas muitos esperando soluções
milagrosas prometidos por outras empresas (PeerApp é a primeira vez que
vejo aqui) sobre essa 
> 
>> ;o costuma prometer isso, de onde saiu essa
informação ? O que algumas soluções fazem que envolvem criptografia é
com P2P, mas aí a solução entra como um peer participante, n&ati
>
man-in-the-middle. Inclusive interferindo no Marco Civil. 
> 
> Não só
no Marco Civil, mas também em dispositivos já mais antigos como a
> lei
sobre interceptação de comunicações telemáticas.
> http://www.p>
comunicações telef&ocir
> nformática ou telemática, ou quebrar segredo
da Justiça, sem autorização judicial ou com objetivos não autorizados em
lei. Pena: reclusão, de dois a quatro anos, e multa." Não me consta que
cache seja um objetivo autorizado em lei... Uso o Hyper da Thagos e
sofremos com a redução do conteúdo em cache, mais eles ao menos focaram
nesta tecnologia enfatizando a impossibilidade e ilegalidade de fazer
cache destes objetos. 
> 
> Que bom. Eu volta e meia tenho que
argumentar com concorrentes deles que
> insistem em achar que cache de
tráfego criptografado é legal (duplo sentido
> proposital).
> 
>
Rubens
> --
> gter list
 

Links:
------
[1] http://www.sulinternet.net