Atualmente o tráfego web começa a adotar um protocolo padrão e generalizado — o HTTPs.

No passado era comum associar ligações seguras (HTTPSecure) a transações financeiras, compras online, páginas de autenticação, acima de tudo usado em operações desta natureza.

Na época os web-designers defendiam que não existia a necessidade de sobrecarregar uma ligação TCP com criptografia quando “a informação trocada” apenas consistia numa página baseada em HTML e sem qualquer tipo de informação sensível.

À medida em que os websites se foram tornando mais funcionais, dinâmicos e complexos, essa realidade mudou rapidamente. Os consumidores sentiram que, não só eles queriam os seus dados financeiros protegidos, mas que também queriam que outras coisas fossem mantidas em sigilo. Coisas como p.ex., o que escrevem num post do Facebook, o conteúdo enviado através de um e-mail, entre outras coisas “normais” que um utilizador faz no seu dia a dia na Internet.

Este foi o ponto de viragem. Hoje temos mais websites com HTTPS. Esta mudança tem sido tão rápida, que a Google irá marcar todos os websites HTTP como não seguros a partir de julho 2018.

Ligações HTTP irão ser marcadas como not secure

 

Voltando a 2014, à conferência E/S, onde o protocolo HTTPs foi referido como uma uma nova prioridade para todo o tipo de tráfego que circula na Internet. Uma medida imediata foi tomada no ano seguinte, 2015, pela Google. A empresa começou a priorizar todo o tipo de resultados HTTPs resultante das pesquisas via o seu motor de pesquisa (google.pt).

Um ano depois, os websites que tivessem módulos de autenticacão insegura, ou informações de pagamento via cartões de crédito através do protocolo HTTP, passariam a ser “identificados” como not secure.

Em julho de 2018 entrará em vigor outra medida da Google — A empresa confirmou que com o lançamento do Chrome 68, agendado para julho, todos os websites que não usem HTTPs serão identificados como “not secure”.

 

 

Mas o que é está realmente protegido numa ligação com HTTPS?

O HTTPS é apenas HTTP sobre SSL (ou hoje, TLS) — HTTP + Secure => HTTPS.

Existem dois modelos de rede, o modelo OSI e o modelo TCP/IP. O TCP/IP é um mapeamento redutivo do OSI para redes modernas, onde as sete camadas originais são reduzidas para quatro.

TCP-IP-model-vs-OSI-model

 

O modelo TCP/IP, de quatro camadas, possui a camada de mais baixo nível chamada Network Interface, onde são executados protocolos como o Ethernet e similares.

Mais acima, existe uma camada chamada Network. Aqui operam protocolos como o ARP, ICMP (ping), e o Internet Protocolo (IP). Em seguida o modelo é composto pela camada de Transport (TCP e UDP) e por fim a camada Application, aquela com que interagimos todos os dias!

É na camada aplicacional que o HTTP e o TLS são usados!

No protocolo HTTPS, o TLS é executado logo abaixo do HTTP, e todas as comunicações HTTP são assim cifradas. Essas comunicações são p.ex., URLs, cookies, conteúdo web, atributos — basicamente => tudo.

Mas é importante perceber que tudo abaixo da camada de aplicação TCP/IP não está encriptado. P.ex., os portos do servidor, endereços de IP, endereços ethernet, i.e., qualquer tipo de informação necessária ao funcionamento de uma ligação entre dois hosts.

O protocolo HTTPS apenas cifra todo o conteúdo de um pedido  HTTP (mensagens, cookies, o corpo de uma página web)  — a informação trocada entre o computador de um utilizador (cliente) e o Facebook (servidor).

 

O tráfego é cifrado de ponta-a-ponta, e isso permite obter privacidade e confidencialidade na sua transmissão. Mas o que impede de alguém reivindicar ser o Facebok e roubar os dados dos utilizadores p.ex., na rede wireless de um cibercafé? — O certificado.

O HTTPs pode ser usado em dois modos, simples e mútuo.

Na maior parte das vezes é usado no modo simples, onde o servidor apenas autentica o cliente. Para que isso aconteça, o cliente deve ter um certificado e que é usado para validar o certificado de um servidor (p.ex., o Facebook).

Esses certificados de validação são fornecidos junto de todos os navegadores de Internet, e identificam as autoridades de certificação (Certificate Authorities) que emitem certificados assinados para que depois sejam instalados nos servidores web.

Quando uma ligação é estabelecida com o servidor, depois de algum paleio entre o computador do cliente e do servidor, o servidor fornece o seu certificado e o cliente valida se o certificado do servidor é válido. Para tal, o cliente confia no certificado assinado pela CA.

how-encryption-works

 

Portanto, o HTTPS permite validar se um cliente está a “falar” com quem pensa que é (p.ex., o Facebook)  e “esconde” o conteúdo da conversa.

No entanto, não esconde:

  • A quantidade de vezes em que ocorre uma conversa
  • Com quem se conversa (com que website foi estabelecida a comunicação — Facebook, Gmail, etc)
  • Com que frequência se mantém contacto
  • A capacidade de estimar o tamanho da mensagem enviada
  • O porto do servidor destino
  • O endereço de IP (cliente e servidor)
  • A sua localização (Portugal, EUA, etc)

 


Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *