Re: Futuro do cache com o google apoiando https (ssl)
Citação:
Postado originalmente por
MarcusMaciel
Leia com atenção o rodapé da URL que me colou relacionada a DYNAMIC CERTIFICATE
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.
Citaçã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.
Lendo esse rodape tambem, vc pode observar que eles ja disseram que nao vao fazer SNI FORWARDING, que eh exatamente oq implementamos
Re: Futuro do cache com o google apoiando https (ssl)
Citação:
Postado originalmente por
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?
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
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 :)
Re: Futuro do cache com o google apoiando https (ssl)
Citação:
Postado originalmente por
MarcusMaciel
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
Citação:
Postado originalmente por
MarcusMaciel
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?
1 Anexo(s)
Re: Futuro do cache com o google apoiando https (ssl)
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.
Re: Futuro do cache com o google apoiando https (ssl)
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.
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?