Página 3 de 4 PrimeiroPrimeiro 1234 ÚltimoÚltimo
+ Responder ao Tópico



  1. #41
    Under-linux.Org Team Avatar de MarcusMaciel
    Ingresso
    Dec 2000
    Localização
    Boston
    Posts
    1.970
    Posts de Blog
    44

    Padrão 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 ?

  2. #42

    Padrão 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



  3. #43

    Padrão 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 ?

  4. #44
    Ricardo Romero Avatar de ricromero
    Ingresso
    Apr 2008
    Localização
    São Paulo / Interior
    Posts
    920

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Citação Postado originalmente por davidmilfont Ver Post
    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.



  5. #45
    Under-linux.Org Team Avatar de MarcusMaciel
    Ingresso
    Dec 2000
    Localização
    Boston
    Posts
    1.970
    Posts de Blog
    44

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Citação Postado originalmente por softov Ver Post
    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.



    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.



    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.

  6. #46
    Under-linux.Org Team Avatar de MarcusMaciel
    Ingresso
    Dec 2000
    Localização
    Boston
    Posts
    1.970
    Posts de Blog
    44

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Citação Postado originalmente por davidmilfont Ver Post
    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 ?
    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.



  7. #47

    Padrão

    Citação Postado originalmente por MarcusMaciel Ver Post
    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.
    Eu deixaria de ser cliente se o meu provedor me solicitasse isso ou eu tivesse conhecimento que isso foi feito.

    Sem contar o Marco Civil da Internet, o que vcs acham que eles tratam como "Conexões Privadas"?

  8. #48

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Citação Postado originalmente por EribertoTorres Ver Post
    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.
    "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."

    Poderia dar uma explicada maior neste paragrafo? Obrigado.



  9. #49

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Os conteúdos de vídeo do Youtube já estão em https?

  10. #50

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Citação Postado originalmente por surfinhu Ver Post
    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).



  11. #51

    Padrão

    Olhem o número de sessões ativas, e o número de clientes de streaming.

    Clique na imagem para uma versão maior

Nome:	         2014-09-09_224318.png
Visualizações:	83
Tamanho: 	18,1 KB
ID:      	54584

    Uma coisa tenho que admitir, pelo menos eles não tem intenção de fazer cache HTTPS.

  12. #52

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Citação Postado originalmente por marcioelias Ver Post
    Quase 100% (quando meu Hyper ainda me exibia o conteúdo sendo cacheado, youtube tava dando 7% do total em cache somente).
    Sério isso, amigo? Putz, estamos mesmo sem saída! =/

    Mesmo que consigam desenvolver o cache transparente (total ou seletivo), o Marco Civil vai ser o calcanhar de aquiles dos provedores, não?



  13. #53

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    E enquanto isso, o que se faz com o Servidor de Cache que tava uma belezura? Deixa rodar assim mesmo e vai pagando suas mensalidades? Ou formata e instala o windows 8? ;-(
    Mas falando sério mesmo, o que fazemos diante disso?

  14. #54

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Citação Postado originalmente por KevinMitnick Ver Post
    E enquanto isso, o que se faz com o Servidor de Cache que tava uma belezura? Deixa rodar assim mesmo e vai pagando suas mensalidades? Ou formata e instala o windows 8? ;-(
    Mas falando sério mesmo, o que fazemos diante disso?
    Windows 8 em uma máquina com valor equivalente a um carro popular é foda... Compramos Link, tranporte para PTT-SP (esse sim da economia), formamos PTT's regionais entre provedores para juntar a banda necessária e pedir um GGC, trocar tráfego com Akamai, etc, etc.

    Pra quem realmente quer vender banda, tem que comprar, seja transito puro, ou transporte PTT. Quer vender, tenha estoque! É a vida.



  15. #55

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Sim... esse é o caminho Técnico e Lógico para a solução (É SÓ CONTRATAR LINK)
    Agora para Provedores que estão localizados em regiões desprovidos de Infraestrutura de Link ou onde AINDA É VENDIDO O MEGA A R$ 3.500,00, Ai esse DISCURSO não se adequa. Temos que ser coerente com o cenário de cada realidade.

  16. #56

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Peguei uns vídeos do Youtube, testei aqui com o Lusca e consegui alguns HITs:
    Clique na imagem para uma versão maior

Nome:	         Krbt37u.png
Visualizações:	95
Tamanho: 	197,3 KB
ID:      	54586

    Será que ainda tem esperança pro Youtube, pelo menos?



  17. #57

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Citação Postado originalmente por kamui Ver Post
    "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."

    Poderia dar uma explicada maior neste paragrafo? Obrigado.
    Quando você abre seu navegador, e tem a home page definida para http://www.google.com.pe, ele sozinho te manda para https://www.google.com.pe/?gws_rd=ssl.

    Eu tenho uma conta no Gmail, que é da Google. O Youtube também é da Google. Ambos funcionam com uma conta da Google, que no meu caso é o meu e-mail do Gmail. A alguns meses, quando você abria o Youtube, ele funcionava sem o https, abria como http://www.youtube.com e só abria como https://www.youtube.com se você estivesse com a conta do gmail abera, ou na mesma aba do navegador ou em outra aba do navegador.

    Quer dizer, antes, o Youtube só abria em https se você estivesse logado na tua conta do Google, hoje, abre direto no https.

    O Facebook nunca tinha prestado atencao, mas hoje ao menos ele já abre direto como https://www.facebook.com

    Os servidores web cache nao "cacheiam" arquivos enquanto a navegacao é feita usando o protocolo https, logo, os caches do mercado nao cacheiam quando a navegacao é feita em https, portanto a economia do cache vai cair, já que a maioria dos servicos que os clientes usam estao em https.

    Como muitos nao poderao usar os recursos de cache dinâmico, nao terá sentido pagar um cache, ai o Squid passará a servir, sendo utilizado para cachear atualizacoes do Windows, anti-virus, e sites XXX que ainda nao sejam https.

  18. #58

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Citação Postado originalmente por KevinMitnick Ver Post
    Sim... esse é o caminho Técnico e Lógico para a solução (É SÓ CONTRATAR LINK)
    Agora para Provedores que estão localizados em regiões desprovidos de Infraestrutura de Link ou onde AINDA É VENDIDO O MEGA A R$ 3.500,00, Ai esse DISCURSO não se adequa. Temos que ser coerente com o cenário de cada realidade.
    Cara, a vida é cruel, cada um tem que dançar conforme a música que toca. Infelizmente os provedores de conteúdo não levam em conta o valor agregado de conexão regional na hora de entregar seus serviços, isso é um fato. Complicado é pagar R$ 3500,00/Mega enquanto outros com possibilidade de contratação a R$ 100,00/Mega revendem ADSL (pensando...).

    Citação Postado originalmente por surfinhu Ver Post
    Peguei uns vídeos do Youtube, testei aqui com o Lusca e consegui alguns HITs:
    Clique na imagem para uma versão maior

Nome:	         Krbt37u.png
Visualizações:	95
Tamanho: 	197,3 KB
ID:      	54586

    Será que ainda tem esperança pro Youtube, pelo menos?
    Nem todos os conteúdos de streaming do youtube estão usando conexões HTTPS, como disse em uma resposta anterior, tinha em média de 7% da economia total atrelada a conteúdo do youtube.

    Segundo informações que tenho, esse (maldito para uns) "Szinho" do HTTPS não é apenas 1 byte a mais na URL, envolve muita infraestrutura para gerenciamento de certificados e criptografia de conteúdo, envolve a atualização de todos os mirrors do youtube (que devem ser mais de 2 rsrs) envolve mais processamento e consequentemente mais $$$, por estes motivos nem todo conteúdo do youtube está sendo entregue usando HTTPS.

    Agora, isso é uma tendência. Fato.



  19. #59

    Padrão

    Não sei quanto a vocês ai... mas notei que apesar de estar a pagina em HTTPs, o googlevideo ainda lidera os acessos.
    Clique na imagem para uma versão maior

Nome:	         top dominio.jpg
Visualizações:	352
Tamanho: 	85,3 KB
ID:      	54588

    Em todo caso, não existe apenas o youtube e facebook.
    Tem atualizações dos windows (todos os clientes possuem windows), atualização antivírus, adobe, netflix (cada dia que passa mais e mais gente contrata), entre outros.
    Pago R$ 200,00 e pouco na licença do thunder.

    Pago R$ 200,00 no mega.

    o Cache me dá uma economia de no minimo uns 4 mega, chegando a pico de 20 mega.
    Ao meu ver, estou tendo pelo menos 1 mil real de economia

  20. #60

    Padrão Re: Futuro do cache com o google apoiando https (ssl)

    Citação Postado originalmente por AndrioPJ Ver Post
    Não sei quanto a vocês ai... mas notei que apesar de estar a pagina em HTTPs, o googlevideo ainda lidera os acessos.
    Clique na imagem para uma versão maior

Nome:	         top dominio.jpg
Visualizações:	352
Tamanho: 	85,3 KB
ID:      	54588

    Em todo caso, não existe apenas o youtube e facebook.
    Tem atualizações dos windows (todos os clientes possuem windows), atualização antivírus, adobe, netflix (cada dia que passa mais e mais gente contrata), entre outros.
    Pago R$ 200,00 e pouco na licença do thunder.

    Pago R$ 200,00 no mega.

    o Cache me dá uma economia de no minimo uns 4 mega, chegando a pico de 20 mega.
    Ao meu ver, estou tendo pelo menos 1 mil real de economia

    Então, com o Hyper eu tenho uma média de economia de 12 a 40M (picos de aproximadamente 500M de consumo). E meu custo é aproximadamente 60% menor que o seu por mega. Agora quando vc conseguir chegar ao PTT-SP pagando transporte até 60% mais barato que o transito e ver seu link cair 50% instantaneamente vc vai ver o que é a economia nos dias atuais.

    Quem ainda não está no PTT, deve veemente tentar chegar lá.