O número de pessoas que executam transações sensíveis na internet (como compras online, transações bancárias, etc.) cresce cada vez mais. Porém, com a facilidade que a internet trouxe em geral para a execução destas operações, os cuidados devem ser redobrados. Analisar e verificar os sites onde estas operações são feitas com o intuito de detectar se o site é confiável, real e seguro é algo essencial.
Por isso, aspectos relacionados a segurança em geral em aplicações web merecem uma atenção especial. A sensação de segurança que uma aplicação web passa a seus usuários é algo extremamente importante, pois inspira confiança e credibilidade. Uma aplicação web precisa garantir que é verdadeira e que as informações trocadas estarão criptografadas e seguras. Visando isso, a implementação de um certificado SSL torna-se algo essencial.
O SSL (Secure Socket Layer) é um mecanismo de criptografia com o objetivo de aumentar a segurança na troca de informações entre clientes e servidores, protegendo a integridade e veracidade do conteúdo que trafega na internet. O certificado garante que a informação do navegador chegará de forma segura desde um cliente (como um browser) até o servidor do site. Quando você coloca seu número de cartão de crédito em uma página que utiliza SSL por exemplo, os números serão codificados e embaralhados, dificultando que um invasor ou interceptador consiga ver o número de cartão de crédito informado.
Curso Kubernetes - Health Check, Resources, Automação e Administração de cluster
Conhecer o cursoCom a utilização do certificado SSL, o endereço do seu site passa de HTTP para HTTPS, indicando que as informações trafegadas entre cliente e servidor ocorrerão através do protocolo SSL/TLS e que as informações serão criptografadas. Além disso, os browsers modernos passam a exibir o desenho de um cadeado antes da URL, fazendo com que o usuário saiba que a aplicação web é segura.
O HTTPS (sigla para Hyper Text Transfer Protocol Secure ou Protocolo de Transferência de Hipertexto Seguro) é uma derivação do protocolo HTTP com uma camada SSL/TLS adicional implementada, o que adiciona mais segurança ao HTTP. Como o HTTPS utiliza criptografia, as chances de um intruso interceptar as mensagens trocadas entre cliente e servidor e obter acesso ao conteúdo destas mensagens reduz-se consideravelmente, pois as mensagens passam a ser criptografadas através de certificados digitais. Quando falamos sobre aplicações web, essa criptografia é essencial: através do tradicional HTTP, as mensagens são trafegadas como texto puro, ou seja: caso um interceptador capture mensagens HTTP, este terá total acesso a seu conteúdo sem maiores dores de cabeça. Com o HTTPS e sua criptografia inerente, esse risco é drasticamente reduzido.
Além de deixar o seu site mais seguro e confiável, a utilização do certificado SSL traz um outro benefício: a otimização do SEO. São diversos fatores que influenciam o ranqueamento dos sites no Google, sendo que um destes fatores é justamente a utilização de SSL. Como o Google considera o certificado SSL um benefício importante para os usuários, ele prioriza isso ao selecionar os sites que aparecem na busca, melhorando o posicionamento do seu site.
Como ele funciona?
O ciclo de uma transmissão HTTPS começa com um certificado digital. Um certificado digital é como se fosse uma espécie de RG eletrônico, identificando a sua aplicação como sendo uma aplicação confiável e verdadeira. Certificados digitais devem ser obtidos através de entidades certificadoras (ou CAs - Certification Authorities), pois somente estas têm as permissões necessárias para gerar certificados digitais válidos. É um processo muito parecido com o RG humano propriamente dito… Um RG não pode ser emitido em qualquer lugar: ele deve ser solicitado somente em locais autorizados a lidarem com a emissão de RGs e que tenham acesso aos sistemas estaduais e nacionais de identificação. É o mesmo cenário com certificados digitais, já que estes irão identificar sua aplicação dentro de toda a web. Algumas entidades certificadoras são Verisign, GeoTrust, Comodo e Amazon. O serviço de geração de um certificado é geralmente pago e deve ser feito periodicamente, pois os certificados possuem uma data de expiração. Também existem serviços que emitem certificados de maneira gratuita, como o Let’s Encrypt.
Um certificado é composto basicamente por duas partes: uma chave pública e uma chave privada que são geradas randomicamente pela entidade certificadora. A chave pública é utilizada para verificar os clientes que realizam as requisições, enquanto a chave privada é utilizada para a realização do processo de criptografia.
Curso HTML5 + CSS3 - Fundamentos
Conhecer o cursoQuando você se conecta a um servidor que utilize HTTPS/SSL para a transferência de informações, o servidor irá responder inicialmente com a chave pública e o certificado associado à aplicação que está sendo acessada. Cabe ao cliente (como um browser), ao receber esta chave, verificar alguns pontos:
- Se a chave pública não está expirada (o que ocorre quando o certificado já se encontra expirado);
- Se a chave pública pertence realmente à aplicação que está sendo acessada;
- Se o cliente consegue descriptografar a assinatura digital do certificado enviado, o que significa que aquela chave pública e aquele certificado são válidos.
Quando um destes pontos de verificação falha, o cliente (como um browser) aborta a conexão e mostra uma mensagem de alerta para o usuário parecida com a tela abaixo.
Caso todas as verificações ocorram com sucesso, o browser entende que a comunicação está sendo feita com um servidor confiável.
Quando o cliente detecta que a conexão é confiável, o cliente cria uma nova chave, chamada de chave de sessão ou session key. Com a chave de sessão criada, o cliente envia esta chave de volta ao servidor, porém, criptografada com a chave pública validada nos passos anteriores.
Quando o servidor recebe a chave de sessão do cliente, ele utiliza a chave privada (que nunca é trafegada entre as requisições) para tentar obter a chave de sessão informada pelo browser. Um conteúdo criptografado com a chave pública só pode ser descriptografado com a chave privada, o que garante a autenticidade e legitimidade das informações que são trafegadas criptografadas com a chave pública. Caso o servidor consiga realizar este processo, é enviado de volta ao cliente uma resposta de que “está tudo OK”, também chamada de ACK (acknowledgement ou reconhecimento). Esse processo todo é chamado de handshake, pois agora somente o cliente e o servidor têm conhecimento das chaves públicas e de sessão que foram trocadas. É como se o cliente e o servidor tivessem se identificado um com o outro e, após existir a confiança entre os dois, ambos apertassem as mãos e disessem: “sei que você é você mesmo de fato e, por isso, confio nas informações que vamos trafegar entre nós”.
A partir deste momento, o servidor passa a responder as informações de volta ao cliente criptografando-as com a chave de sessão que somente o cliente e o servidor têm conhecimento. O cliente passa a utilizar a chave de sessão para descriptografar as informações enviadas pelo servidor. Quando o cliente precisa enviar informações para o servidor, este utiliza também a chave de sessão para criptografar o conteúdo, enquanto o servidor utiliza a mesma chave (que somente este cliente e o servidor possuem conhecimento) para descriptografar o conteúdo.
Veja que o processo de confidencialidade é bem forte neste processo: se algum interceptador interceptar estas mensagens, este não terá a chave de sessão vinculada ao cliente para descriptografar as mensagens. Ele também não conseguirá obter esta chave de sessão, mesmo que ele tenha acesso à chave pública do certificado: não se esqueça que o conteúdo criptografado com a chave pública só pode ser descriptografado com a chave privada. A única maneira de um invasor conseguir descriptografar o conteúdo é se este, de alguma maneira, tiver acesso à chave privada do certificado do servidor ou à chave de sessão do cliente.
Um ponto interessante é que esse processo de criptografia que é utilizado no HTTPS é chamado por muitos de criptografia assimétrica, já que existem duas chaves de criptografia utilizadas durante o processo: uma estática, mas que fica escondida no cliente (no caso da chave privada) e no cliente (no caso da chave de sessão); e uma chave pública, cujo conteúdo só pode ser descriptografado justamente com a chave privada. Veja que esse processo é diferente da criptografia “tradicional”, que também é dita como criptografia simétrica, onde só existe uma chave estática para a realização do processo de criptografia e descriptografia.
