Versão Imprimível
É pessoal, como eu já estava imaginando o dia está cada vez mais próximo.
http://googlewebmastercentral.blogsp...ng-signal.html
O google agora dará um ranking maior para paginas com https ou seja a tendência mundial será migrar para https e com isso eu fico na duvida em qual será a utilidade dos caches.
Alguém tem idéia de qual será o futuro dos caches como thundercache, peerapp, speedr e muitos outros se o mundo migrar pra https que na verdade é o que deve ocorrer.
Então qiuer dizer que o cache só serviram para as páginas XXX.:hmmmm: kkkkkkkkkkkk
morrem todos, não vão pagar nem a energia que consomem...
---------------Citação:
Postado originalmente por technorte
Verdade @technorte, sério desde que instalei o windows 8.1 no note ele atualiza quase todo dia é um saco.
E qual a garantia de banda de provedores q usam cache? O MB ta caro assim pra precisar disso? Quem usa cache sabe q eh um paleativo. Tem q ter link...
O problema e link e os clientes que acham que internet e televisao.
Citação:
Postado originalmente por naldo864
Mas ai você vende um plano melhor para seu cliente e ganhar mais com isso.
O próprio MC informou que o problema no Brasil o problema esta entre o cliente e o PTT, isto mesmo! A rede chega no Brasil em alguns Terabits, após o PTT passa para o máximo de 10-40 Gbps, ou seja, se conclui que o problema esta nas operadoras.
Isso do google migrar para https nao indica que tudo na net ira para https.
Isso é apenas taticas do google contra os caches de mercado para que as empresas passem a usar o proprio sistema de cache deles.
Hoje se vc tem link a cima de 500 Megas, vc ja pode contratar o serivço de cache do google, porem vc deve destinar 100 megas dedicado exclusivo a eles.
è otimo, porem o google ira com certeza usar o servidor de cache como nodulo da rede deles nas nuvens.
Acho que você não entendeu... quando você faz uma pesquisa no google o google mostra resultados, logo a maioria dos acessos a websites vem do google e não de acessos diretos.Citação:
Postado originalmente por edmarmega
O que o google está falando no link que eu enviei no inicio deste tópico é que ele vai mostrar nas primeiras posições de resultados de pesquisa os sites que usam https, ou seja, se você quer que seu website apareça primeiro nos resultados de pesquisa do google, você irá querer migrar seu website para https.
Só não irá migrar pra https quem não precisa do google, que no caso de hoje não sei quem seria este...
Creio que o mundo migraria pra https se fosse obrigatório. Caso não seja, muitos não vão querer mais essa despesa com certificado.Citação:
Postado originalmente por MarcusMaciel
Taí uma prova de que o fluxo vai para https. É questão de segurança.
Na verdade tenho observado que se o provedor tem link o cache não vai fazer muita diferença.
Citação:
Postado originalmente por 1929
Carlos, na real se o provedor tiver LINK cache prestará apenas para atualizações do windows, e nesse caso um cache open source fará tudo "de grátis" e não necessitará de servidores estratosféricos.
Eu vejo não como uma obrigatoriedade mas como uma tendência para aprimorar segurança. Por exemplo o Underlinux já passou para https.Citação:
Postado originalmente por Carlosaps
Quem não passar vai ficar para trás e perder o "bonde da história".
Colega MarcusMaciel,
Pelo que entendi, o que o colega Edmarmega quis dizer com relação ao cache do google é a vantagem de ter o cache do Youtube entre outras coisas pois, apesar do youtube ser HTTPS, ele fica no server do google, se vc entrar a fazer parte, com certeza recebera o cache do que é mais solicitado.....
quem não tem link, esta na hora de procurar na cidade um serviço, ou entrar em contato com quem tem para se unirem, pequenos se unindo irá fazer uma grande mudança. Hoje eu tenho 100Mb dedicado e não uso cache, tenho clientes que usam planos de 1Mb, e 10Mb, outros planos dedicado, plano diferencial que oferto 50% de up. Já estou negociando a possibilidade de um link bem maior.
Sinceramente já tinha visto essa tendência, tanto é que depois que o Thunder parou na rede (anos trás, quando eu ainda estava tentando implementar), nem coloquei mais.
A tempos o Google já abre direto na página com https. Youtube se estiver logado no Gmail (eu sempre estou), já sai https. FB também, entao, se os principais servicos que os clientes usam, sao em https, qual o sentido do cache? Logo o Squid voltará a ter serventia.
Complementando, quase todos os sites hoje querem fidelizar seu usuários ou fornecer algum serviço que necessite de autenticação (plugins do Facebook, G+, etc facilitam muito isso), e com isso todos os dados privados devem ser trafegados de maneira segura.Citação:
Postado originalmente por MarcusMaciel
"A internet não é mais como era antigamente" (Renato Russo certa vez cantou uma frase muito parecida, qualquer semelhança é mera coincidência). Antigamente tínhamos um login para acessar nossos e-mails, alias, nosso e-mail, sim tínhamos somente uma conta, ou então senha para acesso ao internet banking, pergunto a vcs, quantos usuários e senhas vcs tem hoje, e em quantos sites, serviços, e plataformas estão interagindo.
Uma pesquisa rápida sobre a WEB 2.0, mostra que a tendência desse novo modelo (novo? desde 2004!!!) é a utilização da web como uma plataforma de serviços e com uma maior interatividade por parte dos usuários, que deixam de ser meros consumidores de conteúdo para participarem de forma ativa na rede.
Concluindo, sobre o futuro dos Caches, não acho que irão morrer, existem empresas grandes por trás de algumas soluções, acho que o que irá morrer é o mercado viável para comercialização do produto nos moldes atuais. Acredito que estas empresas devam estar a algum tempo (muito antes de nós com certeza) cientes deste futuro e estudando novos modelos de negócios para que possam continuar ativas no mercado.
Citação:
Postado originalmente por biohazzard
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.
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:Citação:
Postado originalmente por MarcusMaciel
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.Citação:
Postado originalmente por softov
Citação:
Postado originalmente por crnet
Ter que instalar um certificado em cada cliente para "interceptar" na conexão feita pelo cliente não consigo ver com BONS olhos.
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.
Bom no caso do meu de 1 a 4 MB tem 369 online com picos de ate 120 megasCitação:
Postado originalmente por naldo864
Falaram que não era possível fazer Interceptação seletiva, ou reconhecimento se o cliente tem ou não o certificado instalado.Citação:
Postado originalmente por crnet
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.
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...
Muito bom...Citação:
Postado originalmente por softov
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@).
Desculpe amigo, não concordo,Citação:
Postado originalmente por MDdantas
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+
Por enquanto a parte de HTTPS é só pra teste pelo que pude ver.....não faz cache....mas dá pra ter um saborzinho...
Citação:
Postado originalmente por softov
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?
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.Citação:
Postado originalmente por softov
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...
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 .
Citação:
Postado originalmente por 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.
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.
Eu poderia lhe dar vários exemplos, mas vou dar um bem simples você conhece o squid ? OpenSource e gratuito ?Citação:
Postado originalmente por 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
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.
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.Citação:
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.
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...
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?
Leia com atenção o rodapé da URL que me colou relacionada a DYNAMIC CERTIFICATECitação:
Postado originalmente por MarcusMaciel
Citação:
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.
Lendo esse rodape tambem, vc pode observar que eles ja disseram que nao vao fazer SNI FORWARDING, que eh exatamente oq implementamosCitação:
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.
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.Citação:
Postado originalmente por softov
Citação:
Postado originalmente por softov
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 :)
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?Citação:
Postado originalmente por MarcusMaciel
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
É 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?Citação:
Postado originalmente por 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:
Anexo 54561
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.
Citação:
Postado originalmente por MarcusMaciel
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?
@softov,
Por que você está tentando complicar algo que é obvio e simples ?
Por que eu vou querer usar um certificado pro youtube e outro pro google ? O cliente já teve que instalar o seu certificado pro youtube logo tanto faz qual certificado será usado pro google. Ele não terá visibilidade de nada que está ocorrendo não tem lógica.
O cliente que entende algo de segurança NUNCA iria deixar qualquer certificado ser instalado na maquina dele e o que não entende não precisa saber que um certificado é o seu e o outro é o real do google, logo me perdoe mas sua solução é muito legal, mas não tem diferença no mercado de usuários leigos.
O Squid foi só um exemplo eu realmente nunca implementei esta solução, mas eu nunca falei que queria usar 1 certificado pra uma coisa e o original para outra isso é uma particularidade do seu produto que eu particularmente não vejo necessidade, mas isso é minha opinião pessoal.
Agora pra terminar logo essa sua discussão aqui sem fundamentos me perdoe, mas o que você está tentando provar aqui ? Todos aqui sabem que não existe uma forma de usar cache https sem que o cliente instale um maldito de um certificado sendo assim o que você quer dizer ?
O que estou querendo dizer eh que
1) Voce pode interceptar uma faixa inteira de IPs e enviar para o Speedr. Dentro dele voce pode usar regras relacionadas ao DOMAIN de destino pra decidir interceptar (gerar um certificado novo pro DOMAIN que foi requisitado, e decriptar a conexao) ou deixar a conexao interceptada passar intacta (sem alterar os certificados originais, portanto sem interceptar)
2) Que nao eh possivel voce fazer isso nem com ACL do SQUID nem com "if domain" como voce afirmou, ja que as informacoes de DOMAIN a que voce se refere fazem parte do TUNEL SSL, ao qual o SQUID nao tem acesso usando os mecanismos de ACL disponiveis.
3) O que me leva ao meu ponto final, que eh onde discordamos ha alguns POSTs atras, onde te afirmo que nao conheco ferramenta opensource ou comercial de baixo custo (as que fazem hoje sao BLUECOAT, A10 NETWORKS, etc) que implemente essa solucao. Voce mencionou o SQUID, e eu usei os links que vc me mandou (que ja tinha lido no passado, alias) pra mostrar que voce esta enganado (tanto nisso quanto na questao da simplificacao do "faco um if domain").
4) Voce so tem o IP sim, por que voce precisa criar um certificado para o DOMINIO e apresentar ele para o cliente como parte do processo de HANDSHAKE. Portanto no momento do HANDSHAKE voce ainda nao tem acesso aos cabecalhos HTTP (eles so virao depois, lembra?)
PS: Nao sei se voce compreendeu completamente, mas o certificado CA que eh instalado no dispositivo do cliente eh usado somente para ASSINAR certificados que sao criados pelos DOMINIOS SOLICITADOS em tempo real. Se o cliente pede o youtube.com, o certificado tem que vir pra youtube.com. ASSINADO pela CA do SPEEDR que foi instalada como confiavel. Deu pra entender agora?
Nao estou tentando complicar algo que eh obvio em simples. So estou tentando te mostrar quais sao as reais complexidades relacionadas ao processo, que talvez por nunca ter implementado, voce nao compreendeu por completo
e por isso pensa que eh obvio e simples ;)
Depois dessa grande aula,eu pergunto...
Seria viável realizar algo que possa gerar desconfiança do usuário no provedor?Porque por mais que a ideia seja boa, muitos usuários irão ficar desconfiados.
Ou estou enganado e não entendi nada ?
Citação:
Postado originalmente por davidmilfont
Eu acho que quem tiver um cache dessa forma estará colocando sua cabeça à prêmio.
O provedor terá que ter um advogado muito bom, pois caso ocorra alguma coisa com o cliente o provedor vai ter que vender as calças para pagar.
Amigo você está insistindo nisso. Isso é uma particularidade do seu produto que você considera incrível e eu acho muito bom pra você, porém isso não afasta a necessidade do cliente instalar o certificado ou seja no meu entendimento não muda nada.Citação:
Postado originalmente por softov
Por favor entenda isso, o problema todo é fazer com que o cliente tenha uma ação do seu lado seja configurar um proxy manualmente ou instalar um certificado.
Eu não sei se eu não consigo me expressar corretamente ou se você continua tentando levar tudo pro seu produto.Citação:
2) Que nao eh possivel voce fazer isso nem com ACL do SQUID nem com "if domain" como voce afirmou, ja que as informacoes de DOMAIN a que voce se refere fazem parte do TUNEL SSL, ao qual o SQUID nao tem acesso usando os mecanismos de ACL disponiveis.
3) O que me leva ao meu ponto final, que eh onde discordamos ha alguns POSTs atras, onde te afirmo que nao conheco ferramenta opensource ou comercial de baixo custo (as que fazem hoje sao BLUECOAT, A10 NETWORKS, etc) que implemente essa solucao. Voce mencionou o SQUID, e eu usei os links que vc me mandou (que ja tinha lido no passado, alias) pra mostrar que voce esta enganado (tanto nisso quanto na questao da simplificacao do "faco um if domain").
O uso de ACL para https funciona perfeitamente, porém concordo que existem bugs e limitações quanto ao uso do mesmo no SQUID quando SNI é usado, mas isso não quer dizer que não existam trabalhos neste sentido.
Um projeto que está trabalhando neste sentido é
Exemplo: http://wiki.squid-cache.org/Features/SslPeekAndSplice
E Mais uma vez se você ja instalou o maldito certificado no cliente qual é a diferença? Como eu já disse anteriormente e irei repetir, pro usuário que entende alguma coisa ele nunca iria instalar o seu certificado e pro cliente que não entende, nada não irá mudar.
Amigo eu sei muito bem como isso funciona o fato de eu não ter implementado isso com squid não quer dizer que eu não saiba ler RFC/Specs e não entenda como as coisas funcionam. Concordo que o SQUID possa ter bugs e limitações, porém isso não impede qualquer developer de fazer uma fix pra uma necessidade especifica não concorda ? Alias se não fosse possível você mesmo não conseguiria fazer certo ?Citação:
4) Voce so tem o IP sim, por que voce precisa criar um certificado para o DOMINIO e apresentar ele para o cliente como parte do processo de HANDSHAKE. Portanto no momento do HANDSHAKE voce ainda nao tem acesso aos cabecalhos HTTP (eles so virao depois, lembra?)
PS: Nao sei se voce compreendeu completamente, mas o certificado CA que eh instalado no dispositivo do cliente eh usado somente para ASSINAR certificados que sao criados pelos DOMINIOS SOLICITADOS em tempo real. Se o cliente pede o youtube.com, o certificado tem que vir pra youtube.com. ASSINADO pela CA do SPEEDR que foi instalada como confiavel. Deu pra entender agora?
Nao estou tentando complicar algo que eh obvio em simples. So estou tentando te mostrar quais sao as reais complexidades relacionadas ao processo, que talvez por nunca ter implementado, voce nao compreendeu por completo
e por isso pensa que eh obvio e simples ;)
Agora voltando a sua resposta se o cliente tem instalado o meu CA, qualquer dominio que estiver assinado com o meu CA será válido para este cliente, pois este cliente já tem o meu certificado instalado desta forma é sim tudo obvio e simples e sim você está tentando complicar algo que não tem complicação.
Pare de colocar o uso de SNI como coisa de outro planeta, pois não é lhe garanto que se o pessoal do thundercache, peerapp, Cache Mara etc etc quiser implementar esta porcaria eles implementam. Então me perdoe, mas você o que você tem é um o workaround que continua fazendo com que o cliente tenha que instalar/configurar algo do lado dele.
Amigo, a não ser que você tenha bons advogados, tenha conseguido uma autorização e certificação governamental. Eu não recomendo nunca que você instale certificados nos computadores dos seus clientes.Citação:
Postado originalmente por davidmilfont
Eu deixaria de ser cliente se o meu provedor me solicitasse isso ou eu tivesse conhecimento que isso foi feito.Citação:
Postado originalmente por MarcusMaciel
Sem contar o Marco Civil da Internet, o que vcs acham que eles tratam como "Conexões Privadas"?
"A tempos o Google já abre direto na página com https. Youtube se estiver logado no Gmail (eu sempre estou), já sai https. FB também, entao, se os principais servicos que os clientes usam, sao em https, qual o sentido do cache? Logo o Squid voltará a ter serventia."Citação:
Postado originalmente por EribertoTorres
Poderia dar uma explicada maior neste paragrafo? Obrigado.
Os conteúdos de vídeo do Youtube já estão em https?
Quase 100% (quando meu Hyper ainda me exibia o conteúdo sendo cacheado, youtube tava dando 7% do total em cache somente).Citação:
Postado originalmente por surfinhu