Criptografia em AdvPL – Parte 10

Introdução

No post anterior, vimos em mais detalhes o objetivo e uso das chaves públicas, e como funciona um Handshake de conexão segura para HTTPS. Agora, vamos ver como gerar um certificado digital a partir de outro certificado, usando o certificado “pai” para autenticar o certificado “filho”, e usar isso no nosso exemplo de HTTPS 😀

Posts anteriores

Lembrando do primeiro teste com HTTPS

No Post 06 tem a receita de bolo pra gerar um certificado auto-assinado e usá-lo no TOTVS Application Server para prover acesso via HTTPS. Em resumo, trata-se de um certificado auto-assinado com extensões v3, para ser usado no servidor HTTPS em um determinado host, e para o navegador aceitar o certificado, ele precisava ser instalado na máquina cliente como um Trusted Root Certificate.

Certificados com cadeia de autenticação

Agora, vamos fazer um mecanismo um pouco mais elegante: Criar um certificado raiz auto-assinado, e criar um outro certificado para o HTTPS, com todos os dados necessários, porém assinado pelo primeiro certificado. E isso permite eu praticamente fazer o papel de uma autoridade certificadora — não oficial, claro.

Imagine que eu vou fazer o papel fictício de Autoridade Certificadora, e você quer criar um site seu, usando um certificado seu, mas quer que ele seja autenticado pelo meu certificado. Eu, como autoridade certificadora fictícia, tenho um certificado auto-assinado que eu uso como “raiz”, a base de tudo, com uma chave privada minha atrelada a este certificado.

Então, primeiro você cria a sua chave privada para ser usada pelo seu certificado. Porém, você não vai criar o certificado propriamente dito, você vai criar uma CSR (Certificate Signing Request), ou requisição de assinatura de certificado, com tudo o que você quer no seu certificado, e vai mandar ela para eu assinar com o meu certificado e com a minha chave. Eu vou criar o seu certificado para você, usando os dados que você forneceu na requisição de assinatura, e vou assinar o seu certificado com o meu.

Repare que eu tenho uma chave privada do meu certificado, e você vai usar a sua chave privada no seu certificado, mas em nenhum momento nem eu e nem você podemos tre acesso as chaves privadas um do outro. Neste processo as chaves públicas são intrinsecamente utilizadas: Quando eu receber a sua requisição de assinatura, a requisição em si traz junto a sua chave pública embutida, e todos os dados que você quer no seu certificado. Eu crio e assino o seu certificado, para que ele possa ser autenticado pelo meu certificado, mas o seu certificado ainda assim vai usar a sua chave privada no seu ambiente.

Quando você colocar o seu site no ar, você vai usar o seu certificado e a sua chave privada nas configurações do HTTPS, porém você não vai precisar pedir para os seus clientes — que vão acessar o seu site — instalar o seu certificado na maquina deles, você pede para eles instalarem o meu certificado — que assinou o seu — como Trusted Root Certificate. 😀 Assim, a máquina que tiver o meu certificado raiz não vai ter a minha chave privada, e o meu certificado será usado para verificar a assinatura do seu certificado quando o cliente acessar o seu site 😀

Fazendo a mágica

Eu, atuando como Autoridade Certificadora, crio a minha chave privada e o meu certificado auto-assinado:

-- Criando chave privada protegida por senha 
openssl genrsa -des3 -out rootCA.key 4096

-- Criando o meu certificado raiz para ser uma "autoridade certificadora"
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt 

O primeiro comando vai perguntar a senha para uso da chave privada, e na criação do meu certificado raiz eu coloco informações que me identificam.

Agora você vai criar a sua chave privada e uma requisição de assinatura para o seu certificado:

-- Voce cria a sua chave privada
openssl genrsa -out mydomain.com.key 2048

-- e cria uma requisição de assinatura
openssl req -new -key mydomain.com.key -out mydomain.com.csr -subj "/C=BR/ST=SP/L=Sao Paulo/O=Testes INC/CN=mydomain.com" 

A sua requisição de assinatura vai estar gravada no arquivo “mydomain.com.csr“, e você manda esse aquivo para eu assinar com o meu certificado. Eu vou assinar seu certificado com o seguinte comando:

openssl x509 -req -in mydomain.com.csr -extfile v3.ext -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out mydomain.com.crt

Para assinar o seu certificado, eu tive que criar um arquivo a mais, no exemplo acima chamado de “v3.ext”, onde eu vou colocar algumas extensões no seu certificado.

basicConstraints = CA:FALSE
keyUsage=digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectKeyIdentifier = hash
subjectAltName=DNS:mydomain.com

No final das contas, o seu certificado vai ser gerado no arquivo “mydomain.com.crt“, e eu mando esse arquivo pra você, e mando também o meu certificado “rootCA.crt“.

Agora você tem a sua chave privada “mydomain.com.key”  e o seu certificado “mydomain.com.crt“, e você configura o seu servidor HTTPS para usá-los.

[sslconfigure]
CertificateServer=c:\Protheus12LG\certificates\mydomain.com.crt
KeyServer=c:\Protheus12LG\certificates\mydomain.com.key

E, você ou qualquer outra pessoa que acesse o seu site, deve apenas instalar o meu certificado na máquina cliente como “Trusted Root Certificate“. Dessa forma, quando um navegador abrir o seu site, ele vai encontrar o seu certificado, e para validar a relação de confiança desse certificado, ele procura um certificado raiz confiável, e encontra o meu certificado — que é capaz de dizer que o seu certificado foi assinado por mim 😀

Se, amanhã você colocar outro site no ar, você repete o processo de criação de chaves e requisição de assinatura, e eu crio e assino o seu novo certificado, e todas as pessoas que já instalaram o meu certificado nas máquinas delas para acessar o seu site, não precisam mais instalar nada, pois o meu certificado raiz é capaz de autenticar qualquer certificado que eu tenha assinado com ele 😀

Estendendo a cadeia de autenticação ou confiança

Por hora a cadeia de autenticação desse exemplo possui apenas o certificado raiz, e cada certificado assinado por ela confia no raiz. Se, ao invés de você me pedir para assinar um certificado de uso final, você crie o seu certificado raiz e eu assine esse certificado, você mesmo pode emitir certificados para terceiros, assinados com o seu certificado raiz. Com isso, quando um navegador usar um certificado que você emitiu, ele vai procurar o seu certificado raiz — que não necessariamente precisa ser um “Trusted Root”, mas sim um “Trusted CA” — e quando ele encontrar o seu certificado raiz, ele verifica que ele foi emitido por mim, e confia nele desde que o meu certificado raiz seja um “Trusted Root” 😀

Eu sei, logo de cara é um pouco complicado, mas esse mecanismo — quando bem configurado e utilizado — provê um mecanismo de confiança muito seguro. Vamos ver agora alguns exemplos do mundo real.

Assinatura digital de aplicativos

Quando você vai instalar um programa qualquer,  o sistema operacional da sua máquina verifica se o seu programa tem uma assinatura digital que indica quem é o fornecedor desse programa. A cadeia de autenticação é praticamente a mesma, porém você tem um tipo diferente de certificado, com outras propriedades e extensões. Na instalação do programa, ao verificar o certificado usado para a assinatura, caso a assinatura não possa ser verificada, o sistema operacional pergunta se você confia nessa assinatura, e você aceita o risco de instalar o programa. E, se você confia naquela assinatura, você pode ainda declarar que “sempre confia” naquela assinatura, e quando você instalar outro programa assinado com este certificado, o sistema operacional não vai perguntar novamente se você confia nele, e vai deixar o programa ser executado.

Agora, já pensou se alguém consegue assinar um aplicativo malicioso, com um vírus ou um Trojan Horse, copiando a assinatura da Microsoft ? Ou da Symantec ? Se a assinatura for determinada erroneamente como confiável, o estrago é inimaginável e transparente, o programa faz o que quiser com a sua maquina !!! Por isso a infraestrutura de segurança é desenhada para não ser quebrada, senão a “vaca vai pro brejo” !!!!

Conclusão

Já vimos bastante coisa até o momento, mas ainda têm bastante a ser visto. Toda essa introdução com os respectivos exemplos serve para a gente entender o tamanho do mecanismo e seus componentes. A partir de agora, todas as demais camadas e mecanismos são baseados em tudo o que foi explicado até aqui, isso serve de “base” para tudo o que ainda vamos ver pela frente !!!

Agradeço novamente pela audiência, e lhes desejo TERABYTES DE SUCESSO !!! 

Referências

 

 

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s