En criptografía y seguridad informática , un certificado autofirmado es un certificado de seguridad que no está firmado por una autoridad de certificación (CA). Estos certificados son fáciles de hacer y no cuestan dinero. Sin embargo, no proporcionan todas las propiedades de seguridad que los certificados firmados por una CA pretenden proporcionar. Por ejemplo, cuando el propietario de un sitio web utiliza un certificado autofirmado para proporcionar servicios HTTPS , las personas que visitan ese sitio web verán una advertencia en su navegador. Los visitantes del sitio web que eluden tales advertencias están expuestos al riesgo de que un tercero intercepte el tráfico al sitio web utilizando el certificado autofirmado del tercero. Este es un tipo deataque man-in-the-middle (MitM), y permite que el tercero lea y modifique todos los datos enviados hacia o desde el sitio web por el usuario objetivo.
En comparación, los visitantes de un sitio web que utiliza un certificado firmado por una CA no verán advertencias sobre los certificados autofirmados. Debido a que estos visitantes no se acostumbran a eludir las advertencias del navegador, son menos vulnerables a un ataque MitM. Sin embargo, todos los visitantes del sitio web pueden seguir siendo vulnerables a un ataque MitM si una CA en la que confía su navegador se ve comprometida o emite maliciosamente un certificado incorrecto para el sitio web de destino. (La mayoría de los navegadores tampoco dan advertencias para visitar un sitio web utilizando HTTP sin cifrar, que es menos seguro que HTTPS con un certificado autofirmado).
En las aplicaciones de certificados fuera de HTTPS en un navegador web, los certificados autofirmados tienen propiedades diferentes. Por ejemplo, si un servidor HTTPS o TLS está configurado con un certificado autofirmado, los clientes que no sean navegadores que se conectarán a ese servidor pueden configurarse para confiar explícitamente en ese certificado autofirmado específico. Siempre que la información de configuración para el cliente se proporcione de forma segura y la configuración se realice correctamente, esto puede resultar en una comunicación segura entre el cliente y el servidor que no es vulnerable a MitM.
Temas de seguridad
En un sistema PKI basado en CA, ambas partes deben confiar en la CA. Por lo general, esto se logra colocando los certificados de CA en una lista blanca de certificados de confianza. Por ejemplo, los desarrolladores de navegadores web pueden utilizar procedimientos especificados por CA / Browser Forum , o puede colocarse un certificado de CA privado en el firmware de un sistema integrado . Los problemas de confianza de una entidad que acepta un nuevo certificado autofirmado son similares a los problemas de una entidad que confía en la adición de un nuevo certificado de CA. Las partes en una PKI autofirmada deben establecer confianza entre sí (utilizando procedimientos fuera de la PKI) y confirmar la transferencia precisa de claves públicas (por ejemplo, comparar el hash fuera de banda).
Existen muchas diferencias sutiles entre los certificados firmados por una CA y los certificados autofirmados, especialmente en la cantidad de confianza que se puede depositar en las afirmaciones de seguridad del certificado. Algunas CA pueden verificar la identidad de la persona a la que emiten un certificado; por ejemplo, el ejército de los EE. UU. emite sus tarjetas de acceso común en persona, con múltiples formas de otra identificación. La CA puede dar fe de valores de identidad como estos incluyéndolos en el certificado firmado. La entidad que valida el certificado puede confiar en la información contenida en ese certificado, en la misma medida en que confía en la CA que lo firmó (y, por ende, en los procedimientos de seguridad que la CA utilizó para verificar la información certificada).
En cambio, con un certificado autofirmado, la confianza de los valores en el certificado es más complicada porque la entidad posee la clave de firma y siempre puede generar un nuevo certificado con valores diferentes. Por ejemplo, es posible que no se confíe en las fechas de validez de un certificado autofirmado porque la entidad siempre puede crear y firmar un nuevo certificado que contenga un intervalo de fechas válido. Se puede confiar en los valores de un certificado autofirmado cuando se cumplen las siguientes condiciones: los valores se verificaron (fuera de banda) cuando se confiaba formalmente en el autofirmado y existe un método para verificar el certificado autofirmado no ha cambiado después de que se confió en él. Por ejemplo, el procedimiento de confiar en un certificado autofirmado incluye una verificación manual de las fechas de validez y un hash del certificado se incorpora a la lista blanca. Cuando se presenta el certificado para que una entidad lo valide, primero verifican que el hash del certificado coincide con el hash de referencia en la lista blanca y si coinciden (lo que indica que el certificado autofirmado es el mismo que el que se confiaba formalmente ), entonces se puede confiar en las fechas de validez del certificado. El tratamiento especial de los campos del certificado X.509 para el certificado autofirmado se puede encontrar en RFC 3280. [1]
Hay al menos dos razones por las que una PKI basada en certificado autofirmado puede haber reducido el riesgo general. La primera, también compartida con los sistemas PKI privados, es que evitan los problemas de confiar en terceros que pueden firmar certificados de forma indebida. Las transacciones de certificados autofirmados suelen presentar una superficie de ataque mucho menor al eliminar tanto la compleja validación de la cadena de certificados [1] como las comprobaciones de revocación de CA como CRL y OCSP .
La revocación de certificados autofirmados difiere de los certificados firmados por CA. El certificado autofirmado no puede (por naturaleza) ser revocado por una CA. [2] La revocación de un certificado autofirmado se logra eliminándolo de la lista blanca de certificados de confianza (esencialmente lo mismo que revocar la confianza en una CA). No revocar un certificado autofirmado puede permitir que un atacante que ya ha obtenido acceso supervise e inyecte datos en una conexión falsifique una identidad si una clave privada se ha visto comprometida.
Otros asuntos
Costo Los certificados autofirmados se pueden crear de forma gratuita utilizando una amplia variedad de herramientas, incluidas OpenSSL , la herramienta de claves de Java, Adobe Reader y el llavero de Apple.
Velocidad de implementación Los certificados autofirmados requieren que las dos partes interactúen (por ejemplo, para intercambiar claves públicas de forma segura). El uso de una CA solo requiere que la CA y el titular del certificado interactúen; el titular de la clave pública puede validar su autenticidad con el CA certificado raíz .
Personalización Los certificados autofirmados son más fáciles de personalizar, por ejemplo, un tamaño de clave más grande, datos contenidos, metadatos, etc.
Ver también
- Autoridad certificadora § Debilidad en la implementación del esquema de terceros de confianza
- X.509 , el estándar que describe el formato más utilizado para almacenar certificados
- Let's Encrypt , una autoridad de certificación que proporciona certificados validados de dominio gratuitos [3]
Referencias
- ^ a b "Certificado y perfil de CRL - RFC 3280" . tools.ietf.org . Consultado el 6 de abril de 2017 .
- ^ http://www.ietf.org/rfc/rfc2459.txt
- ^ "Beta pública" . Encriptemos . Consultado el 6 de diciembre de 2015 .