cert SSL minimiza la estrategia de rotación de claves de tiempo de inactividad

2

Como ya sabe, debido al error del corazón, debemos volver a introducir nuestros servidores web (> 10). Antes de hacerlo, quiero comprobar si mi estrategia propuesta es la correcta o no.

a. Genere un nuevo CSR, envíelo a Godaddy para volver a emitir el certificado

b. Instale el certificado y la clave en el servidor web, y reinicie lo más rápido posible

Mis preguntas:

  1. ¿Hay algún paso que haya omitido?
  2. En el paso (a), cuando se vuelve a emitir el nuevo certificado, asumo que se revoca el anterior, pero antes de que se despliegue el nuevo certificado, ¿existe algún riesgo durante ese tiempo, el cliente verifica el certificado revocado y tiene experiencia? error?
  3. ¿El cliente (de escritorio / móvil) almacenará en caché el certificado revocado? ¿Y no podré comunicarme con mi nueva clave privada incluso después de haber instalado el nuevo certificado?
pregunta Howard 14.04.2014 - 15:50
fuente

2 respuestas

1

Usted asume incorrectamente: un certificado no tiene que ser revocado cuando se vuelve a emitir. Es típicamente un proceso completamente diferente. Esto significa que debe agregar un último paso a su plan: revocar el certificado anterior una vez que haya terminado de instalar el nuevo.

Los clientes no almacenarán en caché su certificado. De hecho, no pueden guardar una copia en caché ya que es su servidor el que envía su certificado como parte del protocolo de enlace SSL. Pueden mantener una copia de la CRL en la memoria caché mientras sea válida, pero eso debería tener un impacto muy limitado en la seguridad y ninguna en la disponibilidad.

Finalmente, no tiene que reiniciar los servidores, simplemente puede reiniciar el proceso / servicios usando sus certificados. Seguirá causando que se eliminen las conexiones existentes, pero debería ser mucho más rápido que reiniciar todo el servidor.

    
respondido por el Stephane 14.04.2014 - 16:26
fuente
1

Supongamos, por un instante, que realmente necesita "cambiar la clave de sus servidores web" debido al error del corazón (si existe tal necesidad, entonces lógicamente también debe hacerlo para cualquier otra vulnerabilidad similar que aparece, por lo tanto, varias veces al año, y también debe hacerlo para las vulnerabilidades que se mostrarán , por lo que, según ese razonamiento, su nueva clave también se brindará de inmediato. Supongamos también que volver a teclear es suficiente (nuevamente, hay una falacia: si un atacante podría obtener su clave privada, entonces también podría obtener todos sus datos confidenciales, por lo que el problema tiene un alcance mucho mayor).

Bajo estas suposiciones, el modelo es el de un compromiso de sus claves privadas (eso es lo que teme). Debes hacer dos cosas:

  1. Declare el certificado antiguo como no válido, para que los clientes dejen de confiar en él. Esto se conoce como revocación.

  2. Obtenga un nuevo certificado con una nueva clave que el atacante no conoce.

No hay necesidad conceptual de hacer las cosas en ese orden. De hecho, por lo general, desea que el nuevo certificado esté activo y en ejecución antes , se revoque el anterior. Sucede que algunos CA insisten en vincular las dos operaciones, es decir, revocar el certificado anterior y volver a emitir el nuevo al mismo tiempo (una razón para hacerlo es comercial: usted pagó por uno certificado, por lo que debería obtener uno certificado no revocado en cualquier momento).

Afortunadamente, algunas características te ayudarán:

  • Los clientes no almacenan certificados. En el protocolo SSL / TLS , el servidor envía sistemáticamente su certificado actual, y el cliente siempre utilizará ese, no un versión en caché.

  • La revocación es asíncrona: cuando se revoca un certificado, su número de serie se incluirá en la Lista de revocación de certificados que publica regularmente la CA. Por lo general, tomará algunas horas antes de que la revocación sea efectiva (depende de la política de CA). Además, los clientes hacen almacenan en caché la CRL, por lo que incluso si la CA publica inmediatamente una nueva CRL, los clientes que se conectaron hace unas horas seguirán funcionando con la anterior, hasta que caduque. (Sin embargo, OCSP puede reducir la ventana de tiempo).

  • Muchos clientes no se molestan en comprobar la CRL de todos modos, por lo que, desde su punto de vista, el certificado anterior nunca será revocado.

Todavía le conviene completar el procedimiento rápidamente, es decir, en unos pocos minutos. De todos modos, DEBES poder realizar ese proceso correctamente, ya que los certificados caducan: simplemente lo estás haciendo temprano (por un sentimiento de deferencia hacia la actual ola de paranoia mal informada).

    
respondido por el Thomas Pornin 14.04.2014 - 17:22
fuente

Lea otras preguntas en las etiquetas