Google will start boycotting insecure websites

Uma das minhas primeiras publicações neste blog é sobre encriptação. Curiosamente, também é a publicação #1 de quem cai aqui direto do Google, o que dá um pouco abaixo dos 10% dos leitores. Na época, meu interesse por encriptação havia nascido por causa do Pré-Universitário Comunitário Rubem Alves, que passaria a automatizar na nuvem tarefas que antes eram desempenhadas por seres humanos (como efetivação de matrículas, controles de frequência e distribuições de notas de redação) por conta da falta de mão-de-obra qualificada que enfrentávamos quando um dos coordenadores precisou se mudar do Rio de Janeiro a trabalho. A partir do momento em que dados sensíveis de alunos e voluntários passariam a ser transmitidos pela rede, tive a preocupação de que eles não pudessem ser espionados pelos operadores da infraestrutura de rede. 

Apesar disso, não teve nada de pioneiro na minha atitude. A praticamente um ano atrás, encriptação para sites comuns (que não transferem informações sensíveis pela rede) não era mais uma novidade. Realmente novo à época, só a notícia de que o Google havia conseguido a primeira colisão do algoritmo SHA-1, o que infelizmente significava que milhões de sites (já considerados inseguros) que ainda usavam esta velharia estavam oficialmente em perigo. O ano de 2018 repete os passos do passado e começa, mais uma vez, com uma notícia bombástica do próprio Google: depois de anos avisando que passaria a boicotar sites não-encriptados, a multinacional californiana parece ter escolhido uma data. A partir de julho, com o lançamento da versão 68 do Chrome, todos os sites que carregam recursos via porta 80 (HTTP) serão marcados pelo navegador como Inseguros.

OBS: embora esta imagem seja do próprio Google, o aviso atualmente um vermelho bem mais agressivo.

É possível adiar?

Eu não apostaria em engenharia social para conseguir uma extensão desta data. Independentemente da métrica utilizada, é fato consumado que mais da metade do tráfego da web passa pelo navegador do Google. A maioria dos usuários também atualiza para a última versão com bastante agilidade, provavelmente porque permitiu as atualizações automáticas (configuração padrão). É praticamente certo que estes usuários confiarão mais na mensagem do navegador do que no autor do site e tomarão a via de saída mais próxima. 

Fonte: GlobalStats statcounter

Atualmente, o aviso de Inseguro é mostrado somente em sites que carreguem recursos via porta 80 (HTTP) e utilizem formulários <input type="password" /> ou que sejam identificados como de cartões de crédito. A partir de julho, mesmo sites completamente estáticos e/ou que não transfiram informação sensível entre usuário e servidor começarão a ser marcados para o iminente boicote que virá a seguir, já que, nas palavras de Emily Schechter, gerente de segurança do departamento de segurança do Chrome, o objetivo é "continuar a mover em direção a uma web HTTPS segura por padrão". Nas palavras dela, cerca de 30% da web deverá se adequar às novas regras ou aceitar a excomunhão.

Contratar o certificado SSL não será mais suficiente. Se um site carregar imagens ou scripts externos via porta 80 (HTTP), o que é bastante comum, terá a letra escarlate marcada na testa. Caçar e substituir estas requisições perdidas por aí é um processo longo, custoso e cansativo: mesmo o maior site dedicado a programadores do mundo, o Stack Overflow, levou 4 anos para completar a transição. Nick Craver, arquiteto-chefe do site, lembra no artigo que não basta só garantir que o conteúdo dos autores seja seguro, mas também garantir que o conteúdo enviado pelos usuários (fotos, textos, links) também trafeguem pela porta 443 (HTTPS). Garantir que o conteúdo alheio adeque-se a regras que não existiam antes significa removê-lo se preciso for, o que muitos considerarão como censura

Outro problema serão os redirecionamentos. Muitos dos sites mais populares da web optaram por oferecerem versões seguras (HTTPS/443) e inseguras (HTTP/80) do próprio conteúdo. A partir de julho, eles precisarão remover o acesso via porta 80, o que automaticamente quebrará favoritos e links salvos em outras plataformas (como o Facebook), e redirecioná-lo para a porta 443. Esta mudança não será indolor. O Google aqui afaga com a mão direita (o navegador) e agride com a mão esquerda (o buscador), porque o algoritmo de classificação da relevância das páginas considera redirecionamentos como um indício de conteúdo suspeito (spam) e há de chutá-los para o mundo dos mortos a segunda página de buscas. A internet deve ficar ainda mais concentrada nas mãos dos grandes sites, infelizmente, porque a maioria destes já implementou seus redirecionamentos com sucesso. Faça o teste: tente acessar http://facebook.com ou http://twitter.com e observe o redirecionamento automático em ação. 

Quem será afetado?

A internet brasileira está particularmente vulnerável. Das grandes operadoras de celular, por exemplo, só a Claro oferece todos os seus serviços via porta 443 (HTTPS). A partir de julho, celulares e computadores usando o Chrome terão dificuldades em acessar os sites de Oi, TIM Brasil e Vivo.

A TIM sequer exige cadastro antes de enviar dados de cartão de crédito sem encriptação.

A Vivo também não exige cadastro mas oferece a opção.

Os grandes portais de notícias, ironicamente, também contam com representantes desatualizados. A situação é bastante preocupante, já que portais de notícias frequentemente utilizam links internos em suas reportagens e caçá-los até julho será uma tarefa hercúlea.

No domínio das redes sociais, praticamente todos os serviços estão adequados à mudança. Os aplicativos de mensagens instantâneas e os sites de relacionamentos mais populares não correm risco. A única fonte de preocupação são os sites pessoais independentes (que dependem de intervenção manual do dono e do responsável técncio) e, ainda mais ironicamente, o Blogspot, serviço que pertence ao próprio Google.

Minha maior preocupação, no entanto, está nos serviços oferecidos pelas universidades brasileiras, que são sabidamente lentas em adotar padrões de segurança na web. A data, em especial, será um grande problema, porque cairá nas férias escolares e colidirá com as inscrições em disciplinas dos alunos do segundo semestre. Das 10 universidades que procurei aleatoriamente na web, só UFRJ, UFMG e UFPE redirecionam e servem corretamente páginas via porta 443 (HTTPS), enquanto todas as outras serão marcadas como Inseguras.

Os serviços onde segurança é um fator crítico (email, operações financeiras, armazenamento de documentos e fotos, etc) não serão afetados pela mudança porque já fizeram a migração para a porta 443 há muitos anos. Boa parte deles, especialmente os já nascidos na era da Web 2.0, nunca nem ofereceu acesso via porta 80, que já é considerada insegura há pelo menos uma década.

O que fazer?

Para o usuário da web, não há nada a fazer além de esperar. A mudança ocorrerá automaticamente e os sites que falharem em se adaptar serão silenciosamente censurados e bloqueados da internet. Mudar de navegador por causa disso não é uma opção a longo prazo, já que é apenas uma questão de tempo até que os demais sigam o mesmo caminho. Ficarei genuinamente espantado se Microsoft, Mozilla e Apple não implementarem mudanças similares até o final do ano. Apesar disso, recomendo a migração para o novo Firefox, não por ser mais leniente com sites inseguros, mas por ser mais rápido e eficiente mesmo

Para os produtores de conteúdo, fica aqui o apelo de serem mais criteriosos com as plataformas que escolhem para divulgarem o próprio trabalho. Se tiverem de migrar, escolham serviços que não esperem até a última hora para fazerem atualizações de segurança. Se o problema só agora veio a público, o meio técnico já estava ciente de que a marcação desta data era inevitável há anos.

Para os desenvolvedores e administradores de sistemas, isto não deve ser mais novidade. Ainda assim, o Google publicou uma extensão do Chrome para auditar páginas e procurar pacotes que ainda estão trafegando por HTTP. Quem estiver utilizando infraestrutura própria ou alugada (IaaS, como os serviços DigitalOcean e Linode), precisa reconfigurar o servidor se quiser utilizar o Let's Encrypt (que é grátis). Para quem estiver usando a stack Linux/gunicorn/nginx/Django, preparei um passo-a-passo que deve simplificar o processo

Sites que operam sobre infraestrutura de caixa preta (comum em serviços PaaS como o Heroku, ou em hospedagens gratuitas de sites estáticos) precisarão da autorização e/ou intervenção direta do administrador do sistema, que pode cobrar pelo serviço. Talvez seja a hora de migrar para um servidor virtual privado (VPS), que só precisa ser configurado uma única vez, é fácil de modificar e não incorre em custos adicionais inesperados. É muito mais fácil do que parece, e mesmo usuários não-técnicos conseguem instalar e operar seus próprios sites sem a necessidade de contratar um administrador de sistema só para isso.

Ademais, só nos resta esperar e torcer para que a transição seja o mais suave possível. Agora, se me dão licença, preciso avisar meu chefe que o site da empresa está marcado como Inseguro...


 

Comments

There are currently no comments

New Comment