Https e certificado digital

Desde o surgimento das primeiras aplicações web e principalmente das aplicações financeiras, as empresas de tecnologia tiveram preocupação com a segurança dos usuários desses sistemas, afinal ninguém gostaria que as informações que manda para seu banco ou aplicativo de mensagens (Ex. WhatsApp) fosse lido por um estranho. Não é mesmo?

E hoje vamos ver como isso é feito.

Primeiramente vamos analisar quais são os principais problemas que podem ocorrer na comunicação entre o cliente e servidor.

Vamos supor A e B se comunicando usando o protocolo HTTP,  A deseja acessar a página que B hospeda,  então requisita ela usando GET.
Server Communication

Dentro do index.html existe um formulário onde o usuário preencherá login e senha para efetuar login na aplicação.

Screenshot from 2018-12-01 19-42-28

Quando A submeter o formulário e enviar as informações para B, os dados de login serão enviados ao servidor B:
Server Communication 2

O problema é que utilizando simplesmente o protocolo HTTP, se alguém interceptar a mensagem terá acesso ao login e senha do usuário.

Para evitar isso, utilizamos o protocolo HTTPS que adiciona criptografia a nossa conexão e também nos permite verificar a autenticidade da conexão através de certificado digital.

Mas como isso funciona?

É bem simples: Uma autoridade certificadora (comumente chamada de CA) emite um certificado digital para o domínio usar(no nosso exemplo seria servidorb.com), a autoridade certificadora é uma organização confiável que vai garantir a autenticidade do certificado.

Em browsers como o Google Chrome, existem uma série de CAs já pré registrados. Também é possível ao usuário adicionar mais CAs em que ele confia, por exemplo, um serviço privado de sua empresa pode ter um certificado auto-assinado, evitando assim que o navegador emita aquela mensagem chata: “conexão não é particular”.

 

erro-de-certificado

Essa mensagem significa que você está acessando um serviço que usa um certificado que não foi gerado por CA renconhecida pelo seu browser.

O certificado será usado para garantir que o conteúdo que você recebe de servidorb.com vem realmente de B, evitando assim o chamado ataque man-in-the-middle (Um terceiro sequestra a conexão entre A e B, interferindo na comunicação entre ambos, fingindo ser B para A ou fingindo ser A para B).

Server Communication 3

O certificado garantirá que o atacante não se passará por B, pois, ele não tem o certificado de servidorb.com.

Outro aspecto fundamental da comunicação é que os dados serão criptografados. Pois, ao iniciar a comunicação, B passa para A uma chave pública, que A utilizará para criptografar as mensagens que deseja passar para B. Somente B tem a chave privada que decodifica as mensagens, então A pode passar mensagens para B de forma segura.

Da mesma forma, A e B combinam um esquema de criptografia, geralmente o esquema simétrico, ou seja, mesma chave. A comunicação é segura, pois mesmo que um atacante veja as mensagens, elas estão criptografadas e ele não tem a chave para decodificá-las.

Sendo assim, as aplicações que utilizam HTTPS e que usam um certificado emitido por uma CA confiável são seguras.

Por hoje é só pessoal, abraço.

Vladwoguer Bezerra

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close