Autenticación del certificado de cliente SSL

Los certificados son solo la clave pública con algún contexto agregado. El nombre de la clave, las firmas, las pautas de uso, etc. SSL / TLS depende de ese contexto. De lo contrario, el host al que te estás conectando no sabrá si la clave realmente te pertenece o no. El mecanismo de confianza de SSL se basa en el concepto de certificados de confianza explícitos y luego en los certificados de confianza implícitos que firman.

Pero si no está utilizando SSL o TLS, el cifrado aún puede ocurrir sin él, pero la confianza tiene que ocurrir de una manera diferente. SSH es un buen ejemplo de esto: SSH todavía usa claves públicas y privadas, pero como no hay una jerarquía de firmas, la información adicional que proporcionan los certificados no sería útil, por lo que la clave se envía sin restricciones. En su lugar, el cliente le pregunta si confía o no en la clave pública del servidor la primera vez que se conecta, y cada vez que lo verifica, verifica si la clave pública coincide con la que vio la última vez. Esto puede suceder porque SSH no usa SSL o TLS para su cifrado.

Pero si está utilizando el protocolo SSL, el protocolo dicta que la clave pública debe presentarse con el contexto agregado del certificado. Es decir, el certificado es el contenedor en el que se debe colocar la clave pública para que SSL lo use.

Si tiene la clave privada, es trivial crear un certificado autofirmado con una herramienta como OpenSSL.

SSL / TLS admite la autenticación de clientes con un certificado. Lo que realmente sucede internamente es que:

• El servidor solicita un "certificado de cliente" a través de un mensaje CertificateRequest .
• El cliente envía su certificado como un mensaje Certificate , y también calcula una firma (usando su clave privada) sobre todos los mensajes anteriores en el protocolo de enlace; la firma se envía como un mensaje CertificateVerify .
• El servidor de alguna manera obtiene la clave pública del cliente (normalmente descodificando el certificado del cliente como X .509 , validándolo de la forma X.509 y luego extrayendo la clave pública de él) y lo utiliza para verificar la firma del cliente.

Sin embargo, en el protocolo en sí, los certificados se intercambian como fragmentos opacos de bytes; cada "certificado" se envía con un encabezado de 3 bytes que especifica su longitud. Por lo tanto, si usted controla tanto el código del servidor como el del cliente, entonces depende de usted decidir cómo se interpretarán estos trozos de bytes. No necesita enviar un certificado X.509 . Si lo desea, puede enviar un mensaje vacío.

Los puntos importantes permanecen:

• Para que la autenticación tenga sentido, el servidor debe saber con alguna garantía la clave pública del cliente. La firma demuestra que el cliente controla la clave privada, pero esto solo sirve si la clave pública correspondiente está unida sin ambigüedad a una identidad de cliente conocida.

• El par de claves debe ser de un tipo adecuado para firmas (es decir, RSA o DSA, no Diffie-Hellman).

Las implementaciones SSL existentes podrían insistir en al menos respetar el formato X.509, en cuyo caso tiene que envolver su clave pública en una especie de certificado X.509 autofirmado, que es relativamente fácil de programar con algunas bibliotecas como OpenSSL .

Hay un estándar para reemplazar los certificados X.509 en SSL con las claves públicas de OpenPGP, lo que demuestra la agilidad del formato inherente a SSL.

(Esto se basa en mi respuesta a la misma pregunta en SO . A menudo es mejor preguntar en una sola SE sitio.)

El protocolo TLS solo permite el intercambio de certificados, no las claves públicas sin formato. Incluso "claves PGP" (si desea reemplazar X.509 con OpenPGP para la autenticación en TLS , que es mucho menos compatible ) son certificados de hecho (son la combinación firmada de una clave pública y un conjunto de identificadores y atributos).

Como dice Thomas, posiblemente puedas definir tu propio tipo de certificado y convertirlo en una clave pública simple (aunque no estoy seguro de que aún se puedan llamar "certificados" técnicamente).

Desde un punto de vista práctico, debería poder lograr lo que necesita utilizando las pilas SSL / TLS existentes, y ajustar la forma en que tratan los certificados de verificación X.509, con precaución . De hecho, la mayoría de las pilas SSL / TLS exponen la verificación de los certificados X.509 a través de sus API, pero pocos permiten otros tipos de certificados (por ejemplo, OpenPGP) o le permiten personalizar su código fácilmente. La personalización de certificados que no sean X.509 puede ser bastante difícil, puede resultar en errores adicionales si es nuevo en la implementación de SSL / TLS y también sería difícil de implementar en la práctica, ya que todos los clientes potenciales también necesitarían ser compatibles con sus personalizaciones. .

Puede realizar la autenticación del cliente utilizando certificados X.509 de cliente autofirmados y confiar en sus claves públicas ( pero deberá verificar esta clave pública contra algo que su servidor ya conoce, como una lista conocida ). Debe comprender las implicaciones de seguridad para implementar esto primero. Este no es el mismo problema que los certificados de servidor autofirmados. (Sugiero mantener un enfoque más tradicional para verificar el certificado del servidor).

Puede hacer que el cliente envíe un certificado autofirmado (posiblemente utilizando ciertos trucos con respecto a la lista de CA anunciada por el servidor ) y realice la verificación en la pila TLS o más adelante en la aplicación.

Tenga en cuenta que muchos contenedores de aplicaciones (por ejemplo, Tomcat / Jetty en Java) esperan que la capa SSL / TLS verifique el certificado del cliente. Por lo tanto, si omite la autenticación allí (y prefiere hacerlo más adelante dentro del contenedor o como parte de la aplicación), muchos marcos de aplicación se confundirán. Debe tener mucho cuidado para asegurarse de que la autenticación se realice realmente en algún lugar antes de realizar cualquier acción que requiera autenticación en su aplicación.

Por ejemplo, puede estar bien tener un administrador de confianza que permita que cualquier certificado de cliente pase por Tomcat / Jetty, pero no puede confiar en que el atributo de solicitud javax.servlet.request.X509Certificate haya sido verificado de ninguna manera (que la mayoría de los marcos) de lo contrario esperaría). Necesitaría implementar alguna lógica de verificación dentro de su aplicación: por ejemplo, tener un filtro antes de cualquier función autenticada que compare la clave pública en este certificado de cliente con su lista conocida de claves públicas (o sin embargo, desea hacer coincidir la clave pública con un identificador). Alternativamente, también puede realizar esta verificación dentro de su administrador de confianza personalizado (en Java), esto requerirá menos trabajo dentro de las aplicaciones.

Podría hacer algo similar en una configuración de Apache Httpd + PHP (por ejemplo), usando SSLVerifyClient optional_no_ca . Una vez más, su aplicación PHP no puede confiar en que el certificado haya sido verificado, por lo que tendría que implementar la verificación también.

No hagas nada de esto a menos que entiendas en qué etapa se verificó la información del certificado que obtuviste.

además de nuestro querido amigo, tylerl

deberías saber sobre el comando OpenSSL de Linux y tener una buena habilidad para programar en PHP o en perl (especialmente PHP) Aquí hay una buena guía sobre eso: 1- enlace y 2-openssl. org debe tener un conocimiento profundo sobre el comando openssl y sus funciones.

al final: (tu pregunta) ¿Es posible enviar la clave pública del servidor en lugar del certificado del cliente para la autenticación del certificado del cliente? no, debido a que puede olvidar el protocolo de protocolo de enlace TLS, que muestra paso a paso el servidor-cliente, la autenticación y el intercambio de claves. enlace