Re: Futuro do cache com o google apoiando https (ssl)
@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 ?
Re: Futuro do cache com o google apoiando https (ssl)
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 ;)
Re: Futuro do cache com o google apoiando https (ssl)
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 ?
Re: Futuro do cache com o google apoiando https (ssl)
Citação:
Postado originalmente por
davidmilfont
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 ?
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.
Re: Futuro do cache com o google apoiando https (ssl)
Citação:
Postado originalmente por
softov
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)
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.
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.
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").
Eu não sei se eu não consigo me expressar corretamente ou se você continua tentando levar tudo pro seu produto.
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.
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 ;)
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 ?
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.
