en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Credenciais delegadas para TLS

Terminando um TLS conexão requer o uso de uma chave privada de certificado. Como resultado, a chave privada precisa ser armazenada em cada servidor utilizado por um serviço. A proteção do sigilo desta chave privada é fundamental para o bom funcionamento de um esquema de infraestrutura de chave pública. Uma entidade de posse da chave privada pode realizar ataques man-in-the-middle pelo restante da validade do certificado. Normalmente, quando um invasor compromete uma chave privada, o certificado associado a essa chave é revogado e um novo é emitido. No entanto, para empresas que usam vários servidores, como Facebook ou Content Delivery Networks, os principais comprometimentos, especialmente em servidores de borda, não são fáceis de detectar, colocando em risco toda a rede. As credenciais delegadas permitem que os servidores executem TLS apertos de mão, enquanto a chave privada do certificado é armazenada em um local seguro.

As credenciais delegadas são estruturas de dados assinadas digitalmente, compostas por duas partes: um intervalo de validade e uma chave pública (junto com seu algoritmo de assinatura associado). Eles servem como um “procuração”Para os servidores, indicando que eles estão autorizados a terminar o TLS conexão. O processo de emissão de credenciais delegadas está atualmente sob padronização e definido neste Rascunho IEFT. O rascunho define o uso de credenciais delegadas da seguinte forma:
 
“Um mecanismo de delegação limitada que permite um TLS peer para emitir suas próprias credenciais dentro do escopo de um certificado emitido por uma CA externa. Essas credenciais apenas permitem que o destinatário da delegação fale em nome de nomes que a CA autorizou. ”
As credenciais delegadas são projetadas com o objetivo de aumentar a segurança. Portanto, eles possuem certas características, conforme definido no rascunho do IEFT.
  • O período máximo de validade de uma credencial delegada é sete (7) dias para minimizar a exposição se a chave privada for comprometida. O curto período de validade não significa que a segurança das credenciais delegadas deve ser considerada levianamente. As medidas tomadas para proteger a chave privada do certificado da entidade final também devem ser aplicadas à proteção dos controladores de domínio. Isso inclui controles do sistema de arquivos, segurança física e módulos de segurança de hardware, entre outros. Além disso, as credenciais delegadas devem ser usadas apenas entre partes que compartilham alguma relação de confiança entre si.
  • As credenciais delegadas são ligado criptograficamente ao certificado da entidade final. Especificamente, a chave privada do certificado da entidade final é usada para calcular a assinatura do DC por meio de um algoritmo especificado pela credencial. A assinatura vincula efetivamente o DC aos nomes do certificado da entidade final.
  • As credenciais delegadas são emitidas pelo cliente, o que é muito mais fácil do que criar um certificado assinado por uma CA. Certificados emitidos pelo cliente também são úteis para manter o serviço em funcionamento, mesmo se a CA tiver um tempo de inatividade. Além disso, as organizações podem experimentar algoritmos sem suporte oficial da CA, sem comprometer a segurança do certificado da entidade final. 
  • As credenciais delegadas têm curtos períodos de validade por definição. Ao definir o tempo de vida das credenciais delegadas, os servidores precisam levar em consideração a defasagem do relógio do cliente para evitar a rejeição de certificados. O desvio do relógio do cliente também é importante para o certificado original, mas é crucial para a chave privada delegada de curta duração. A inclinação do relógio do cliente deve ser levada em consideração no início e no final dos períodos de validade.
  • Não há mecanismo de revogação para credenciais delegadas. Eles são invalidados quando o período de validade expira. No entanto, a revogação da chave privada do certificado da entidade final (que é usado para assinar as credenciais delegadas) revoga implicitamente a credencial delegada. 
  • As credenciais delegadas são projetadas para serem usadas em TLS 1.3 ou mais tarde. Existe uma vulnerabilidade conhecida quando TLS Os servidores 1.2 suportam a troca de chaves RSA, permitindo a falsificação de uma assinatura RSA em uma mensagem arbitrária. Suponha que um invasor seja capaz de forjar uma assinatura. Nesse caso, eles podem criar credenciais delegadas falsificadas para todo o período de validade do certificado da entidade final. Esta vulnerabilidade não está presente em implementações de TLS 1.3 ou posterior. Além disso, a vulnerabilidade não afeta os certificados com criptografia de curva elíptica, que SSL.com proporciona. 
  • As organizações podem usar APIs de emissão automatizada existentes, como ACME, para fornecer credenciais delegadas. Nesse caso, os algoritmos usados ​​são apenas aqueles suportados pela CA, mas essa prática reduz a possibilidade de comprometimento de chaves. SSL.com endossa esta prática. 
  • As credenciais delegadas não podem ser reutilizadas em vários contextos. As partes emissoras calculam a assinatura usando uma string de contexto exclusiva para a função pretendida (cliente ou servidor), tornando assim o uso da mesma credencial delegada para autenticação de cliente e servidor impossível. 
SSL.com suporta o uso de credenciais delegadas para todos os clientes. A emissão de certificados com capacidade de credenciais delegadas pode ser feita por meio do uso de APIs para automação usando o protocolo ACME. Desde a SSL.com utiliza ECDSA para implementar o PKI ofereceu para clientes, as credenciais delegadas emitidas por nossos clientes não são vulneráveis ​​a ataques de falsificação de assinaturas, conforme descrito acima. 

Artigos Relacionados

Inscreva-se no boletim informativo de SSL.com

O que é SSL /TLS?

Reproduzir Vídeo

Inscreva-se no boletim informativo de SSL.com

Não perca novos artigos e atualizações de SSL.com