Los certificados SSL (Secure Sockets Layer), también denominados certificados digitales o certificados de clave pública, son documentos digitales firmados por una Autoridad Certificadora (CA por sus siglas en inglés) utilizados para establecer una comunicación segura entre el navegador o computadora de un usuario, y un servidor o sitio web, garantizando la seguridad mediante cifrado robusto de los datos que son transportados como pueden ser datos de tarjeta o credenciales de inicio de sesión. La firma por parte de la CA implica que estos certificados estén verificados utilizando una cadena de confianza, asegurando su fiabilidad.
Los certificados SSL se basan en el protocolo TLS (SSL quedó obsoleto) y son los encargados de que los sitios web cambien de HTTP a HTTPS proporcionando:
- Protección de las comunicaciones. Se protege la transmisión de datos confidenciales, como son los datos de tarjeta, a través de protocolos seguros que utilizan cifrado robusto como es HTTPS.
- Preservación de la integridad de los datos sensibles utilizando algoritmos como MAC (Message Authentication Code) que verifica si ha habido cambios durante la transmisión de la información.
- Autenticación del sitio web evitando suplantaciones de dominio y proporcionando fiabilidad.
NOTA: Este artículo no va enfocado a explicar la criptografía, sino que se centrará en como los certificados SSL protegen información sensible y dan seguridad a los sitios web.
2. Introducción a los certificados SSL
Los certificados SSL contienen la clave pública del sitio web junto con otra información, la cual se explica a continuación, proporcionando el cifrado en las comunicaciones a través del protocolo de enlace TLS y verificando la identidad del servidor. La clave privada se mantiene secreta y segura en el servidor.
La información contenida en los certificados es la siguiente:
- Nombre del dominio protegido por el certificado.
- Sujeto (persona, organización o dispositivo) a quien se emitió el certificado.
- Autoridad Certificadora que lo ha emitido.
- Firma digital de la Autoridad Certificadora.
- Subdominios asociados.
- Fechas de emisión y de caducidad.
- Clave pública.
Otra información adicional (Extensiones o Propiedades) que pueden incluir los certificados:
- Identificador de clave de entidad emisora y del titular
- Nombre alternativo del titular
- Uso mejorado de claves
- Puntos de distribución CRL (Certificate Revocation List)
- Directivas del certificado, acceso a la información de entidad emisora, lista de SCT (Signed Certificate Timestamps)
- Uso de la clave
- Restricciones básicas o la huella digital.
El protocolo de enlace TLS se encarga de crear las conexiones seguras entre cliente y servidor. Este protocolo especificará los siguientes parámetros:
- Versión de TLS y suites de cifrado para seleccionar el cifrado en la comunicación.
- Autenticar al servidor a través de su clave pública y de la firma digital de la CA.
- Clave de sesión para proteger la comunicación con el cifrado simétrico.
El intercambio de claves puede resumirse con la siguiente ilustración:
El proceso se resume a continuación:
- El servidor envía al navegador del cliente una copia de la clave pública asimétrica.
- El navegador crea una clave de sesión simétrica para proteger las comunicaciones con el servidor. Esta clave se cifra con la clave pública del servidor y se envía al propio servidor.
- El servidor descifra la clave de sesión utilizando su clave privada que está almacenada en el servidor.
- Cliente y servidor establecen una sesión segura utilizando la clave de sesión simétrica compartida.
3. Validación de los certificados
La validación de certificados consiste en demostrar a la Autoridad Certificadora quien es el propietario del dominio. Para ello es necesario realizar distintas comprobaciones que dependerán del tipo de validación. Hay tres tipos de validaciones:
3.1 Validación por dominio (DV)
Para la emisión de certificado, la Autoridad Certificadora validará el nombre de dominio del aplicante demostrando cierto control sobre un dominio DNS, es decir, demostrando que se tiene un control sobre el dominio utilizando uno de los criterios siguientes:
- Respuesta a un correo mandado al email de contacto que aparece en los detalles de registros whois.
- Respuesta a correos mandado a un contacto administrativo en el dominio (administrador, postmaster, etc.).
- Publicando un registro DNS TXT.
- Publicando un reto “nonce” proporcionado por un sistema de emisión de certificados automático.
La validación por dominio es la menos segura ya que los visitantes no pueden validar si la identidad del sitio web es legítima, favoreciendo los ataques por phishing, lo que podría impactar en la imagen y seguridad de estos sitios web.
3.2 Validación por organización (OV)
La validación por organización realizada por la Autoridad Certificadora se centra en la identidad del negocio y su legitimidad, proporcionando un nivel adicional de confianza. Las organizaciones tienen que probar que les pertenece el nombre de dominio y que realmente este se encuentra legalmente registrado, pudiendo incluir la verificación de la localización registrada, números de teléfono, estado bancario, artículos de incorporación o la propiedad del dominio.
Esta validación añade confianza al sitio web al demostrar que no se trata de un sitio web falso, añadiendo un candado y el prefijo HTTPS en la barra del navegador del visitante, indicando que se trata de un sitio cifrado.
3.3 Validación extendida (EV)
La validación extendida proporciona el nivel más alto de autenticación y cifrado. Es el nivel de validación más largo y el que más cuesta, pero son los certificados más fiables. Se verifica información de la organización como es el nombre legal, la marca, quién controla el dominio o la autenticidad del acuerdo de subscripción.
Esta validación proporciona un nivel más de confianza añadiendo a la barra de direcciones de ciertos navegadores el color verde sobre el nombre de dominio, así como los detalles de la organización en el certificado.
4. Tipos de certificados
4.1 Certificados autofirmados
Estos certificados no se encuentran firmados por ninguna CA, sino que se encuentran firmados con su propia clave privada, por lo que carecen de la confianza proporcionada por las CA, siendo las comunicaciones con equipos que tengan instalado este tipo de certificados no confiables. Estos certificados contienen una clave pública, información acerca del propietario y su firma.
Estos certificados son más fáciles y rápidos de emitir, así como más flexibles a la hora de customizarlos. Pueden utilizarse para probar configuraciones SSL. Por el contrario, estos certificados no ofrecen confianza a los usuarios y no pueden ser revocados por una CA en caso de algún incidente de seguridad, que comprometería la seguridad en el entorno.
4.2 Certificados de dominio único
Los certificados de dominio único permiten añadir seguridad TLS a un único dominio, protegiendo los datos sensibles que sean comunicados hacia/desde el propio dominio, incluyendo a todas las páginas que se encuentren en este dominio.
No permiten autenticar ningún otro dominio o subdominio del propio dominio.
Por ejemplo, si se encuentra protegido el dominio https://www.example1.com, se encontrarán protegidas también las páginas https://www.example1.com/servicios o https://www.example1.com/biblioteca.
4.3 Certificados wildcard
Los certificados wildcard aplicarán tanto a un dominio como a un subdominio, los cuales compartirán clave privada. Esta clave privada tiene que encontrarse en cada uno de los servidores donde se encuentre el subdominio.
Los certificados wildcard facilitan el proceso de gestión e instalación de certificados en un dominio, ya que el mismo certificado sería compartido por todos sus subdominios, así como suponen un ahorro económico en empresas con más de un servicio a proteger debido a la utilización de un único certificado para todos ellos. Sin embargo, cuenta con una serie de riesgos para la seguridad en el entorno:
- En caso de verse comprometida la clave privada de uno de los dominios o subdominios, peligraría la integridad y la confidencialidad de cualquier comunicación con equipos que tengan instalado el certificado debido a que esta clave es compartida.
- Los certificados wildcard no permiten la validación extendida, por lo que el nivel de confianza que proporcionan no sería tan elevado.
- Este tipo de certificado favorece ataques de phishing.
4.4 Certificados multidominio (SAN – Subjects Alternative Names)
Los certificados SAN incluyen varios dominios distintos que se verían protegidos por un mismo certificado. Como en el caso de los certificados wildcard, la clave privada queda compartida por todos los dominios, por lo que si queda comprometida la clave de uno de los dominios se compromete la seguridad de todos los dominios bajo ese certificado. Por tanto, estos certificados incluyen riesgos derivados de la compartición de clave privada, pero permiten un nivel de protección superior, sobre todo a nivel de autenticidad.
Los certificados multidominio incluyen más campos, por lo que podría impactar en el rendimiento del sitio web que protege.
Por ejemplo, si la empresa “Example1” quisiera proporcionar seguridad a su propio dominio y al de un Partner (“Example2”), el certificado emitido protegería a https://www.example1.com y a https://www.example2.com.
5. Certificados en la normativa PCI DSS
El estándar PCI DSS, en su versión 3.2.1, señala en el requisito 4.1 que se deben proteger con cifrado y protocolos seguros las comunicaciones para poder transferir datos de tarjeta de forma segura a través de redes públicas y abiertas. Para proteger las comunicaciones deben utilizarse certificados confiables que proporcionen cifrado robusto. Estos certificados deben estar en vigor y emitidos por una fuente confiable. En este requisito se hace referencia a estándares desarrollados por la industria como son el NIST SP 800-52 y SP 800-57, o OWASP para la correcta utilización de los mismos.
5.1 NIST SP 800-52
El estándar NIST SP 800-52 establece una guía para la selección, configuración y uso de TLS en los certificados. Esta guía establece una serie de mínimos:
- Los certificados deben estar firmados por un algoritmo seguro: RSA, ECDSA, DSA, Diffie-Hellman o ECDH. Establece como mínimo RSA o ECDSA con curva de P-256 o P-384 en clave pública.
- Los servidores deben estar configurados con certificados emitidos por una CA que publique información de revocación en OCSP para comprobar su validez. La fuente de revocación debe incluirse en el certificado emitido por la CA.
- Los certificados deben ser del tipo X.509 versión 3, por lo que deben incluir los siguientes campos: Versión, número de serie, información sobre el algoritmo, emisor, periodo de validez, sujeto y clave pública.
- La clave pública contenida en el certificado y la firma tienen que proporcionar, al menos, 112 bits de seguridad.
- Este estándar no hace recomendaciones sobre qué nivel de validación utilizar.
Por tanto, con este estándar los certificados autofirmados no serían válidos para proteger las comunicaciones hacia el exterior desde un entorno PCI DSS debido a que los certificados deben ser emitidos por una CA, así como incluir la información de revocación en OCSP.
5.2 NIST SP 800-57
El estándar NIST SP 800-57 se basa en recomendaciones sobre la gestión de claves, y hace referencia a la gestión de las claves y de los certificados electrónicos dentro de una organización:
- Los algoritmos criptográficos deben tener una robustez de seguridad mínima de 112 bits. Dependiendo del tipo de algoritmo, se define una robustez asociada a este mínimo de 112 bits:
- Algoritmos de cifrados FFC: DSA, DH o MQV. Claves públicas de 2048 bits y privadas de 224.
- Algoritmos criptográficos IFC: RSA. Claves de 2048 bits.
- Algoritmos de cifrado de curva elíptica (ECC): ECDSA, EdDSA, DH o MQV. Claves de 224 a 255 bits.
- Para firmas digitales. Funciones hash como SHA-224, SHA-512/224, SHA3-224.
- Debe mantenerse un inventario con todos los certificados que se emiten en una organización, así como de las claves criptográficas utilizadas. Este inventario debe mantenerse actualizado.
- Los certificados deben tener establecido un periodo de validez que no sobrepase el final del criptoperiodo de las claves utilizadas.
- Como parte del Plan de Respuesta ante Incidentes o el Plan de Continuidad de Negocio, debe establecerse un plan para proteger a la organización ante incidentes de seguridad relacionados con los certificados SSL o tener preparada una respuesta en caso de incidencias con los mismos, así como revocar el certificado en todos los servidores si una clave privada se ve comprometida ya que las comunicaciones con ese sitio web se verían comprometidas pudiendo afectar a la confidencialidad e integridad de los datos intercambiados (datos de tarjeta, credenciales de acceso, etc.).
5.3 OWASP
El proyecto OWASP establece unas pautas para la protección de los certificados:
- Claves de longitud mínima de 2048 bits, así como SHA-256 como algoritmo hash.
- Recomienda no utilizar certificados wildcard por violar el principio de mínimo privilegio y aumentan la probabilidad de compromiso de seguridad de las claves privadas. Estos certificados no pueden ser utilizados para sistemas en diferentes niveles de seguridad dos gateways VPN, múltiples instancias de aplicaciones web, un Gateway de VPN con un webserver público, o un webserver público con un servidor interno).
- Los certificados deben ser firmados por CAs confiables.
- Considerar el uso de Validación Extendida (EV) para proporcionar el nivel más alto de verificación, así como realizar las comprobaciones de que se trata de una entidad legal.
Por tanto, con este estándar los certificados wildcard no serían recomendados para un entorno PCI DSS, así como la preferencia de certificados de dominio único frente a los certificados multidominio debido a que se comparte la clave pública entre los sistemas como ocurre con los certificados wildcard.
6. Recomendaciones de seguridad y conclusiones
Una vez analizados cada uno de los tipos de certificados SSL quedan claras varias conclusiones acerca de la protección de las comunicaciones externas:
- Para entornos PCI DSS, de acuerdo con el requisito 4.1, se debe verificar que los certificados son confiables. Para ello, estos no tienen que haber expirado y deben ser emitidos por una fuente confiable.
- No utilizar para las conexiones externas desde entornos PCI DSS certificados autofirmados debido a que no son emitidos por fuentes confiables ni pueden ser revocados.
- De acuerdo con los estándares de referencia de la industria (NIST y OWASP), las claves de los certificados deben ajustarse a unos mínimos de seguridad.
- El estándar OWASP, recomienda no utilizar certificados wildcard en el entorno productivo por introducir riesgos innecesarios.
- Del mismo modo que en el punto anterior, con OWASP se da preferencia a los certificados de dominio único por los riesgos que incluyen los certificados multidominio por la compartición de la clave pública en los sistemas.
Por tanto, como conclusión, para entornos PCI DSS que quieran tener protegidas comunicaciones con el exterior se recomienda la utilización de certificados de dominio único por dotar de una seguridad adicional a los canales por los que viajan los datos de tarjeta. No obstante, es importante consultar con una empresa QSA para analizar los detalles de cada entorno en concreto y dirimir la mejor solución de cara al cumplimiento del estándar PCI DSS y en pro de la seguridad de dicho entorno y la información que en él se trata.
Referencias:
- PCI DSS:
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf?agreement=true&time=1645690449063 - NIST SP 800-52:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf - NIST SP 800-57:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf - OWASP:
https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
Autor: Diego de la Horra - PCIP, CSFPC
Dpto. Consultoría
