ssl two-way

Clarificación SSL bidireccional



two-way (3)

Estoy algo confundido sobre cómo funciona el SSL bidireccional. ¿Cómo crea el cliente su certificado para enviar al servidor? ¿Se genera desde el servidor y se distribuye al cliente?

Además, ¿cuál es la ventaja de SSL bidireccional sobre SSL unidireccional?


Ambos certificados deben existir antes de la conexión. Generalmente las crean las Autoridades de Certificación (no necesariamente lo mismo). (Hay casos alternativos donde la verificación se puede hacer de forma diferente, pero será necesario realizar alguna verificación).

El certificado del servidor debe ser creado por una CA en la que el cliente confíe (y siga las convenciones de nomenclatura definidas en RFC 6125 ).

El certificado del cliente debe ser creado por una CA en la que confíe el servidor.

Depende de cada parte elegir lo que confía.

Existen herramientas de CA en línea que le permitirán solicitar un certificado dentro de su navegador e instalarlo allí una vez que la CA lo haya emitido. No necesitan estar en el servidor que solicita la autenticación del certificado del cliente.

La distribución de certificados y la gestión de confianza es la función de la Infraestructura de clave pública (PKI), implementada a través de las CA. El cliente y los servidores SSL / TLS y luego meramente usuarios de esa PKI.

Cuando el cliente se conecta a un servidor que solicita la autenticación del certificado del cliente, el servidor envía una lista de las CA que está dispuesto a aceptar como parte de la solicitud del certificado del cliente. El cliente puede enviar su certificado de cliente, si así lo desea y uno adecuado está disponible.

Las principales ventajas de la autenticación del certificado del cliente son:

  • La información privada (la clave privada) nunca se envía al servidor. El cliente no deja salir su secreto durante la autenticación.
  • Un servidor que no conoce a un usuario con ese certificado aún puede autenticar a ese usuario, siempre que confíe en la CA que emitió el certificado (y que el certificado es válido). Esto es muy similar a la forma en que se usan los pasaportes: es posible que nunca haya conocido a una persona que le muestre un pasaporte, pero como confía en la autoridad emisora, puede vincular la identidad con la persona.

Usted puede estar interesado en Ventajas de certificados de cliente para autenticación de cliente? (en Security.SE) .


En ssl bidireccional, el cliente solicita el certificado digital de servidor y el servidor solicita el mismo al cliente. Es más seguro ya que es en ambos sentidos, aunque es un poco lento. En general, no lo seguimos, ya que al servidor no le importa la identidad del cliente, pero el cliente debe asegurarse de la integridad del servidor al que se está conectando.


Lo que usted llama "SSL bidireccional" generalmente se llama TLS / SSL con autenticación de certificado de cliente.

En una conexión TLS "normal" a example.com, solo el cliente verifica que efectivamente se está comunicando con el servidor para example.com. El servidor no sabe quién es el cliente. Si el servidor quiere autenticar al cliente, lo habitual es usar contraseñas, por lo que un cliente debe enviar un nombre de usuario y contraseña al servidor, pero esto sucede dentro de la conexión TLS como parte de un protocolo interno (por ejemplo, HTTP), no es parte del protocolo TLS en sí. La desventaja es que necesita una contraseña diferente para cada sitio porque envía la contraseña al servidor. Entonces, si usa la misma contraseña en, por ejemplo, PayPal y MyPonyForum, cada vez que inicie sesión en MyPonyForum, envíe esta contraseña al servidor de MyPonyForum para que el operador de este servidor pueda interceptarla y probarla en PayPal y pueda realizar pagos a su nombre .

La autenticación de certificado de cliente ofrece otra forma de autenticar al cliente en una conexión TLS. A diferencia del inicio de sesión con contraseña, la autenticación del certificado del cliente se especifica como parte del protocolo TLS. Funciona de forma análoga a la forma en que el cliente autentica el servidor: el cliente genera un par de claves privadas públicas y envía la clave pública a una CA confiable para firmar. La CA devuelve un certificado de cliente que se puede usar para autenticar al cliente. El cliente ahora puede usar el mismo certificado para autenticarse en diferentes servidores (es decir, podría usar el mismo certificado para PayPal y MyPonyForum sin arriesgarse a que se abuse de él). La forma en que funciona es que una vez que el servidor ha enviado su certificado, también le pide al cliente que proporcione un certificado. Luego ocurre algo de magia de clave pública (si desea conocer los detalles, lea RFC 5246 ) y ahora el cliente sabe que se comunica con el servidor correcto, el servidor sabe que se comunica con el cliente correcto y ambos tienen material clave común para encriptar y verificar la conexión.