Resumen

  • APNIC informa que un certificado de Let's Encrypt ya revocado aparecía en una CRL; Chrome y Safari no reconocieron la revocación en aquella prueba y Firefox sí.
  • El resultado no ofrece una tasa mundial de fallo ni describe todas las versiones y configuraciones. Publicar el estado y aplicarlo en el cliente son actos diferentes.
  • Acortar la vigencia, consultar OCSP, adjuntar una respuesta o proponer DANE modifica las dependencias, pero no acredita por sí solo un corte inmediato.

Una lista firmada suele parecer la última palabra. En TLS es, más bien, una pieza de evidencia que debe viajar. La autoridad certificadora puede añadir el número de serie a su lista; el servidor puede seguir presentando su copia del certificado; los distribuidores pueden servir una versión anterior dentro de su ventana de validez. El navegador decide qué fuente consultar, si la respuesta es suficientemente actual y qué hacer si no puede obtenerla. Ninguno de esos pasos se deduce automáticamente de la palabra «revocado».

El informe de APNIC publicado el 21 de septiembre describe la demostración de Geoff Huston. Emitió y revocó un certificado de Let's Encrypt. El certificado figuraba en una lista de revocación. En las condiciones observadas, Chrome y Safari no rechazaron la conexión por esa revocación, mientras Firefox sí la reconoció. El informe no proporciona una matriz exhaustiva de versiones, plataformas, ajustes, fuentes alternativas de estado y marcas horarias de cada conexión. Es evidencia de esta prueba, no de que un producto «nunca» verifique nada.

La variable temporal es central. En su análisis de abril, Huston explica que una CRL tiene firma, fecha de emisión y próxima actualización. Un cliente puede conservar una copia que sigue siendo admisible aunque aún no recoja la revocación más reciente. Descargar miles de entradas durante cada negociación añade trabajo y demora. APNIC menciona una lista semanal con 17.527 certificados revocados y un ciclo de publicación de siete días para la demostración. No son 17.527 usuarios afectados ni una medición de siete días de daño.

OCSP formula una pregunta individual y evita descargar toda la lista. A cambio, la consulta puede revelar el sitio visitado al servicio de estado y depender de su disponibilidad. Una respuesta firmada también debe juzgarse por sus tiempos internos, no sólo por la firma. El servidor puede adjuntarla durante el saludo TLS mediante OCSP stapling; así se reducen consultas directas y latencia, pero el servidor que conserva un certificado revocado no tiene por qué suministrar una respuesta nueva que lo perjudique. La decisión de permitir o bloquear cuando falla la consulta queda en el cliente.

El propio historial impide una lectura cómoda. El análisis de abril registra otra observación de navegadores con OCSP en la que Safari tenía un resultado distinto al de septiembre. No es válido mezclar ambas pruebas como si compartieran protocolo, caché y configuración. La noticia de APNIC 62 es precisamente que una revocación publicada y la respuesta del software no son el mismo hecho.

Un certificado con vida más corta limita el tiempo que le queda a una credencial, siempre que el cliente respete el vencimiento y el operador renueve sin interrumpir el servicio. No equivale a invalidar una clave robada en el instante en que se descubre. Huston explora DNSSEC y DANE, con tiempos de expiración del DNS, en sus diapositivas de APNIC 62. Su propuesta no demuestra que esa arquitectura sustituya ya a la PKI web en los navegadores.

El operador que investigue un incidente necesita conservar el momento de la decisión de revocar, la publicación de la CA, la versión de CRL o respuesta OCSP recuperable, los puntos de servicio que aún ofrecían la credencial antigua y resultados de clientes concretos. APNIC no documentó en esta prueba una intrusión bancaria ni contó víctimas. Documentó algo previo: la distancia que puede existir entre una declaración autorizada y el acto del último software que decide.

Fuentes