Vamos falar sobre o Google Data Saver, o serviço de economia de dados do google que promete comprimir os conteúdos de sites terceiros não encriptados permitindo assim uma redução no uso de dados pelo usuário.

Nesta primeira parte, faremos uma análise do fluxo de sinalização que o Google Data Saver utiliza para realizar a navegação via Proxy. Através desta análise vamos também identificar como este serviço pode afetar os usuários de dados móveis e serviços providos pela operadora de celular e traremos uma solução para operadoras e provedores de Internet a fim de contornar esta possível afetação.

Primeiro, pegaremos a descrição que o próprio Google utiliza para falar sobre este serviço oferecido aos usuários.

As principais otimizações que nos permitem reduzir o uso geral de dados são realizadas pelos servidores do Google. Quando a Economia de dados está ativada, o Google Chrome abre uma conexão entre seu telefone e um dos servidores de otimização em execução nos datacenters do Google e retransmite todas as solicitações HTTP não criptografadas por meio dessa conexão.

Podemos entender que o Google Chrome só direciona o tráfego não criptografado para o serviço Google Data Saver. Isto é bem importante, pois desta maneira fica claro que o Google não está realizando um MITM (Man in the Middle), o que poderia ficar sob suspeita caso o Google Data Saver estivesse sendo usado também para conteúdos HTTPS onde os protocolos SSL/TLS são utilizados para criptografar o conteúdo de camada 7.

Tirando essa pulga de trás da orelha, podemos começar a analisar o funcionamento deste serviço.

Para efetuar tal análise, realizamos um tcpdump de uma navegação online utilizando o navegador Google Chrome com o serviço Data Saver habilitado conforme abaixo.

 

Análise

Para iniciar o serviço de Data Saver, o Google Chrome consulta o domínio check.googlezip.net e envia um HTTP GET para a URL check.googlezip.net/connect. Esta conexão é realizada apenas para o Chrome entender se ele irá utilizar o servidor do domínio proxy.googlezip.net ou do domínio compress.googlezip.net.

 

O domínio proxy.googlezip.net é utilizado quando a requisição HTTP para a URL check.googlezip.net/connect retorna uma resposta com código 200 (OK).

Neste cenário o navegador irá iniciar uma conexão HTTPS com os servidores de proxy do google, utilizando o protocolo TLSv1.2. Após esta conexão, toda requisição HTTP feita pelo Google Chrome é realizada através do proxy, tornando toda a navegação criptografada. Perceba que o Google Chrome fecha 6 conexões TCP com o proxy, na figura abaixo podemos ver o procedimento de Three-Way Handshake entre o Google Chrome e o servidor Proxy do Google Data Saver.

O estabelecimento destas 6 conexões é uma característica do protocolo SPDY desenvolvido pelo próprio Google, este protocolo utiliza multiplexação e paralelização para acelerar o carregamento de uma página. Vamos estudar mais a fundo este protocolo em outro artigo, por enquanto seguimos com a análise.

Após estabelecimento das conexões TCP, dá-se início às conexões TLS. Essas conexões são utilizadas para criptografar todo o tráfego de camada 7, como observamos no início deste artigo. As conexões TLS são estabelecidas em cima das conexões TCP que vimos anteriormente, portanto veremos as mesmas portas de origem (5013,5014,5015,5016,5017 e 5018).

É interessante notar que com a utilização do proxy, o Chrome não realiza consultas DNS, logo o provedor de Internet fica sem qualquer visibilidade do que seu assinante está acessando.

 

Você pode estar pensando: “Que ótimo, desta maneira estou realizando uma navegação privada mesmo quando acesso conteúdos não criptografados”.

Essa afirmação, é “meio” verdadeira, pois apesar do seu provedor de internet estar completamente agnóstico aos conteúdos HTTP acessados, o Google não está, ou seja, todo o conteúdo acessado é visto e processado pelos servidores desta gigante da Internet. Além disso, quando se trata de operadora de telefonia móvel, muitas utilizam tarifação diferenciada para conteúdos de parceiros e para seus próprios portais, ou seja, nestes casos ao invés de estar sendo beneficiado, você poderá estar sendo prejudicado pela utilização deste serviço de Data Saver uma vez que será impossível que sua operadora identifique qual conteúdo esta sendo acessado.

Pensando nos provedores de internet, além de uma própria solução de resiliência do serviço, a Google implementou uma forma de evitar a utilização de HTTPS nas conexões com o Proxy Data Saver.

Até agora falamos do comportamento do Google Data Saver quando a URL check.googlezip.net/connect retorna resposta com código 200.

Neste cenário o navegador irá iniciar uma conexão HTTPS com os servidores de proxy do google, utilizando o protocolo TLS 1.2.

Vamos agora elucidar a solução para as operadoras de telefonia móvel bem como para provedores de internet que por um motivo ou outro precisam ter acesso ao conteúdo HTTP do assinante. Para que fique claro, irei enumerar dois motivos pelos quais os provedores precisariam ter acesso aos conteúdos HTTP do assinante:

  1. Utilização de “Seamless Authentication”
    • Teremos um artigo para tratar apenas desta solução, por hora, diremos que o provedor poderá incluir algum cabeçalho HTTP na requisição HTTP feita pelo navegador a fim de autenticar seu assinante em algum portal.
  2. Tarifação Diferenciada
    • Grandes portais que oferecem serviços podem fechar acordos com os provedores para que o acesso aos seus conteúdos não seja cobrado ao assinante, para realizar esta isenção é preciso classificar o tráfego no Gateway do provedor, isso geralmente é feito utilizando-se a URL acessada via HTTP.

Uma das maneiras de evitar a criptografia nas conexões entre o Google Chrome e o Proxy Data Saver é bloquear a requisição HTTP para a URL check.googlezip.net/connect e enviar um TCP com a Flag “Reset” tanto para o servidor quanto para o Google Chrome.

É importante ressaltar que as mensagens TCP Reset vistas acima, são emitidas pelo Gateway.

Quando navegador Google Chrome recebe esta pacote TCP, o mesmo consulta o domínio compress.googlezip.net o qual não faz uso de criptografia para navegação HTTP.

Antes de iniciar a utilização do proxy para requisições HTTP, o Chrome inicia uma conexão TCP com o servidor do domínio compress.googlezip.net com o único fim de garantir a disponibilidade do serviço. Após esta conexão, o Chrome inicia uma conexão TCP para cada requisição HTTP nova, perdendo-se boa parte da otimização obtida através do protocolo SPDY.

 

Portanto, para garantir a diferenciação de tarifação, bem como qualquer outro serviço que a operadora fornece ao usuário baseado no conteúdo acessado, é necessário responder requisições HTTP para a URL check.googlezip.net com um código diferente de 200 ou cancelar a conexão TCP com o servidor check.googlezip.net. Esta informação pode ser encontrada no site do Google Data Saver.

Desativando Criptografia
Por padrão, a conexão entre o navegador e o proxy está em um canal criptografado. Um administrador de rede pode restringir o uso de criptografia para um usuário específico, bloqueando o acesso a um URL (http://check.googlezip.net/connect) e retornando uma resposta diferente de um código de status 200 com um corpo de resposta de OK. Conforme descrito abaixo, o Chrome envia uma solicitação clara para este URL antes de se conectar ao Proxy. O URL é usado apenas para essa finalidade e não oferece nenhum outro conteúdo.

Como o downgrade para HTTP não permite que o Proxy use HTTP / 2 e outros aprimoramentos no nível do protocolo, isso acarretará uma penalidade de desempenho para o usuário.

É preferível enviar uma resposta imediata para o URL, em vez de induzir um tempo limite de conexão ou DNS, o que não desabilitará o uso do Proxy.

Conforme documentação apenas bloquear a requisição HTTP não garante a desativação da criptografia.

Se a solicitação do URL atingir o tempo limite ou ocorrer um erro de DNS, o Chrome usará uma conexão proxy criptografada.

Portanto sugere-se que seja utilizada a solução de TCP Reset ou o bloqueio de qualquer tráfego cujo destino seja servidores pertecentes ao domínios check.googlezip.net.