La clave para una buena seguridad, dicen, es la vigilancia constante. En la práctica, esto significa que los profesionales de la seguridad y las redes deben ser conscientes de dos cosas: los cambios en el panorama de amenazas para que puedan estar alertas ante posibles ataques a sus sistemas y los cambios y desarrollos en las tecnologías que emplean.
A la luz de la segunda parte, centrada en los cambios en la tecnología subyacente, me gustaría llamar la atención sobre los posibles cambios que se están discutiendo actualmente. El cambio puede parecer menor en la superficie, pero las posibles consecuencias a largo plazo acechan justo debajo de la superficie.
Estas consecuencias son muy importantes. Si no se planifican, estos cambios pueden generar decenas de horas desperdiciadas buscando fallas de aplicaciones difíciles de depurar, posibles interrupciones del servicio u otros efectos que pueden no ser evidentes a simple vista. Me refiero aquí a los cambios propuestos en discusión relacionados con el ciclo de vida de los certificados X.509 utilizados para las sesiones TLS/SSL.
Entonces, ¿qué pasa con los certificados?El trasfondo es que Google hizo una propuesta en el CA/B Forum de junio Acorte la vida útil de los certificados X.509 Nuevamente para TLS, poco más de un año (397 días).
El CA/Browser Forum (CA/B Forum) es una coalición de partes interesadas de la industria de PKI: autoridades de certificación (las organizaciones que realmente emiten certificados) y partes de confianza (fabricantes de software que confían en los certificados emitidos, como los proveedores de navegadores). Su misión es establecer prácticas y estándares de seguridad en torno al ecosistema de PKI pública.
El estándar actual de dos años (825 días), establecido en marzo de 2018, tiene una vida útil máxima del certificado más corta que la vida útil anterior de tres años (39 meses). Esta vez, el foro está revisando una propuesta de un año. Como fue el caso la última vez, las autoridades certificadoras naturalmente encontrarán cierta resistencia en el negocio de emitir certificados relevantes.
¿A quién le importa cuánto dura la vida?
De hecho, existen buenos argumentos en ambos lados del período de validez del certificado, tanto a favor como en contra de reducir el período máximo de validez del certificado.
En primer lugar, está el tema de la revocación del certificado. Específicamente, aquellos que confían en la validez del certificado (para la mayoría de los casos de uso, esto significa navegadores como Chrome, Edge y Firefox) son responsables de garantizar que el estado de revocación del certificado se verifique correctamente. Este tipo de cosas suenan fáciles de hacer hasta que piensas en sus implicaciones.
Por ejemplo, no son solo los navegadores los que tienen que implementar comprobaciones de validez. Lo mismo ocurre con implementaciones como bibliotecas de software (p. ej., OpenSSL, wolfSSL), implementaciones de sistemas operativos (p. ej., CAPI/CNG), productos CASB u otros productos de supervisión que intentan interceptar HTTPS.
Como uno podría sospechar, dada la complejidad, no todas las implementaciones lo hacen bien o completamente (como en US-CERT’s Boletín Técnico tema sobre la interceptación de HTTPS). Una vida útil más corta significa que incluso si una implementación no verifica el estado de revocación, se reduce el límite superior de cuánto tiempo puede continuar usándose un certificado revocado.
Por otro lado, tenga en cuenta que la mayoría de las aplicaciones nuevas dependen en gran medida de los servicios web como método clave de operación. No solo los navegadores y los productos relacionados se basan en certificados, sino que las propias aplicaciones dependen cada vez más de los certificados.
Esto, a su vez, significa que cuando un certificado caduca, no solo afecta negativamente la experiencia de la interfaz de usuario de quienes buscan acceder a un sitio web, sino que también puede provocar que la aplicación falle en servicios web críticos, como los del lado del servidor RESTful. API (donde se implementa realmente la lógica empresarial). No pueden establecer un canal seguro y, por lo tanto, fallan. En este caso, el certificado vencido puede hacer que la aplicación falle inesperadamente de una manera difícil de depurar: «funcionó ayer, pero no funciona ahora».
Desde la perspectiva de un profesional del usuario final, no importa cómo lo divida, hay compensaciones. Una vida útil corta puede ayudar a mitigar los problemas causados por no implementar correctamente las comprobaciones de revocación, pero al mismo tiempo puede generar complejidad en la aplicación cuando no se realiza un seguimiento estricto del estado de vencimiento del certificado. Tenga en cuenta que esto se suma a los argumentos a favor y en contra presentados por las CA, los desarrolladores de navegadores y otras partes interesadas en el foro CA/B.
Qué pueden hacer los profesionales de la seguridad
Ya sea que tome una postura profesional o constante sobre este cambio en particular, hay algunas cosas que los practicantes pueden y deben hacer para garantizar que el orden permanezca en su casa. En primer lugar, si todos fueran mejores validando el estado de revocación en primer lugar, no habría necesidad de encontrar estrategias alternativas para limitar el riesgo de revocación de certificados.
Si está usando algo como CASB (u otra herramienta de monitoreo basada en interceptación), si está desarrollando una aplicación que emplea una API RESTful que admite TLS, usa un proxy inverso o maneja clientes de sesión TLS, entonces es imprescindible. -do es para garantizar que las verificaciones de estado de revocación se realicen y se realicen con precisión.
Es una buena idea de todos modos, pero el hecho de que los que saben están presionando por el cambio sugiere que el problema puede ser más grande de lo que piensas.
En segundo lugar, realice un seguimiento de los vencimientos de certificados en su entorno. Lo ideal es registrar quién lo emitió, cuándo caduca y un punto de contacto para cada contacto (si caduca, puede causarle problemas a alguien).
Si es posible, verifique periódicamente su entorno en busca de nuevos oyentes habilitados para TLS que no espera. Si tiene el presupuesto para invertir, hay algunos productos comerciales que pueden hacer esto. De lo contrario, puede obtener información sobre la caducidad del certificado a partir de los resultados del análisis de vulnerabilidades.
En el peor de los casos, no es demasiado difícil escribir secuencias de comandos utilizando la interfaz «s_client» de OpenSSL o herramientas como la opción «ssl-cert» para buscar sistemáticamente rangos de direcciones IP para servidores TLS (y registrar detalles del certificado, incluido el vencimiento). nmap. Nuevamente, esto es útil de todos modos, pero proporcionará más valor si la esperanza de vida se vuelve más corta en el futuro.
Ahora, si se toma un tiempo y realiza una planificación, puede asegurarse de que su entorno se mantenga en la mejor posición posible, sin importar el camino que finalmente decida tomar el poder. Dado que estas medidas son prudentes de todos modos, aún puede obtener valor al implementarlas incluso si el resultado no acorta el período de validez.
