O site tem HTTPS. Posso confiar nele?

«Tem HTTPS. Deve ser seguro.»

Recebemos uma mensagem sobre uma encomenda. Falta pagar uma pequena taxa para a entrega avançar. Abrimos a ligação, encontramos um logótipo conhecido e o endereço começa por https://.

O browser até indica que a ligação é segura. Então podemos introduzir os dados do cartão, certo?

É precisamente aqui que convém parar.

A recomendação de procurar o HTTPS tem uma razão de ser. O problema aparece quando a transformamos numa garantia sobre tudo o que está dentro do site. Ligação segura e site de confiança não significam a mesma coisa.

Gosto de pensar no HTTPS como um envelope fechado. Dificulta que alguém leia ou altere a mensagem pelo caminho. Mas não escolhe o destinatário por nós. Se enviarmos o envelope a um burlão, ele continua a recebê-lo. Apenas chega muito bem fechado.

O que protege, afinal, o HTTPS?

O HTTPS permite trocar informação entre o browser e o site através de uma ligação protegida por um protocolo chamado TLS. Não precisamos de decorar a sigla; interessa perceber as três funções principais:

• Cifragem: dificulta que terceiros no percurso leiam o conteúdo da comunicação, como palavras-passe ou dados de um formulário.
• Integridade: protege a comunicação contra alterações pelo caminho que passem despercebidas.
• Autenticação do destino: o browser verifica o certificado apresentado para o endereço a que está a ligar-se, segundo as suas regras de confiança.

Quando estas verificações funcionam, temos proteção no transporte dos dados até ao destino indicado. A Mozilla explica estes indicadores de segurança da ligação.

O pormenor decisivo é esse: até ao destino indicado. Se o endereço pertencer a um site falso, uma ligação HTTPS válida pode entregar-lhe os nossos dados de forma protegida. O problema já não está em alguém os intercetar pelo caminho. Está em quem os recebe.

O certificado não passou a loja a pente fino

Um certificado usado numa ligação HTTPS não é um certificado de boa conduta.

Nos certificados de validação de domínio, uma modalidade comum, a emissão verifica o controlo do domínio. Isso não equivale a investigar a honestidade de uma loja, testar todos os seus programas ou confirmar que vai entregar a encomenda.

A própria Let’s Encrypt explica que emite certificados de validação de domínio e contempla a denúncia de sites que os usam para phishing ou malware. A existência dessas situações ajuda a desfazer a ideia de que HTTPS e fraude são incompatíveis.

Por isso, um site com HTTPS pode pedir-nos a palavra-passe numa página falsa, disponibilizar um ficheiro malicioso ou aceitar dinheiro por um produto que nunca envia. Um site legítimo também pode ter vulnerabilidades ou ser comprometido. A proteção da ligação não faz uma auditoria à aplicação que está do outro lado.

E os dados não ficam invisíveis para quem gere o site. Se os introduzirmos num formulário, esse serviço recebe-os para os tratar. O HTTPS protege a viagem; não determina o que o destinatário faz depois.

Vamos voltar à encomenda

Imaginemos este cenário: a mensagem diz que a entrega fica bloqueada se não pagarmos uma taxa nas próximas horas. Estamos à espera de uma compra e o valor pedido parece insignificante.

A página tem o logótipo da transportadora, uma fotografia de uma carrinha e um formulário bem apresentado. Não há erros de português que saltem à vista. O HTTPS funciona.

O que falta confirmar?

Se estamos realmente no site da transportadora e se aquele pedido corresponde a uma situação verdadeira.

O logótipo não responde a isso: pode ser copiado. O aspeto profissional também não. E o certificado pode ser perfeitamente válido para o domínio usado na burla.

Neste cenário, eu fecharia a página e abriria a aplicação da transportadora ou um endereço oficial que já conhecesse. Consultaria a encomenda por aí, sem voltar à ligação da mensagem. Se fosse necessário contactar o apoio, procuraria o contacto nesse canal, não no formulário suspeito.

O valor pequeno também não torna o pedido inofensivo. O formulário pode estar interessado em mais do que aqueles cêntimos: os dados do cartão, uma palavra-passe ou um código de autorização podem ser o verdadeiro objetivo.

A urgência tem outra função: tirar-nos o tempo para fazer estas perguntas. A encomenda parece ter pressa. Quem enviou a mensagem também.

O endereço merece mais atenção do que o logótipo

Comparemos estes dois endereços fictícios:

https://transportadora.example/entrega
https://transportadora.example.confirmacao.example/entrega

Nos dois aparece a palavra «transportadora». Nos dois aparece HTTPS. Mas, no segundo, o domínio é confirmacao.example; a parte transportadora.example foi colocada antes, como subdomínio. Não transforma esse endereço no primeiro.

O final .example está reservado para exemplos; estes endereços não representam transportadoras reais.

Não precisamos de transformar cada visita numa aula sobre domínios. Vale, porém, a pena abrir o endereço completo e comparar com o endereço oficial conhecido. A palavra certa algures no URL não chega. Um nome parecido, uma letra trocada ou palavras como «seguro» e «verificado» também não provam quem está do outro lado.

No telemóvel, onde parte do endereço pode ficar escondida, este cuidado é especialmente útil. Se continuarmos com dúvidas, é preferível entrar pelo canal que já conhecemos a tentar adivinhar se aquele nome comprido merece confiança.

Uma pausa antes de fornecer dados

Eu usaria três perguntas antes de introduzir uma palavra-passe, dados pessoais ou de pagamento:

1. Como cheguei aqui? Abri o site por um endereço conhecido ou vim de uma mensagem inesperada, de um anúncio ou de um QR code? O caminho não decide tudo, mas ajuda a perceber o que falta confirmar.
2. O pedido faz sentido? Estava à espera desta ação? Porque me pedem estes dados ou este código agora? Uma ameaça de bloqueio imediato merece confirmação por outro canal.
3. Consigo confirmar fora desta página? A aplicação oficial, um favorito guardado anteriormente ou um contacto obtido de forma independente são melhores pontos de partida do que os dados apresentados pela própria mensagem suspeita.

A ARTE recomenda confirmar a origem, aceder diretamente aos serviços oficiais e desconfiar da urgência. São hábitos úteis mesmo quando o site apresenta uma ligação HTTPS sem avisos.

Se o browser mostrar um alerta de certificado ou de página perigosa, devemos parar, em vez de o ultrapassar para despachar a tarefa. Pode existir uma configuração errada ou uma ameaça; o aviso, sozinho, não permite distinguir as duas. É necessário confirmar antes de continuar.

O raciocínio funciona nos dois sentidos: um aviso merece atenção; a ausência de aviso não é uma garantia de confiança. As proteções do browser ajudam, mas não reconhecem obrigatoriamente todas as burlas.

Então o HTTPS não serve para nada?

Serve, e faz muita falta. É uma proteção essencial para a comunicação na Web. A conclusão não é trocar HTTPS por HTTP nem ignorar os indicadores do browser.

É dar-lhes o significado certo. A forma do símbolo pode variar entre browsers e versões; procuremos a informação sobre a ligação, em vez de tratar um cadeado como um selo de aprovação de todo o site.

Para mim, a pergunta útil deixa de ser apenas «tem HTTPS?» e passa a ser: «a ligação está protegida, mas estou a falar com quem pretendia e este pedido faz sentido?»

O envelope deve ir fechado. Confirmar a quem o entregamos continua a ser da nossa responsabilidade.