Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
| master_cs:secom:tm1_v2 [2026/05/24 21:48] – thejuanvisu | master_cs:secom:tm1_v2 [2026/05/25 22:13] (actual) – [Problemas con la infraestructura PKI actual] thejuanvisu | ||
|---|---|---|---|
| Línea 226: | Línea 226: | ||
| * Public Key: Contiene el ID del algoritmo, parámetros opcionales y la propia clave pública. | * Public Key: Contiene el ID del algoritmo, parámetros opcionales y la propia clave pública. | ||
| + | Se puede extender el certificado con las siguientes extensiones: | ||
| + | * Subject Alternative Name: Sustituye el campo subject, soporta múltiples identidades especificadas por nombre DNS, dirección IP o URI. | ||
| + | * Name Constraints: | ||
| + | * Basic Constraints: | ||
| + | * Key Usage: usa el certificado de un un set restringido conocido. | ||
| + | * Extended Key Usage: Puede detallar temas ás específicos con propósitos arbitrarios | ||
| + | * Certificates Policies: Liste de enlaces donde se puede obtener todo el texto de la política. | ||
| + | * CRL Distribution Points: Ubicación de la Lista de certificados revocados (CRL) | ||
| + | * Authority information Access: Varias URI, entre ellas la localicación del OCSP responder. | ||
| + | * Subject Key Identifier: Identificador único para la clave pública, normalmente un hash. | ||
| + | * Authority Key Identifier: Identificador único de la clave que firmó el certificado. Debe coincidir con el SKI del que firmó el certificado. | ||
| + | |||
| + | Los certificados tienen el siguiente ciclo de vida: | ||
| + | {{drawio> | ||
| + | |||
| + | ==== Infraestructura PKI ==== | ||
| + | * Solicitud de firma de certificado: | ||
| + | * Validación de indentidad del Suscriptor: Hay varias estrategias de validación: | ||
| + | * Validación de Dominio (DV): Prueba de control de un nombre de dominio dado. | ||
| + | * Envío de email a direcciones bien conocidas | ||
| + | * Adición de registro a la zona del dominio | ||
| + | * ACME challenge. | ||
| + | * Puede ser automatizada y realizada en segundos. | ||
| + | * Validación de Organización (OV): Requiere verificación de identidad y verificación. Puede haber inconsistencias en el procedimiento y en el codificado de la información. | ||
| + | * Validación Extendida (EV): Requiere identidad y autenticidad con requerimientos muy estrictos. Alternativa a Certificados OV. Puede tomar días o semanas. | ||
| + | * Revocación: | ||
| + | * Certification Revocation List (CRL): Lista el número de serie de certificados revocados no expirados. | ||
| + | * Online Certificate Status Protocol (OCSP): Permite a las partes interesadas revisar el estado de un certificado. Tiene problemas de rendimiento y privacidad. El OCSP stapling permite al servidor adjuintar una respuesta OCSP al handshake TLS. | ||
| + | * Let's Encrypt | ||
| + | * Los puntos de distribución CRL ahora son certificados hoja. | ||
| + | * URLs OCSP eliminadas de nuevos certificados | ||
| + | * CRLs particionados: | ||
| + | * Los buscadores usan CRLs agregados, no suelen buscar directamente. | ||
| + | |||
| + | {{drawio> | ||
| + | * Seguridad de la clave Root de la CA: Es crítico, si se revoca, todos los certificados que dependen de esta deben ser emitidos de nuevo. Los buscadores requieren que las CA sean operadas manualmente. | ||
| + | * Cross Certification: | ||
| + | * Compartimentación: | ||
| + | * Delegación: | ||
| + | |||
| + | === Partes de Confianza === | ||
| + | Se debe confiar en una serie de certificados CA raiz por sistemas operativos o desarrollador, | ||
| + | * Apple: mismas raices para IOS y MacOS. La CA debe pasar una auditoría anual. | ||
| + | * Microsoft: Igual que apple pero para productos de microslop | ||
| + | * Mozilla: Opera un programa de certificados raiz transparente. | ||
| + | * Chrome: Usado en la tienda de Chrome OSm tiene restricciones adicionales: | ||
| + | * Blacklist de raices no confiables | ||
| + | * Whitelist de CAs que pueden emitir certificados EV | ||
| + | * Se requiere transparencia de certificados para todos los certificados públicos. | ||
| + | |||
| + | ==== Problemas con la infraestructura PKI actual ==== | ||
| + | * Emisión de certificados del dueño del controlador de dominio: | ||
| + | * Cualquier CA puede emitir un certificado para una CA sin permiso del dueño ya sea por negligencia o malicia | ||
| + | * Hay cientos de CA, uno solo comprometido puede afectar a la seguridad. | ||
| + | * Dificultades actualizando Trust Stores: | ||
| + | * Muchas CA son demasiado grandes como para fallar: | ||
| + | * Eliminar una CA tiene consdecuencias demasiado grandes para el ecosistema | ||
| + | * Normalmente una CA no puede ser eliminada | ||
| + | * Las CA raíz son de confianza o no | ||
| + | * Procedimientos alternativos: | ||
| + | * Prohibir certificados de CA a de una fecha específica | ||
| + | * Eliminar privilegios EV. | ||
| + | * Revocación rota | ||
| + | * Retrasos en la propagación: | ||
| + | * Soft fail policy: Los navegadores ignoran fallos en comunicaciones CRL o OCSP. Un atacante puede suprimir dichas comunicaciones para usar certificados revocados | ||
| + | * Browser Vendors: Por defecto no realizan revocaciones. | ||
| + | * Una medida temporal es usar una blacklist propietaria en los navegadores. | ||
| + | * Otras debilidades: | ||
| + | * Weak Domain Validation: En email inseguro o usando datos WHOIS inseguros. | ||
| + | * Certificate Warnings: Muchas apps y librerías se saltan la verificación de los certificados. Los buscadores permiten a los usuarios aceptar certificados no verificados. | ||
| + | |||
| + | ==== Mejoras de infraestructura ==== | ||
| + | * Notarías: Repositorios públicos de certificados conocidos. Puede prevenir ataques basados en CA intermediarias comprometidas. Logs de transparecnia de certificados (CT Logs) | ||
| + | * DNS Information: | ||
| + | * HPKP (HTTP Public Key Pinning): Permite a los usuarios de un sitio restringir que CA pueden emitir certificados de sus sitios | ||
| + | * Cabecera HTTP especial: Respetado por firefox, | ||
| + | * Mecanismos propietarios: | ||
| + | * HPKP tiene un alto riesgo de inutilizar una web si no se maneja correctamente | ||
| + | * HPKP esta obsoleto en la actualidad. | ||
| + | * Expected-CT header es una práctica recomendada, | ||
| + | * Transparencia de certificados (CT): Identifiación rápida de certificados frauduletos. Es un framework para las partes interesadas para verificar la emisión de los certificados. | ||
| + | * Bajo CT, todas las CA participantes deben enviar tiodos los certificados emitidos en un log público de forma que todo el mundo puede monitorizar la emisión de certificados. | ||
| + | * La CA obtiene una prueba digital firmada de envío al log público. | ||