Como funciona o Keyless SSL? | Sigilo de encaminhamento

O Keyless SSL possibilita que organizações que não podem compartilhar suas chaves privadas se movam para a nuvem enquanto mantêm a criptografia SSL/TLS.

Objetivos de aprendizado

Após ler este artigo, você será capaz de:

  • Explicar as etapas em um handshake TLS e a diferença entre uma chave de sessão e uma chave privada
  • Entender como o Keyless SSL separa a parte do handshake TLS do restante do handshake usando a chave privada
  • Aprender a diferença entre os handshakes Diffie-Hellman e RSA
  • Entender o que é sigilo de encaminhamento

Copiar o link do artigo

O que é Keyless SSL?

O Keyless SSL é um serviço para empresas que usam um fornecedor de nuvem para criptografia SSL. Normalmente, isso significa que o fornecedor de nuvem precisa conhecer a chave privada da empresa, mas o Keyless SSL é uma maneira de contornar isso. Por motivos regulatórios, muitas organizações não podem compartilhar suas chaves privadas. Com o Keyless SSL, essas organizações ainda podem usar o TLS e aproveitar a nuvem, mantendo a chave segura.

O SSL, mais precisamente conhecido como TLS, é um protocolo para autenticação e criptografia de comunicações em uma rede. O SSL/TLS requer o uso do que é chamado de chave pública e chave privada e, no caso de uma empresa que usa o protocolo para proteger o tráfego de e para seu site (consulte HTTPS), a chave privada normalmente permanece na posse da empresa. Mas quando uma empresa muda para a nuvem e um fornecedor fornece a criptografia TLS, o fornecedor fica com a chave privada.

Ao mover a parte do handshake que envolve a chave privada para fora do servidor do fornecedor, a chave privada pode permanecer com segurança em posse da empresa. Em vez de usar a chave privada diretamente para gerar chaves de sessão, o fornecedor de nuvem obtém as chaves de sessão da empresa por meio de um canal seguro e usa essas chaves para manter a criptografia. Portanto, uma chave privada ainda é usada, mas não é compartilhada com ninguém de fora da empresa.

Por exemplo, suponha que a Acme Co. implemente o SSL. A Acme Co. armazenará com segurança sua chave privada em um servidor de sua propriedade e controle. Se a Acme Co. mudar para a nuvem e usar um provedor de serviços em nuvem para hospedagem na web, este fornecedor terá a chave privada. No entanto, se a Acme Co. mudar para a nuvem com um fornecedor que utiliza o Keyless SSL, a chave privada pode permanecer no servidor que a Acme Co. possui e controla, como na implementação de SSL sem nuvem.

Como funciona o Keyless SSL?

O Keyless SSL é baseado no fato de que há apenas um momento em que a chave privada é usada durante o handshake TLS, que ocorre no início de uma sessão de comunicação TLS. O Keyless SSL funciona dividindo as etapas do handshake TLS. Um fornecedor de nuvem que oferece Keyless SSL move a parte da chave privada do processo para outro servidor, geralmente um servidor que o cliente mantém no local.

Quando a chave privada se torna necessária durante o handshake para descriptografar ou criptografar dados, o servidor do fornecedor encaminha os dados necessários para o servidor de chave privada do cliente. A chave privada criptografa ou descriptografa os dados no servidor do cliente e os envia de volta ao servidor do fornecedor e o handshake TLS continua como de costume.

O Keyless SSL é apenas "sem chave" do ponto de vista do fornecedor de nuvem: ele nunca enxerga a chave privada do cliente, mas o cliente ainda a tem e usa. Enquanto isso, a chave pública ainda é usada no lado do cliente normalmente.

O que é uma chave de sessão?

Uma chave de sessão é uma chave simétrica usada por ambos os lados de uma comunicação segura por TLS, após a conclusão do handshake TLS. Uma vez que os dois lados concordem com um conjunto de chaves de sessão, não há mais necessidade de usar as chaves públicas e privadas. O TLS gera chaves de sessão diferentes e exclusivas para cada sessão.

Quais são as etapas para gerar as chaves de sessão?

Isso depende do tipo de algoritmo de troca de chaves usado no handshake TLS. Os dois principais são o algoritmo de troca de chaves RSA e o algoritmo de troca de chaves efêmeras Diffie-Hellman.

A troca de chaves RSA

Em um handshake RSA, as etapas de um handshake TLS para a criação de chaves de sessão são as seguintes:

  1. O cliente envia ao servidor uma mensagem de texto sem formatação "olá" que inclui a versão do protocolo que deseja utilizar, uma lista de conjuntos de criptografia compatíveis e uma pequena sequência aleatória de dados, chamadas de "cliente aleatório".
  2. O servidor responde (em texto sem formatação) com seu certificado SSL, seu pacote de criptografia preferido e uma pequena sequência aleatória de dados diferente, chamados de "servidor aleatório".
  3. O cliente cria outro conjunto aleatório de dados, chamado de "segredo pré-mestre". Ao usar a chave pública do certificado SSL do servidor, o cliente criptografa o segredo pré-mestre e o envia ao servidor; apenas alguém com a chave privada pode descriptografar o segredo pré-mestre.
  4. O servidor descriptografa o segredo pré-mestre. Observe que esta é a única vez que a chave privada é usada!
  5. Agora, o cliente e o servidor têm o cliente aleatório, o servidor aleatório e o segredo pré-mestre. De maneira independente um do outro, eles combinam essas três entradas para criar as chaves de sessão. Ambos devem chegar ao mesmo resultado e todas as comunicações subsequentes durante a sessão são criptografadas com essas novas chaves.

O Keyless SSL entra em ação na etapa 4. Com o Keyless SSL, em vez de descriptografar o segredo pré-mestre, o fornecedor de nuvem o envia de forma criptografada por meio de um canal seguro para um servidor que o cliente hospeda ou controla. A chave privada do cliente descriptografa o segredo pré-mestre e, em seguida, o segredo pré-mestre, descriptografado, é enviado de volta ao fornecedor de nuvem. O servidor do fornecedor de nuvem usa isso para derivar as chaves de sessão e as comunicações TLS continuam normalmente.

A troca de chaves efêmeras Diffie-Hellman

Um handshake Diffie-Hellman efêmero (DHE) ("efêmero" porque a mesma chave nunca é usada duas vezes) gera chaves de sessão usando o algoritmo Diffie-Hellman, uma maneira de trocar chaves em um canal não seguro. Com esse tipo de handshake TLS, a autenticação da chave privada é um processo separado da geração de chave de sessão.

A principal diferença entre o handshake DHE e o handshake RSA, além dos algoritmos usados, é como o segredo pré-mestre é gerado. Em um handshake RSA, o segredo pré-mestre é composto de dados aleatórios gerados pelo cliente. Em um handshake DHE, o cliente e o servidor usam parâmetros combinados para calcular o mesmo segredo pré-mestre separadamente.

  1. Assim como em um handshake RSA, o cliente envia a versão do protocolo que deseja usar, uma lista de conjuntos de criptografia compatíveis e o cliente aleatório.
  2. O servidor responde com seu conjunto de criptografia escolhido, um servidor aleatório e seu certificado SSL. A partir deste ponto, o handshake DHE começa a se diferenciar do handshake RSA: o servidor também envia seu parâmetro Diffie-Hellman (DH), que será usado para calcular o segredo pré-mestre. Ele também criptografa o cliente aleatório, o servidor aleatório e o parâmetro DH com a chave privada do servidor. Esta é a única vez que a chave privada é usada e ela autentica que o servidor é quem diz ser.
  3. O cliente descriptografa a mensagem do servidor com a chave pública e autentica o certificado SSL. O cliente então responde com seu parâmetro DH.
  4. Usando o parâmetro DH do cliente e o parâmetro DH do servidor, ambas as partes calculam o segredo pré-mestre separadamente.
  5. Em seguida, elas combinam esse segredo pré-mestre com o cliente aleatório e o servidor aleatório para obter as chaves de sessão.

A chave privada é usada apenas na etapa 2 e é aqui que o Keyless SSL se torna relevante. Nesse ponto, o fornecedor de SSL/TLS envia o cliente aleatório, o servidor aleatório e o parâmetro DH do servidor para o servidor controlado pelo cliente que possui a chave privada. Essas informações são criptografadas com a chave privada e enviadas de volta de forma criptografada ao fornecedor de nuvem, que as repassa ao cliente. O cliente pode descriptografar esses dados com a chave pública e o handshake continua. Dessa forma, o fornecedor de nuvem não precisa tocar na chave privada.

Os handshakes Diffie-Hellman efêmeros, embora demorem um pouco mais do que os handshakes RSA, têm a vantagem de algo chamado sigilo de encaminhamento. Como a chave privada é usada apenas para autenticação, um invasor não pode usá-la para descobrir qualquer chave de sessão definida.

O que é sigilo de encaminhamento? O que é sigilo de encaminhamento perfeito?

O sigilo de encaminhamento garante que os dados criptografados permaneçam criptografados mesmo se a chave privada for exposta. Isso também é conhecido como "sigilo de encaminhamento perfeito". O sigilo de encaminhamento é possível se uma chave de sessão exclusiva for usada para cada sessão de comunicação e se a chave de sessão for gerada separadamente da chave privada. Se uma única chave de sessão for comprometida, apenas essa sessão poderá ser descriptografada por um invasor; todas as outras sessões permanecerão criptografadas.

Em um protocolo configurado para sigilo de encaminhamento, a chave privada é usada para autenticação durante um processo inicial de handshake e não é usada para criptografia de outra maneira. O handshake Diffie-Hellman efêmero gera chaves de sessão separadamente da chave privada e, portanto, tem sigilo de encaminhamento.

O RSA, ao contrário, não tem sigilo de encaminhamento; com a chave privada comprometida, um invasor pode descriptografar as chaves de sessão de conversas anteriores, porque ele pode descriptografar os segredos pré-mestre dos clientes aleatórios e dos servidores aleatórios que estão em texto sem formatação. Ao combinar esses três, o invasor pode derivar qualquer chave de sessão definida.

Como a Cloudflare implementa o Keyless SSL?

A Cloudflare foi o primeiro fornecedor de nuvem a lançar o Keyless SSL, permitindo que as empresas que enfrentam restrições de segurança rígidas, como bancos, migrem para a nuvem. A Cloudflare oferece suporte para handshakes RSA e Diffie-Hellman, para que as empresas possam incorporar o sigilo de encaminhamento via Diffie-Hellman e se proteger contra a possibilidade de um invasor descriptografar seus dados após roubar sua chave privada.

Todas as comunicações entre os servidores da Cloudflare e os servidores de chave privada ocorrem em um canal criptografado seguro. Além disso, a Cloudflare descobriu que o Keyless SSL tem um impacto insignificante na performance, apesar das viagens extras para o servidor de chave privada.

Para obter mais detalhes técnicos sobre como o Keyless SSL funciona, veja essa postagem do blog. Para obter mais informações sobre o Keyless SSL da Cloudflare, explore os detalhes de nosso serviço Keyless SSL.