SSL Auto-assinado e Certificados TLS

Em dias atuais é visível a necessidade de privacidade. Por este motivo, as grandes corporações veem desenvolvendo mecanismos para ofuscar a comunicação de uma forma que só o destinatário seja capaz de compreender.

Esta ofuscação é chamada de criptografia, ou texto cifrado. A cifra é a transformação matemática que é utilizada para transformar o texto simples em texto cifrado para levar um tipo de dado, ou informação apenas para destinatários confiáveis.

As primeiras formas de criptografias eram principalmente criptografias "simétricas", o que significa que a cifra utiliza a mesma chave tanto para criptografia, quanto para descriptografia. Por exemplo, se você já gerou uma senha para um documento em PDF, ou um arquivo ZIP, este formato é denominado de simétrico. Isto é, este tipo de senha é uma versão humanamente compreensível de padrão de senha.

Por exemplo, pense em uma chave para a porta da frente de sua casa. Você pode ter uma ou mais dessas chaves, mas todas elas são exatamente iguais e cada uma delas pode trancar ou destrancar a porta.

Hoje em dia temos também formas de criptografia que são "assimétricas". O que significa que uma chave é usada para criptografar uma mensagem, e uma chave completamente diferente é usada para decifrá-la.

Neste caso, depois de trancar a porta da sua casa com uma chave, somente a outra chave pode destranca-la. E mais, nem mesmo a chave que trancou poderá destranca-la.

Ok, mas onde que a InfraEstrutura entra nisso? Uma vez que um par de chaves assimétricos são gerados no sistema, o usuário irá manter uma dessas duas chaves muito seguras e preferencialmente escondidas de modo que só eles terão acesso a estas chaves.

Em termos práticos, se alguém quiser ter acesso a um servidor, simplesmente poderá optar por criptografar uma chave pública já que de antemão se sabe que o destinatário é o único que pode decifra-la. O mesmo ocorre com a chave privada para acesso a um servidor por exemplo.

Só que aí existe um problema: E se o usuário do outro lado não for necessariamente a pessoa a quem a chave privada ou pública se destina? Por exemplo, uma chave compartilhada? É preciso ter uma maneira de verificar isso.

A solução é simplória e extremamente importante. Se chama confiança. Há muitas maneiras de estabelecer confiança, tanto para receber a chave pública, quanto privada. Obviamente, isso não é conveniente para a economia global, por isso é necessário buscar outros mecanismos.

Digamos que o usuário deseje executar um servidor do Governo Federal. É compreendido que este servidor contém dados que não podem ser acessados por qualquer um. Sendo assim, cabe a nós administradores definir o uso do protocolo HTTPS, isto é, um (HTTP seguro).

Basicamente precisamos gerar uma chave pública, e uma chave privada (que neste caso nós chamamos um certificado). A maneira mais comum de fazer isso, é entrando em contato com uma autoridade de certificação e comprar uma assinatura.

A autoridade de certificação irá fazer o trabalho duro de verificar a identidade do usuário e, em seguida, assinar o seu certificado de servidor com a chave privada da AC, proporcionando assim a confiança por meio de um terceiro.

Quando um site tem um cadeado verde ao lado do protocolo HTTPS na sua barra de URL, significa que suas comunicações são criptografadas.

Uma das principais desvantagens para a compra de uma assinatura CA, é que não costuma ser barato. A solução para esta questão de preço tem sido, tradicionalmente, a criação de um certificado auto-assinado.

Ou seja, ao invés de ter o seu certificado assinado por uma autoridade de certificadora, podemos também utilizar os certificados de chave pública para adicionar uma assinatura de chave privada.

O problema com esta abordagem é que os navegadores da Web e outros clientes que verificam a segurança da conexão não será capaz de verificar se o servidor é quem ele diz que é. Na maioria dos casos, o usuário será apresentado com uma página de aviso informando que o site não é seguro (o que na maioria das vezes causa um impacto negativo ao usuário desinformado ou desavisado).

Sendo assim, fica o alerta:

Nunca use um certificado auto-assinado para um site em produção.

Voltando a questão da confiança sobre chaves públicas e privadas em ambiente corporativo para acesso à servidores, é necessário estar atento a alguns questões. São elas:

  • Precisamos ter a criptografia para proteger os dados de olhos curiosos.
  • Nossos clientes precisam ser capazes de confiar que eles estão falando com o sistema de confiável no outro extremo da conversa.

Conseguir um certificado assinado por uma CA bem conhecida pode ser bastante caro para um projeto pequeno, mas nós não queremos colocar máquinas dos desenvolvedores em risco.

Portanto, há duas melhores maneiras de lidar com isso. Uma é ter uma autoridade de certificação para toda a organização. Esta chave deve ser gerida pela equipe de T.I. Esta abordagem é poderosa, mas também pode ser difícil de configurar (especialmente em empresas que não contém nada na nuvem).

Então, vamos olhar para uma outra solução que está mais perto de uma abordagem de chaves auto-assinadas que seria basicamente lidar com uma chave site-specific, isto é, uma assinatura de chave com uma autoridade certificadora para uso apenas para desenvolvimento e testes. Em seguida, você poderá fornecer a chave pública desta autoridade de certificação para quem deseja ter acesso ao serviço e que poderá adicionar este CA ao seu destino de confiança.

De todo modo, a recomendação segue igualmente para ambientes em produção:

Não use esta configuração para um sistema em produção.