Detalles de la verificación del certificado TLS

2

Entiendo lo básico de la criptografía, pero no estoy seguro de los siguientes tres pasos:

Paso 1: cómo calcular un certificado TLS

Corrígeme si me equivoco: La autoridad de certificación calcula un valor de hash sobre la información de certificado relevante (incluida la clave pública del solicitante del certificado), luego firma este valor de hash utilizando la clave privada de la autoridad. El resultado de este proceso es un único archivo de certificado que se puede implementar en servidores que tienen acceso a la clave privada correspondiente.

Paso 2: ¿Cómo verificar que el servidor posee la clave privada correspondiente al certificado TLS?

El cliente obtiene el certificado del servidor durante el protocolo de enlace TLS. Pero el certificado por sí solo no es suficiente para verificar la autenticidad de los datos. (ya que cualquiera puede enviar una copia de un certificado sin poseer la clave privada) ¿Por lo tanto, creo que debe haber alguna información aleatoria adicional transmitida, que debe firmarse con la clave privada correspondiente (quizás también al calcular un hash)?

¿El cliente descifra esta información aleatoria con la clave pública del certificado? ¿Cómo se realiza esta comprobación?

Paso 3: ¿Cómo verificar que el certificado está firmado por una autoridad confiable?

Creo que esto funciona principalmente con tablas de navegador preinstaladas que contienen las claves públicas de las autoridades confiables (entre otra información).

¿Se utilizan las claves públicas de la entidad emisora de certificados para descifrar un valor de hash y comprobar si coincide con un valor de hash autocálculo en todo el certificado?

    
pregunta Mike76 08.10.2016 - 20:40
fuente

1 respuesta

3

Una respuesta a la pregunta 1:

Sí, excepto que la raíz de la AC está fuera de línea en un HSM en una bóveda, no está disponible para ser robada electrónicamente. La raíz se usó para firmar un puñado de certificados intermedios (copias de seguridad y certificados de respuesta de OCSP y otras cosas) que residen en HSM que están directamente conectados a las computadoras a las que se puede acceder electrónicamente.

Para emitir un certificado, la CA "backend":

  1. recibe CSR
  2. utiliza algún método de validación (protocolo ACME, clic humano "ok" en el sitio web de administración, etc.)
  3. registra todas las decisiones y la información utilizada para tomar la decisión de verificar mediante una auditoría posterior
  4. genera los datos del certificado (X.509 v3) codificados en X.690 DER, utilizando una plantilla y un nuevo número de serie / fuente de aleatoriedad.
  5. tal vez obtenga el Certificado de Transparencia SCTs.
  6. pide al HSM que firme el blob (o hash del blob).
  7. adjunta la firma al certificado y la envía al almacenamiento de cara al cliente.

Una respuesta a la pregunta 2:

En el intercambio de claves RSA, el cliente genera una secuencia aleatoria de bytes y realiza el cifrado RSA utilizando la clave pública del certificado del servidor. Luego, el cliente envía el texto cifrado resultante al servidor y espera que el servidor lo descifre (utilizando la clave privada correspondiente a la clave pública del certificado) y use el valor aleatorio en un KDF, junto con otros valores, para generar claves simétricas y enviar un mensaje terminado encriptado con las claves simétricas resultantes. El cliente verifica el mensaje finalizado. El servidor solo puede generar correctamente las claves simétricas esperadas descifrando el mensaje cifrado RSA. enlace

En el intercambio de claves DHE / ECDHE con PFS, el servidor firma su clave efímera utilizando la clave privada correspondiente a la clave pública en el certificado y la envía a ServerKeyExchange. El cliente verifica la firma usando la clave pública del certificado. enlace

Una respuesta a la pregunta 3: El navegador contiene una lista de raíces confiables (Mozilla Firefox lo hace) o usa una lista de raíces confiables proporcionada por el sistema operativo (Google Chrome usa la tienda de raíces del sistema operativo). El almacén raíz contiene certificados autofirmados y algunos metadatos sobre ellos que podrían restringir su uso. Los navegadores también contienen código que agrega controles adicionales, como Chrome que requiere la transparencia del certificado de las CA de propiedad de Symantec y las fechas límite que permiten el uso de certificados SHA1.

La forma en que se verifica un servidor de hoja / certificado de dominio mediante el almacén raíz es mediante la creación de una cadena de certificados intermedios, uno que firma al otro, desde una raíz confiable a la hoja. La raíz muestra un signo intermedio y el intermedio firma la hoja. Puede haber más de un intermedio en una cadena. Los intermedios son enviados por el servidor junto con la hoja. enlace

Las diferentes computadoras tienen diferentes almacenes de raíz y al usar la firma cruzada, se pueden construir muchas rutas diferentes. Actualmente, los navegadores intentan crear rutas sha256 solo si es posible, a veces fallan y producen un error que indica que solo se construyó una ruta sha1, por lo que la conexión puede ser insegura.

No confunda las firmas digitales con cifrado: enlace

    
respondido por el Z.T. 08.10.2016 - 21:11
fuente