¿Entiendo bien cómo funciona SSL?

0

He estado leyendo sobre SSL de 2 vías o autenticación mutua recientemente, y esto es lo que he descubierto hasta ahora:

La autenticación mutua es una forma en que el cliente se autentica en el servidor, al igual que el servidor lo hace con el cliente durante las conexiones SSL (de una vía). Los navegadores web están precargados con los certificados de CA conocidas, por lo tanto, cuando un sitio web envía su clave pública (¿algo como un archivo .cer?), El navegador puede usar el certificado de la CA para determinar si este certificado recibido es válido o no. De manera similar, en SSL de 2 vías, el servidor debe tener el certificado de CA del cliente o el certificado autofirmado mediante el cual se generó el certificado del cliente para confirmar si el cliente es auténtico o no.

Las siguientes son algunas preguntas específicas sobre las cuales aún no estoy claro y apreciaría si alguien pudiera verificar mi comprensión:

  1. El certificado que el servidor envía para SSL de 1 manera solo contiene la clave pública del servidor, ¿verdad? ¿Es esto necesariamente un archivo .cer, o algo así como un archivo .cer?
  2. Los certificados de CA con los que vienen precargados los navegadores, ¿son como certificados .pfx? ¿Y solo con tener estos certificados es suficiente para que el navegador confirme si el certificado recibido del servidor es válido o no?
  3. En caso de certificados autofirmados, ¿el servidor necesita tener el certificado autofirmado .pfx a partir del cual se creó el certificado del cliente?

Supongo que de mis preguntas queda claro que ni siquiera estoy seguro de cuándo se usa la clave pública y la clave privada para el cifrado / descifrado, de modo que cuando responda estas preguntas, le agradecería que también pudiera mencione qué claves se usan con qué propósito cuando se usa un certificado específico.

    
pregunta GrowinMan 05.08.2014 - 08:58
fuente

1 respuesta

1

Abramos un .cer o .pfx por un momento.

¿Qué es un certificado? Es algo que vincula la clave pública con un nombre (simplificación excesiva, pero debería estar bien para esta pregunta). El certificado está firmado por un tercero (autoridad de certificación) que certifica que esta clave pública "pertenece" a este nombre (por ejemplo, www.example.com ).

Ahora, cuando el navegador web se conecta a un sitio SSL, el sitio responde con su certificado. El navegador web luego verifica ese certificado al verificar si está firmado por un certificado raíz de confianza (uno de los precargados con el navegador). Si lo hace, el navegador puede establecer una sesión segura utilizando la clave pública del certificado (porque ahora está seguro de que la clave pública pertenece al sitio al que se está conectando).

En la práctica, los sitios no devuelven un solo certificado, sino una cadena de ellos (certificado de hoja del sitio y uno o más intermedios). Esto no cambia mucho el panorama general, pero ahora el navegador necesita verificar toda la cadena y asegurarse de que termine en uno de los certificados raíz de confianza (es decir, que el certificado de hoja está firmado por el certificado intermedio y el intermedio está firmado por el certificado de raíz).

En cuanto a las claves privadas / públicas ... Los certificados no contienen ninguna clave secreta o privada; solo contienen la clave pública de la entidad. En resumen, la parte que pruebe su identidad debe poseer una clave privada correspondiente a su certificado. Con SSL de 1 vía, esto significa que el servidor debe tener una clave privada correspondiente a su certificado; con 2 vías esto significa que ese cliente también debe tener clave privada correspondiente a su certificado. Cualquier persona con clave privada correspondiente a un certificado puede suplantar al titular del certificado.

A tus preguntas:

  1. El certificado es una clave pública + nombre + otra información; no hay datos privados allí;
  2. Los certificados precargados son exactamente los mismos que los devueltos por el servidor (es decir, sin datos secretos); la "magia" es que son de confianza por el sistema de manera predeterminada, por lo que otros certificados firmados por esos certificados de confianza también serán de confianza;
  3. ¿Estás hablando de autenticación de clientes aquí? El servidor solo necesita el certificado del cliente en el que puede confiar (los certificados autofirmados pueden satisfacer esto) y el certificado del cliente no debe contener absolutamente la clave privada del cliente.

He intentado simplificar un poco las cosas, por lo que no son 100% exactas y hay un espacio para la eliminación de errores :) Pero espero que esto ayude a comprender mejor los conceptos básicos.

    
respondido por el Andrey 05.08.2014 - 09:48
fuente

Lea otras preguntas en las etiquetas