Herramientas de usuario
master_cs:secom:tm1_v2
Diferencias
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/25 21:37] – thejuanvisu | master_cs:secom:tm1_v2 [2026/05/25 22:13] (actual) – [Problemas con la infraestructura PKI actual] thejuanvisu | ||
|---|---|---|---|
| Línea 259: | Línea 259: | ||
| * CRLs particionados: | * CRLs particionados: | ||
| * Los buscadores usan CRLs agregados, no suelen buscar directamente. | * 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. | ||
master_cs/secom/tm1_v2.1779745072.txt.gz · Última modificación: 2026/05/25 21:37 por thejuanvisu
Herramientas de la página
