Nuestros amigos de The Register detectaron un cambio de código interesante en el navegador Chromium la semana pasada.
Parece que Google se está uniendo a Apple para limitar la validez máxima de los certificados de seguridad web, esos bloques de datos firmados digitalmente que ponen el S en TLS y el candado en tu barra de direcciones, a solo un año.
El cambio de código se titula “Enforce 398-day validity for certificates issued on-or-after 2020-09-01”, y se ve así:
Los certificados de servidor TLS de confianza pública tienen una vida útil de 398 días o menos, si se emiten a partir del 2020-09-01.
Los certificados que violen esto serán rechazados con ERR_CERT_VALIDITY_TOO_LONG y serán tratados como “mal utilizado”.
Apple anunció en febrero de 2020 que iba a comenzar a hacer esto en su navegador Safari.
Safari viene como parte de la distribución de macOS para Mac, por lo que siempre está disponible y se usa ampliamente.
Incluso si no es la primera opción para la mayoría de los usuarios de Mac, comúnmente se activa como un navegador “alternativo”, por ejemplo, cuando quieres iniciar sesión en el mismo sitio con dos cuentas diferentes, o iniciar sesión en un navegador pero no iniciar sesión en otro.
Y Safari, o al menos su núcleo de programación conocido como WebKit, es el único código de navegador permitido en iOS.
Los peligros de los certificados robados
Como probablemente sepas, los certificados web tienen dos partes: una clave pública, presentada al mundo para identificar tu servidor; y una clave privada, utilizada por tu servidor para demostrar que realmente posee la clave pública que presenta como identidad.
Puedes pensar en la clave pública como el recibo azul (o el disco blanco, o la hoja rosa, o el color que sea en tu país) que acompaña a tu coche para mostrar que está registrado con el nombre de su propietario, y puedes pensar en la clave privada como la identificación formal que enseñas cuando necesitas demostrar que realmente eres la persona que figura en el recibo.
El recibo no está destinado a ser un secreto: en algunos países es una pegatina que en realidad se coloca en el vehículo, y los datos que contiene pueden copiarse fácilmente, porque en realidad no significa nada sin la identificación que lo avale.
En el contexto de los certificados web, los delincuentes que obtienen tu clave privada son como ladrones de coches con una copia de tu identificación: pueden hacerse pasar por ti y, por lo tanto, convencer a las personas de que tu propiedad les pertenece.
Y si los delincuentes pueden configurar un servidor que pueda “probar” que es tuyo, esos mismos ciberdelincuentes pueden engañar a otras personas para que confíen en contenido falso en su sitio fraudulento como si fuera tuyo, avalado criptográficamente por ti.
Por supuesto, los ciberatacantes pueden disfrutar de la confianza conferida por tu certificado sin robar tu clave privada, por ejemplo, pirateando tu sitio y modificando o agregando contenido falso o malicioso en tu servidor.
Si el contenido proviene de tu web, automáticamente tendrá la impresión de tu certificado y, por lo tanto, tú y tu marca lo avalarán.
Pero los delincuentes que obtienen tu clave privada pueden ir mucho más allá, y pueden hacerlo sin tener que depender en absoluto de tu servidor: pueden crear efectivamente un clon de tu servidor, prácticamente en cualquier parte del mundo, donde no puedes apagarlo fácilmente o eliminar el contenido.
Si usan tu nombre, marca, logotipos y todo, incluido tu certificado web, entonces cualquiera que visite su servidor falso seguramente estará dispuesto a confiar como si fuera tuyo.
¿Por qué solo un año?
El argumento de Apple es que cuanto mayor sea la vida útil de un certificado, más tiempo tendrán los atacantes para abusar si es robado o si se ha firmado de manera fraudulenta, entonces, ¿por qué no limitar el límite superior en un solo año?
Todos en la industria generalmente están de acuerdo en que es necesario algún tipo de límite, como revela el código fuente de Chromium a continuación. (Hemos editado los comentarios, que son líneas que comienzan // para mayor claridad no técnica).
No te preocupes si no dominas C ++ porque las ideas básicas aquí son fáciles de seguir.
El siguiente código proviene de una función llamada HasTooLongValidity (), que devuelve verdadero si no se puede confiar en un certificado, y falso si está bien.
(Creemos que la función debería llamarse al revés, de modo que verdadero significaría HasAcceptableValidity () y falso si no es bueno, pero eso es una discusión para otro momento).
BR es la abreviatura de Requisitos Básicos, los principios acordados que establecen estándares mínimos para los certificados:
Como puedes ver arriba, el límite de vida útil del certificado se ha reducido muchas veces a lo largo de los años, de 10 años a 5, luego a 3¼ y luego nuevamente a 2¼.
Ahora, Google y Apple están trabajando en 398 días, que es un año completo más un mes completo más al menos dos días adicionales.
¿Nos debería importar?
No todos están encantados con este cambio, dado que fue implementado esencialmente por Apple unilateralmente a principios de este año, aparentemente sin consenso de la industria, y ahora está siendo copiado por Google en su navegador Chromium.
En otras palabras, a algunas personas les parece una especie de “política de secretismo”, promovida por Apple y ahora seguida por Google, la opinión los demás no importa porque todos tendrán que hacer lo mismo.
Algunos observadores preguntan por qué es necesario tener límites de vencimiento tan estrictos para los certificados, dado que no es necesario para los certificados que se han cuidado adecuadamente y, por lo tanto, están forzando en gran medida el cambio por el cambio.
De la misma manera que pocas compañías aún fuerzan los cambios regulares de contraseñas “solo porque”, pero guardan los restablecimientos de contraseña para cuando realmente se necesitan, ¿por qué forzar actualizaciones de certificados incluso para personas a las que no les han robado sus claves privadas?
Otros preguntan por qué un año se considera “demasiado largo” dado que las autoridades de certificación como Let’s Enrcypt ya están emitiendo certificados que solo son válidos por tres meses, gracias a un proceso de renovación sin problemas.
Si millones, o incluso cientos de millones, de webs que utilizan los certificados gratuitos de Let’s Encrypt pueden gestionar las renovaciones trimestrales con facilidad, ¿cómo puede considerarse un año demasiado corto para los certificados de las autoridades certificadoras más tradicionales?
¿Qué hacer?
Estos nuevos límites en los navegadores de Apple y Google no se aplican a los certificados que tú mismo autorizaste, por lo que puedes establecer cualquier tipo de límite de vencimiento que desees en tu propio ecosistema.
Pero para el resto: cualquier certificado web emitido después de septiembre de 2020 que se espera que dure dos años será rechazado por los navegadores de Apple y Google con el error CERT_VALIDITY_TOO_LONG.
Puedes luchar, o puedes seguir la corriente y adaptar tu flujo de trabajo de renovación de certificados para adquirir y usar certificados de un año.
