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.

Credenciales delegadas para TLS

Terminando un TLS la conexión requiere el uso de la clave privada de un certificado. Como resultado, la clave privada debe almacenarse en cada servidor utilizado por un servicio. La protección del secreto de esta clave privada es fundamental para el buen funcionamiento de un esquema de infraestructura de clave pública. Una entidad en posesión de la clave privada puede realizar ataques de intermediario durante el resto de la validez del certificado. Normalmente, cuando un atacante compromete una clave privada, el certificado asociado con esta clave se revoca y se emite uno nuevo. Sin embargo, para empresas que utilizan varios servidores, como Facebook o Redes de distribución de contenidos, los compromisos clave, especialmente en los servidores de borde, no son fáciles de detectar, por lo que ponen en riesgo toda la red. Las credenciales delegadas permiten que los servidores funcionen TLS apretones de manos, mientras que la clave privada del certificado se almacena en una ubicación segura.

Las credenciales delegadas son estructuras de datos firmadas digitalmente que constan de dos partes: un intervalo de validez y una clave pública (junto con su algoritmo de firma asociado). Sirven como un "Poder legal”Para los servidores indicando que están autorizados a terminar el TLS conexión. El proceso de emisión de credenciales delegadas se encuentra actualmente bajo estandarización y se define en este Borrador IEFT. El borrador define el uso de Credenciales Delegadas de la siguiente manera:
 
“Un mecanismo de delegación limitado que permite TLS par para emitir sus propias credenciales dentro del alcance de un certificado emitido por una CA externa. Estas credenciales solo permiten al destinatario de la delegación hablar en nombre de los nombres autorizados por la CA ".
Las credenciales delegadas están diseñadas con el propósito de aumentar la seguridad. Por lo tanto, poseen ciertos rasgos, tal como se definen en el borrador de la IEFT.
  • El período de validez máximo de una credencial delegada es siete (7) días para minimizar la exposición si la clave privada se ve comprometida. El corto período de validez no significa que la seguridad de las credenciales delegadas deba tomarse a la ligera. Las medidas tomadas para proteger la clave privada del certificado de entidad final también deben aplicarse a la protección de los CD. Estos incluyen controles del sistema de archivos, seguridad física y módulos de seguridad de hardware, entre otros. Además, las credenciales delegadas solo deben usarse entre partes que comparten alguna relación de confianza entre sí.
  • Las credenciales delegadas son enlazado criptográficamente al certificado de entidad final. Específicamente, la clave privada del certificado de entidad final se usa para calcular la firma del DC a través de un algoritmo especificado por la credencial. La firma vincula efectivamente el DC a los nombres del certificado de entidad final.
  • Las credenciales delegadas son emitidas por el cliente, que es mucho más fácil que crear un certificado firmado por una CA. Los certificados emitidos por el cliente también son útiles para mantener el servicio en funcionamiento incluso si la CA tiene un tiempo de inactividad. Además, las organizaciones pueden experimentar con algoritmos no admitidos oficialmente por la CA sin comprometer la seguridad del certificado de entidad final. 
  • Las credenciales delegadas tienen cortos períodos de validez por definición. Al establecer la duración de las credenciales delegadas, los servidores deben tener en cuenta la desviación del reloj del cliente para evitar el rechazo de certificados. La desviación del reloj del cliente también es importante para el certificado original, pero es crucial para la clave privada delegada de corta duración. La desviación del reloj del cliente debe tenerse en cuenta tanto al principio como al final de los períodos de validez.
  • No existe un mecanismo de revocación para las credenciales delegadas. Se invalidan una vez que expira el período de validez. Sin embargo, la revocación de la clave privada del certificado de entidad final (que se utiliza para firmar las credenciales delegadas) revoca implícitamente la credencial delegada. 
  • Las credenciales delegadas están diseñadas para usarse en TLS 1.3 o después. Existe una vulnerabilidad conocida cuando TLS Los servidores 1.2 admiten el intercambio de claves RSA, lo que permite la falsificación de una firma RSA en un mensaje arbitrario. Supongamos que un atacante puede falsificar una firma. En ese caso, pueden crear credenciales delegadas falsificadas para todo el período de validez del certificado de entidad final. Esta vulnerabilidad no está presente en implementaciones de TLS 1.3 o posterior. Además, la vulnerabilidad no afecta a los certificados con criptografía de curva elíptica, que SSL.com proporciona. 
  • Las organizaciones pueden utilizar las API de emisión automatizada existentes, como ACME, para entregar credenciales delegadas. En este caso, los algoritmos utilizados son solo los admitidos por la CA, pero esta práctica reduce la posibilidad de compromisos clave. SSL.com respalda esta práctica. 
  • Las credenciales delegadas no se pueden reutilizar en varios contextos. Las partes emisoras calculan la firma utilizando una cadena de contexto única para la función prevista (cliente o servidor), lo que imposibilita el uso de la misma credencial delegada para la autenticación de cliente y servidor. 
SSL.com admite el uso de credenciales delegadas para todos los clientes. La emisión de certificados con capacidad para credenciales delegadas se puede realizar mediante el uso de API para la automatización mediante el protocolo ACME. Ya que SSL.com utiliza ECDSA para implementar la PKI ofrecido clientes, las credenciales delegadas emitidas por nuestros clientes no son vulnerables a los ataques de falsificación de firmas, como se describe anteriormente. 

Artículos Relacionados

Suscríbase al boletín de SSL.com

Que es SSL /TLS?

Reproduce el video

Suscríbase al boletín de SSL.com

No te pierdas los nuevos artículos y actualizaciones de SSL.com