2012-05-23 20 views
46

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?Clarificación SSL bidireccional

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

Respuesta

71

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 manera diferente, pero algún tipo de verificación se necesidad de hacerse .)

El certificado de servidor debe ser creado por una CA de confianza para el cliente (y siguiendo las convenciones de nombres definidos en RFC 6125)

El certificado de 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 entidad emisora ​​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 administració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 autenticación de certificado de cliente, el servidor envía una lista de las CA que está dispuesto a aceptar como parte de la solicitud de certificado de 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 de certificado de 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 todavía 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.

Te puede interesar Advantages of client certificates for client authentication? (on Security.SE).

+2

+1 para una buena explicación y no dar por favor la respuesta de google;) – Dexters

+0

debe reemplazar 'created' con 'signed by' para mantener esto relevante – CharlieS

+1

@CharlieS "* Mantenga esto relevante *" ... ¿Quiere decir que es no relevante al usar "creado" (redacción en línea con la pregunta) ;-)? "Emitido" podría ser una palabra mejor en verdad. – Bruno

23

Lo que usted llama "SSL bidireccional" se suele llamar 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 del certificado de cliente ofrece otra manera 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, puede usar el mismo certificado para PayPal y MyPonyForum sin correr el riesgo de 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 sucede 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 el conexión.

+0

Creé un client-rest-api que llama a server-rest-api (llamada de un solo sentido). Mi cliente-descanso-api usa certificados emitidos por el servidor-descanso-api. Sin embargo, mi cliente-descanso-api nunca emitió ningún certificado para el servidor-descanso-api. ¿Viene bajo one-way-ssl o bidireccional-ssl? Aunque el evento es solo una llamada de un solo sentido de cliente a servidor, creo que es bidireccional ya que aquí el servidor-descanso-api valida que el cliente tenga los certificados apropiados emitidos por el servidor. –

+1

@HimalayMajumdar: si su servidor tiene un certificado firmado por una CA o si ha codificado ese certificado en su cliente (fijación), entonces sí, sigue siendo TLS apropiado con autenticación de certificado de cliente (lo llama bidireccional-ssl). Hurra :-).Sin embargo, si su cliente confía ciegamente en su certificado de servidor, técnicamente sigue siendo TLS con autenticación de certificado de cliente, pero como el cliente no puede verificar el certificado de servidor, no es bidireccional y en la mayoría de los casos es una mala idea. No hagas eso :-(. – NEOatNHNG

+0

Normalmente, cuando escribo un cliente Java llamando a un servicio habilitado para https (https autofirmado), el cliente suele fallar, ya que no confía en el certificado de manera predeterminada. En el caso de mi cliente actual de Java, Solo importé los certs emitidos por el servidor en mi classpath para que el servidor confíe en mi cliente, supongo que al importar los certs mi cliente confía automáticamente en el servidor. Gracias por su respuesta. –

4

En el ssl bidireccional, el cliente solicita un servidor de certificado digital y el servidor solicita lo 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.

Cuestiones relacionadas