¿Cuál es el propósito de rotar frecuentemente los certificados TLS sin cambiar las claves subyacentes?

Una gran ventaja es eliminar la necesidad de revocación en caso de un compromiso.

La forma "típica" de hacerlo es mediante la publicación de una lista de revocación de certificados (CRL) o usando protocolo OSCP en el caso de un compromiso para revocar certificados. Sin embargo, la comprobación de CRL u OSCP es increíblemente fácil de omitir. Un atacante en condiciones de realizar un ataque MITM puede simplemente bloquear a un cliente para que no se comunique con el servidor donde se aloja la CRL y el cliente simplemente se ocupará de su negocio. Esto es necesario debido a situaciones comunes como los portales cautivos que funcionan a través de HTTPS pero bloquean el resto del tráfico, incluido el tráfico a los servidores CRL.

Los certificados de corta duración tienen la ventaja de que en el caso de un compromiso, el certificado comprometido solo funcionará por un período muy limitado de tiempo hasta que el certificado caduque, lo que limita el daño que se puede causar.

Adam Langley ha escrito extensivamente sobre el tema si se requieren más lecturas.

Terry Chia respondió a la pregunta "¿Cuál es el beneficio de rotar certificados con tanta frecuencia?" totalmente correcto, así que no hay nada que agregar.

Sin embargo, me gustaría agregar una nota de que Google también cambia con frecuencia sus claves públicas, por lo que la suposición de la hoja de trucos no es válida. Esto agrega bastante confusión y puede ser parte de la razón de la pregunta original.

Solo desde mis archivos x509 personales:

$ openssl x509 -in google-oct.pem -noout -subject -dates -modulus
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
notBefore=Sep 24 10:48:54 2014 GMT
notAfter=Dec 23 00:00:00 2014 GMT
Modulus=AF384ED52C86FBDCD4F3117AD63652874889E442C80B4B112B3AEFA978607B33758927E75F92838D1A42B19F1DB59BC55322068FB197D38BBCB68984CAB4F0328E10A1B0D98DA794AAA379AB7C3CAFF177663127EC5069872F801E925AEDB76C865209A00A55618A2D1BB91F368D5739A1DE88C9FE66F5E0108C1FF1025D62DEE3BFBFB9BCFD3E71EC9C6E91A05AECD9833AE32B89B432DCD4C489D69C2BEC7E325C621184A8E8658CD3B755E62E65E19A2649ADC668E5C2705280884FC5D3B9D5914AC27D22B050F819233A0DDFF4194F55BDE358AABA6376567087BA69407B17EA364DB3A842A1972199B9B5632088F0E1C45B50DD1AD123F49573094051F3


$ openssl x509 -in google-nov.pem -noout -subject -dates -modulus
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
notBefore=Oct 22 12:57:51 2014 GMT
notAfter=Jan 20 00:00:00 2015 GMT
Modulus=C15236913979042DF078DF5B73AF463A636F98CE32A2AABAC378180566A87C382BB3A82A6808D4103D626A37CA4FBF8ABEA5939DD6C9874A8D318593F5481F59756E76817CBD38B73A5C703438BB9A824FD054B168ED3C9E5CD0445F744ED2A4EAA6327A94813A98C941BD60F3B19C5DC8CDFB34DE9293C53D41A234B4499A4F19C6AF193084F61C6636D7E89AEA86110231E6EE03F4C853841B0FB46122E6D73E7EF08D058665C7297B1A329F16F0EEB856E7614EB16B23CB4B6BBC5B567685F02638B52ECEBC71B06A1503776C0945A75E3227F71FE2956FC48533A6529066C840433A6705E94523843D10C45A8BC9CD58FCA6A6AABD79F2FFFEE6CB254AB9

[...]
$ openssl x509 -in google-apr.pem -noout -subject -dates -modulus
Modulus=924D62DDCD6B012D33F6CF12A5FD6291B490867ABB1E4F7F356FA8BBD424400C283EE7BB14DA8D1268239814A490F7D88EBA5EA3A9ED8DFEE6B6FF841405A964D47B1F76DB6F39A6990FD024060248FA889580271D6DDA6A7ADEB1538425268FAA8C2D824865DA3F30F78D48887D4C90D86F0A8A95F0A9CC951B7562FC98EC91D132C1C9418182045652BF510D357F1792201126DF230CD76BCA58B367A30088E6606FE7B80265582BD9A235F36AC60A2A6C266775979B52501355C51C7927ABA5DD0FFAFA39DFA240B3F21826188A9818B5E9761D38E15ACA980EF12BA14BEE00CA3D8C7F66112B56CEDCE2CA8BE67DD8ACA8B594D906CAE752217F67419E59

Las claves reales son completamente diferentes, y eso está perfectamente bien desde una perspectiva de seguridad.

Suponiendo que dado suficiente tiempo y recursos, uno puede, por ejemplo. intente calcular con fuerza bruta una clave privada para que coincida con una clave pública conocida. O algo como Heartbleed sucede una vez más, lo que resulta en un compromiso de claves privadas. Una forma sencilla de mitigar ambos tipos de amenazas es cambiar las claves periódicamente.

De mis observaciones, los certificados de Google son válidos por tres meses, pero se intercambian una vez al mes. Esto está bien desde un punto de vista operativo: no desea volver a cargar los nuevos certificados exactamente en el mismo segundo, pero probablemente comience a implementar los nuevos certificados en el 1% de los servidores afectados y aumente a la flota completa de servidores. Si algo sale mal, todavía puede volver al certificado anterior, que aún es válido, y tiene hasta dos meses más para corregir los nuevos certificados, la configuración del servidor, el software del servidor o lo que sea que tenga como resultado el problema asociado con el nuevo (roto) certificado.

En la respuesta de Ayrx , Steve Sether señala que:

1. Hay una correspondencia de uno a uno entre la clave pública y la clave privada, que forman un llamado par de claves . La clave privada cambia solo si la clave pública cambia. Por lo tanto, primero debemos entender, ya que la clave privada no cambia durante la actualización de un certificado, la clave pública tampoco. Sólo el certificado se actualiza, en particular su fecha de caducidad.
2. Consideremos el escenario en el que nuestra clave privada está comprometida, por ejemplo, un adversario robó nuestra clave privada. Cambiar a un nuevo certificado no ayudará, porque el certificado es público, el adversario puede seguir obteniendo los nuevos certificados y hacerse pasar por nosotros.

Estoy de acuerdo con los puntos de Steve. Entonces, ¿de qué sirve cambiar a un nuevo certificado?

El punto crucial aquí no es cambiar a un nuevo certificado, sino a la validez limitada o al vencimiento del antiguo certificado. Si el compromiso de la clave privada no se detecta (n. ° 2 arriba), entonces este vencimiento no servirá de nada. Sin embargo, si conocemos el compromiso (como suele ser el caso), podemos intentar revocar el certificado (mencionado por Ayrx). independientemente de e independientemente de la revocación, sabemos que tenemos que usar una nueva clave privada. La expiración de nuestro antiguo certificado significa que nuestra clave privada también "caducará" al mismo tiempo, ya que son un par de claves.

Puede haber otros ataques que puedan ayudar a actualizar el certificado, pero creo que el caso de uso anterior es uno prominente.