Como funciona o Keyless SSL?

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 envolvendo a chave privada para fora do servidor do fornecedor, a chave privada pode permanecer segura na posse da empresa. Em vez de usar a chave privada diretamente para autenticar o servidor do fornecedor, o fornecedor de nuvem encaminha e recebe dados do servidor da empresa para fazer isso. Essa comunicação ocorre por meio de um canal seguro e criptografado. Assim, 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 TLS. 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/TLS, a chave privada pode permanecer no servidor que a Acme Co. possui e controla, como na implementação de TLS 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 geograficamente. 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 assinar dados, o servidor do fornecedor encaminha os dados necessários para o servidor de chave privada do cliente. A chave privada descriptografa ou assina 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.

Como funciona o Keyless SSL com um handshake TLS de troca de chave RSA?

Em um handshake RSA, as etapas em um handshake TLS 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 de sessão.

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.

Como funciona o Keyless SSL com 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 inclui uma assinatura digital para autenticação. Esta é a única vez que a chave privada é usada e ela autentica que o servidor é quem diz ser.
3. O cliente verifica a assinatura digital do servidor 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 usadas para gerar a assinatura digital do servidor e enviadas de volta ao ao fornecedor de nuvem, que as repassa ao cliente. O cliente pode verificar essa assinatura 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 é 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.

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 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 determinar as chaves de sessão de conversas anteriores, porque ele pode descriptografar o segredo pré-mestre e os aleatórios do cliente e do servidor que estão em texto não criptografado. 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 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.