Futuro do cache com o google apoiando https (ssl)

[crnet]

Marcus, já estamos desenvolvendo uma solução para cache SSL/TLS, ou seja, cache de HTTP(S), fora a detecção de muitos outros protocolos como TORRENT e SPEEDTEST, ..., você pode conferir a DEMO, segue o link com maiores detalhes:

http://community.brbyte.com/forum/view/post/4659

Em breve estaremos disponibilizando outra DEMO, com mais funcionalidades. Esta foi só um demonstração de que estamos emprenhados e provar que ao contrário do que muitos dizem, é possível SIM, fazer interceptação e CACHE de HTTP(S)...

Mais ninguém falou que era impossível, se falou que era ilegal.

[ricromero]

Mais ninguém falou que era impossível, se falou que era ilegal.

Ter que instalar um certificado em cada cliente para "interceptar" na conexão feita pelo cliente não consigo ver com BONS olhos.

[crnet]

Eu quero ver se um cliente processa um banco porque o dinheiro sumiu e a maquina vá para pericia e acham um certificado que seu provedor manda instalar para que possa quebrar uma criptografia, de quem é a culpa?
Outra, se invadem o servidor de cache e começam a interceptar tudo que for HTTPS.

[romulorenatoss]

umq curiosidade quantos clientes voce conseguiu espremer em um link de 100 mega sem cache algum amigo .
se puder passar a media de cliente em planos de 1 mega ea 10 agradeço a atenção.

Bom no caso do meu de 1 a 4 MB tem 369 online com picos de ate 120 megas

[softov]

Mais ninguém falou que era impossível, se falou que era ilegal.

Falaram que não era possível fazer Interceptação seletiva, ou reconhecimento se o cliente tem ou não o certificado instalado.

Interceptação seletiva, você pode escolher interceptar somente um dominio (ex: youtube.com), ou um wildcard (ex: *.youtube.*). Assim, você pode interceptar o Youtube, e NÃO interceptar o Gmail mesmo que estejam hospedados no mesmo IP. O mesmo vale para sites bancários, aonde você pode escolher não interceptar esses sites, ou simplificando, escolher quais sites você deseja interceptar ou não.

E bypass automatico de clientes que não tem certificado, ou seja, o sistema reconhece automaticamente os clientes que não tem certificado, e trata eles como protocolo RAW_SSL, esse serviço é muito útil, pois além de não "atrapalhar" as requisições dos clientes que não tem certificado instalado, você pode marcar TOS (DSCP) para controle de banda.

[MDdantas]

Infelizmente os caches estão com os dias contados. Praticamente "90%" de acessos aos website são feitos por pesquisas do google, como Marcus informou. E isso vai gerar uma complicação maior para os proprietários de ISP´s. Eles procuram uma solução para economizar sua banda, pagam por suas licenças e agora se vêem encurralados, e ainda com a dúvida que incomoda: "Para que terei um cache?". Afinal, a maioria dos internautas hoje só acessam youtube, facebook e todos já utilizam HTTPS (SSL), o que já vêem incomodando. Uma Solução: reciclagem, adaptação...

[gabrielest]

Falaram que não era possível fazer Interceptação seletiva, ou reconhecimento se o cliente tem ou não o certificado instalado.

Interceptação seletiva, você pode escolher interceptar somente um dominio (ex: youtube.com), ou um wildcard (ex: *.youtube.*). Assim, você pode interceptar o Youtube, e NÃO interceptar o Gmail mesmo que estejam hospedados no mesmo IP. O mesmo vale para sites bancários, aonde você pode escolher não interceptar esses sites, ou simplificando, escolher quais sites você deseja interceptar ou não.

E bypass automatico de clientes que não tem certificado, ou seja, o sistema reconhece automaticamente os clientes que não tem certificado, e trata eles como protocolo RAW_SSL, esse serviço é muito útil, pois além de não "atrapalhar" as requisições dos clientes que não tem certificado instalado, você pode marcar TOS (DSCP) para controle de banda.

Muito bom...
Começam as novidades...
Acompanhando...
Obs...contudo gostaria de deixar aqui uma dica a vcs para não terem problemas no futuro visto que estão trilhando o caminho das pedras:
Seria interessante se vcs tivessem uma lista fixa (de forma que não pudesse ser alterada por ninguém, apenas atualizada de tempos em tempos com os novos sites que surgirem e feita atualizações dsiponibilizadas por vcs) de interceptação de site HTTPS, justamente para evitar problemas futuros com sites restritos, ai não poderiam colocar site de banco por exemplo....todos nós sabemos que hoje em dia quem mais "perturba o juizo" dos provedores é o Youtube, e nisso bato palmas pra vcs porque; o google quer empurrar guela a baixo a solução deles por Misero$$$$ dinheiros (eles que vão pra merd@).

[gabrielest]

Infelizmente os caches estão com os dias contados. Praticamente "90%" de acessos aos website são feitos por pesquisas do google, como Marcus informou. E isso vai gerar uma complicação maior para os proprietários de ISP´s. Eles procuram uma solução para economizar sua banda, pagam por suas licenças e agora se vêem encurralados, e ainda com a dúvida que incomoda: "Para que terei um cache?". Afinal, a maioria dos internautas hoje só acessam youtube, facebook e todos já utilizam HTTPS (SSL), o que já vêem incomodando. Uma Solução: reciclagem, adaptação...

Desculpe amigo, não concordo,
Assim como a net é dinamica, os cache também são, na verdade tudo isso é uma manobra pra tirar os pequenos do mercado e ficarem apenas os grandes Google, Facebook,etc..
Porém assim como eles evoluem, os caches também evoluem, abandonar uma solução não é reciclagem e sim desistencia.
Reciclagem e adaptação caminham junto com evolução, conhecimento e perseverança....

" se fosse fácil o caminho das pedras tantas pedras no caminho não seriam ruins"
Um verso simples (alguém sabe de que banda??) que retrata muita coisa.
T+

[gabrielest]

Por enquanto a parte de HTTPS é só pra teste pelo que pude ver.....não faz cache....mas dá pra ter um saborzinho...

[marcioelias]

Marcus, já estamos desenvolvendo uma solução para cache SSL/TLS, ou seja, cache de HTTP(S), fora a detecção de muitos outros protocolos como TORRENT e SPEEDTEST, ..., você pode conferir a DEMO, segue o link com maiores detalhes:

http://community.brbyte.com/forum/view/post/4659

Em breve estaremos disponibilizando outra DEMO, com mais funcionalidades. Esta foi só um demonstração de que estamos emprenhados e provar que ao contrário do que muitos dizem, é possível SIM, fazer interceptação e CACHE de HTTP(S)...

Hummm que massa, nunca acessaria minha conta bancária usando esse sistema, nem compraria um serviço que eu soubesse que emprega esta solução.

Sim é possível, qualquer Squid versão > 3 já dá suporte, eu mesmo já testei (apenas na rede do escritório, com o intuito de controlar o acesso a sites como facebook, etc), se não quiser não precisa instalar os certificados nos clientes mais navegadores mais "inteligentes" como o Chrome, ao identificarem o acesso com certificado que não o fornecido pelo site sendo acessado simplesmente bloqueiam o acesso ao mesmo, e outros navegadores pedem 1001 confirmações de segurança. Um saco.

Minha opinião é, vamos usar cache, esquecer o streaming, jogos online, redes sociais e voltar ao tempo em que as páginas web mais incrementadas eram as que tinham os melhores Gifs kkkk.

Na minha opinião, cache é uma solução que esta perdendo mercado nos dias atuais, é fato, as tecnologias mudam e algumas se tornam obsoletas.

Curiosidade, alguém aqui já visitou uma sala cofre, onde são armazenados certificados digitais de entidades certificadoras confiáveis? Se não, procurem no tio google sobre os requisitos para estas salas, e pra que tudo isso se um cara vai interceptar sua conexão e analisar/armazenar o conteúdo que vc está acessando com esse certificado?

[MarcusMaciel]

Marcus, já estamos desenvolvendo uma solução para cache SSL/TLS, ou seja, cache de HTTP(S), fora a detecção de muitos outros protocolos como TORRENT e SPEEDTEST, ..., você pode conferir a DEMO, segue o link com maiores detalhes:

http://community.brbyte.com/forum/view/post/4659

Em breve estaremos disponibilizando outra DEMO, com mais funcionalidades. Esta foi só um demonstração de que estamos emprenhados e provar que ao contrário do que muitos dizem, é possível SIM, fazer interceptação e CACHE de HTTP(S)...

Olá @softov, O que você está falando não é nenhuma novidade. Instalando certificado na maquina do cliente é simples de se fazer, o que estamos falando aqui é cache de maneira transparente e isso você não pode fazer já que necessita instalar o certificado no navegador do cliente para que o cache funcione.


Ou seja me perdoe, mas solução para o problema não existe, o que existe são "workarounds" que necessitam que o cliente instale o certificado no navegador dele para que o mesmo possa vir a usar o cache em conteudo cryptografado.

Por favor, não esqueça que você precisa pedir autorização individualmente a cada cliente para que o mesmo entenda que o seu conteúdo não estará oficialmente criptografado com a instituição final e sim com o seu servidor de cache e também que é possível que a sua empresa ou a empresa que tem acesso ao servidor de cache leia o conteúdo enviado já que o mesmo estará usando um certificado de sua empresa.

Desta forma creio que por questões legais não seja tão simples quanto vocês estejam pensando...

[naldo864]

fora que instalar certificado cliente por cliente so para economizar banda e meio complicado .
se o provedor tiver 2 clientes ta bom ,agora com 500 , 1000 ,2000 e por ai afora isto não vai funcionar e mesmo que o provedor seja muito insistente em colocar o certificado em todos os clientes .
o cliente pode formatar o computador e bau bau certificado .para min isto e uma gambiara que não tem a minima chance de dar certo .

[softov]

Olá @softov, O que você está falando não é nenhuma novidade. Instalando certificado na maquina do cliente é simples de se fazer, o que estamos falando aqui é cache de maneira transparente e isso você não pode fazer já que necessita instalar o certificado no navegador do cliente para que o cache funcione.


Ou seja me perdoe, mas solução para o problema não existe, o que existe são "workarounds" que necessitam que o cliente instale o certificado no navegador dele para que o mesmo possa vir a usar o cache em conteudo cryptografado.

Por favor, não esqueça que você precisa pedir autorização individualmente a cada cliente para que o mesmo entenda que o seu conteúdo não estará oficialmente criptografado com a instituição final e sim com o seu servidor de cache e também que é possível que a sua empresa ou a empresa que tem acesso ao servidor de cache leia o conteúdo enviado já que o mesmo estará usando um certificado de sua empresa.

Desta forma creio que por questões legais não seja tão simples quanto vocês estejam pensando...

A ferramenta foi desenvolvida inicialmente para atender os provedores que estavam pedindo por uma solução. Apesar de dizer que é simples, desconheço qualquer ferramenta comercial de baixo custo que cumpra o mesmo.

Assim como qualquer outra ferramenta, será útil para alguns e para outros não, mas já vimos o potencial dessa interceptação para controle parental, e ou empresarial.

Creio que com seu conhecimento, sabe-se que o CACHE, não esta limitado ao uso de provedores, assim como temos faculdades, escolas, hoteis, transporadores e muitos outros segmentos de empresas que utilizam do nosso CACHE.

[MarcusMaciel]

A ferramenta foi desenvolvida inicialmente para atender os provedores que estavam pedindo por uma solução. Apesar de dizer que é simples, desconheço qualquer ferramenta comercial de baixo custo que cumpra o mesmo.

Assim como qualquer outra ferramenta, será útil para alguns e para outros não, mas já vimos o potencial dessa interceptação para controle parental, e ou empresarial.

Eu poderia lhe dar vários exemplos, mas vou dar um bem simples você conhece o squid ? OpenSource e gratuito ?

Segue 2 links que vão lhe dar uma ajuda

http://wiki.squid-cache.org/Features/DynamicSslCert
http://wiki.squid-cache.org/Features/SslBump

Meu conhecimento de cache é bem antigo, pois quando fundei o under-linux.org em 2000 creio que fui um dos primeiros a escrever artigos de como compilar, instalar e configurar o squid, alias aqui mesmo no under-linux.org já tivemos vários GUIAS em como usar o squid. Alias vários dos caches que existem no mercado Brasileiro talvez até de o seu nasceu aqui no under-linux.org.

Creio que com seu conhecimento, sabe-se que o CACHE, não esta limitado ao uso de provedores, assim como temos faculdades, escolas, hoteis, transporadores e muitos outros segmentos de empresas que utilizam do nosso CACHE.

E sim tenho conhecimento que CACHE pode ser usado em faculdades, escolas, hoteis, transportadoras e qualquer outro segmento, mas isso não quer dizer que as pessoas destas organizações estão de acordo em usar um Certificado privado para fazer qualquer operação.

Ou quer dizer que você vai pedir pro hospede do hotel instalar um certificado ? ou um aluno da faculdade instalar um certificado ? ou um funcionario de uma transportadora ? Eu podia continuar nisso pra sempre

Apenas para deixar claro acho legal o "workaround" que a sua empresa está fazendo e dou o maior apoio, mas a minha idéia de discussão é que não existe forma transparente (que não tenha que depender do usuário executar uma operação) para fazer CACHE de conteudo cryptografado.

Espero realmente que este não afete seus negocios nem de vários outros amigos como o pessoal do Thundercache, PeerAPP, MARA, etc...

[softov]

Sim.. se alguém encontrar uma solução de interceptação totalmente transparente, vai vender pra NSA, e não publicar num produto de cache de baixo custo.

Conheço os detalhes de implementação do SQUID 3.0, e que eu saiba, não existe forma de fazer implementação seletiva de HTTPS como fizemos (interceptar por ex o YOUTUBE mas BYPASSAR o GMAIL com certificados originais, sendo os dois destinos para o mesmo IP).

Existe forma de fazer isso no SQUID? Ou na verdade a ideia original ali era fazer OFFLOAD de SSL como REVERSE, e ai evoluiu pra uma interceptação de FORWARD, sem seletividade?

[softov]

Segue 2 links que vão lhe dar uma ajuda

http://wiki.squid-cache.org/Features/DynamicSslCert
http://wiki.squid-cache.org/Features/SslBump

Leia com atenção o rodapé da URL que me colou relacionada a DYNAMIC CERTIFICATE

No dynamically generated certificates for intercepted connections

[...]

We believe it is technically possible to implement dynamic certificate generation for transparent connections. Doing so requires turning Squid transaction handling steps upside down, so that the secure connection with the server is established before the secure connection with the client. The implementation will be difficult, but it will allow Squid to get the server name from the server certificate and use that to generate a fake server certificate to give to the client.

Apesar do SQUID dizendo ser tecnicamente possível fazer a implementação, ainda não fizeram.

http://wiki.squid-cache.org/Features/BumpSslServerFirst

This project will not support forwarding of SSL Server Name Indication (SNI) information to the origin server and will make such support a little more difficult. However, SNI forwarding has its own serious challenges (beyond the scope of this document) that far outweigh the added forwarding difficulties.

Lendo esse rodape tambem, vc pode observar que eles ja disseram que nao vao fazer SNI FORWARDING, que eh exatamente oq implementamos

[MarcusMaciel]

Sim.. se alguém encontrar uma solução de interceptação totalmente transparente, vai vender pra NSA, e não publicar num produto de cache de baixo custo.

Conheço os detalhes de implementação do SQUID 3.0, e que eu saiba, não existe forma de fazer implementação seletiva de HTTPS como fizemos (interceptar por ex o YOUTUBE mas BYPASSAR o GMAIL com certificados originais, sendo os dois destinos para o mesmo IP).

Existe forma de fazer isso no SQUID? Ou na verdade a ideia original ali era fazer OFFLOAD de SSL como REVERSE, e ai evoluiu pra uma interceptação de FORWARD, sem seletividade?

Amigo desde sempre o Squid tem opções de ACL, me perdoe mas isso continua sendo bem simples e mesmo que não fosse possível qualquer pessoa com nivel basico em programacao conseguiria fazer um "if domain" para fazer cache ou nao em script usando o squid como base.

Leia com atenção o rodapé da URL que me colou relacionada a DYNAMIC CERTIFICATE



Apesar do SQUID dizendo ser tecnicamente possível fazer a implementação, ainda não fizeram.



Lendo esse rodape tambem, vc pode observar que eles ja disseram que nao vao fazer SNI FORWARDING, que eh exatamente oq implementamos

Eu vou deixar você ler a página mais umas vezes para você entender o que é que eles estão falando, por que eu creio que você não entendeu.... O transparente que ele está falando não é não instalar certificado e sim evitar problemas que você pode ter mesmo com o certificado instalado, Por favor LEIA

Mas apenas para resumir, é impossível fazer o proxy/cache de https sem instalação de certificados na maquina do cliente ou pedir pro cliente usar um proxy na maquina dele

[softov]

Amigo desde sempre o Squid tem opções de ACL, me perdoe mas isso continua sendo bem simples e mesmo que não fosse possível qualquer pessoa com nivel basico em programacao conseguiria fazer um "if domain" para fazer cache ou nao em script usando o squid como base.

Vamos la. Como voce vai usar opcoes de ACL ou fazer um if domain, se no momento da interceptacao voce so tem o IP de destino (o cabecalho HOST so vai ser transmitido depois do HANDSHAKE SSL, no qual voce precisa apresentar um certificado valido PRO DOMINIO que foi digitado no BROWSER). Pode me explicar melhor como seria esse if domain na ACL do SQUID?

Leia la.. Quando ele diz transparente, ele se reporta justamente ao problema de como gerar um certificado PRO DOMINIO ANTES DO HANDSHAKE, se essa informacao faz parte do tunel SSL e so vai trafegar DEPOIS DO HANDSHAKE? Uma solucao pra isso seria usar SNI (Server Name Indication, uma extensao TLS que indica o DOMAIN, para que seja possivel fazer SSL/VHOST e hospedar varios servicos SSL no MESMO IP?

Se voce acessar youtube.com, gmail.com, google.com, todos apontam para o mesmo IP, mas o certificado apresentado por cada um faz relacao ao nome especifico ou dominio ou a um SAN do certificado

Eu vou deixar você ler a página mais umas vezes para você entender o que é que eles estão falando, por que eu creio que você não entendeu.... O transparente que ele está falando não é não instalar certificado e sim evitar problemas que você pode ter mesmo com o certificado instalado, Por favor LEIA

Mas apenas para resumir, é impossível fazer o proxy/cache de https sem instalação de certificados na maquina do cliente ou pedir pro cliente usar um proxy na maquina dele

É sobre isso que ele se refere a transparencia.. E nao a interceptar o SSL TRANSPARENTE (como disse, se tivesse implemetado isso, venderia pra NSA, e nao pra uma solucao de cache). Conseguiu me compreender agora? Como voce resolveria entao o seu problemas com ACL sobre uma informacao que voce ainda nem tem?

[MarcusMaciel]

Quem disse que eu só tenho o ip ? Eu teria só o IP se o cliente não tivesse usando o certificado que você mandou instalar. Com o seu certificado eu tenho acesso ao http header inteiro e o proxy/cache consegue fazer o decrypt de informações em tempo real graças ao certificado instalado. O handshake é feito com o proxy/cache e não com o server final.

Bom vamos lá exemplos:

Creio que isto responda o exemplo de ACL por dominio certo ?


Mais uma vez estou apenas lhe mostrando uma opção, isso poderia ser feito como plugin no squid para pegar no http header enviado pelo cliente que host está se conectando e tomar qualquer atitude desejada.

[softov]

Quem disse que eu só tenho o ip ? Eu teria só o IP se o cliente não tivesse usando o certificado que você mandou instalar. Com o seu certificado eu tenho acesso ao http header inteiro e o proxy/cache consegue fazer o decrypt de informações em tempo real graças ao certificado instalado. O handshake é feito com o proxy/cache e não com o server final.

Creio que isto responda o exemplo de ACL por dominio certo ?

Quando falei de fazer interceptação seletiva, eu quero dizer de interceptar a conexão SSL para o youtube.com, e não interceptar para o gmail.com.

Isso é na negociação do túnel SSL/TLS, antes da comunicação do protocolo HTTP citado, assim a conexão para o youtube.com usaria o certificado CA do Speedr, enquanto a conexão do gmail usaria o certificado da Google.

Assim o cliente pode até conferir quando ele estiver navegando no site da Caixa, ou do Gmail, qual o certificado que está sendo servido para ele, desse modo ele pode garantir que seus e-mails, ou conexões bancárias não estão sendo interceptados, enquanto o youtube sim...

Fora a auto-detecção de certificado, fazendo um bypass da conexão SSL/TLS, para evitar aqueles erros de certificados, para os clientes que não instalaram o certificado ainda.


Você já fez de fato com o SQUID o que está falando, ou apenas leu o tutorial e supos que era simples fazer?