Fijación de SSL: gestión de cambios en la certificación fijada en el lado del cliente

Navega tus respuestas
0
  • Supongamos que tenemos una aplicación del cliente que se comunica con un servidor a través de SSL.
  • Supongamos también que el cliente está utilizando la fijación de certificados SSL, es decir, el cliente rechazará el certificado del servidor a menos que se ajuste a un código duro específico con el que se lanzó el cliente.

Como los certificados tienen fechas de vencimiento, el certificado anclado del servidor eventualmente tendrá que ser reemplazado. Este proceso generalmente requiere alguna actualización del lado de la aplicación / cliente para que el cliente esté al tanto del nuevo certificado 'para fijar'.

¿Existen prácticas recomendadas sobre cómo se puede gestionar esta transición / cambio?

Estoy pensando en algo más sofisticado que dos personas presionando un botón al mismo tiempo (es decir, el certificado del servidor se está actualizando y la aplicación obliga al usuario a actualizar) ... Los procesos organizativos El involucrado aquí puede ser no trivial, especialmente porque los ciclos de lanzamiento y mantenimiento del cliente / servidor / operaciones pueden ejecutarse de acuerdo con diferentes programas y prioridades.

Tal vez algo como (estoy escribiendo un enfoque bastante ingenuo aquí):

  • El cliente tiene múltiples certificados almacenados para el servidor, con períodos de validez diferentes pero que se superponen.
  • Si un certificado anclado ha caducado, el cliente verifica si tiene otro diferente aún válido ...

- > Esto permitiría que los nuevos certificados "anclados" para un servidor se entreguen mucho antes de que realmente se cambien los certificados en el servidor.

    
pregunta fgysin 30.01.2017 - 14:24
fuente

1 respuesta

3

Puede fijar más de un certificado, y debería fijar al menos 2. Si de alguna manera pierde el acceso a un certificado, puede usar el segundo. Con solo un certificado, nadie que se conecte a su sitio con la opción de anclaje habilitada podrá conectarse a su sitio a través de HTTPS hasta que el certificado caduque (pero pueden conectarse a través de HTTP). Si emplea HSTS, nadie que se haya conectado podrá hacerlo incluso a través de HTTP.

Por lo tanto, siempre que tenga un certificado válido, puede modificar la configuración de su servidor web para enviar el certificado actual y el nuevo en la misma respuesta, y los navegadores también almacenarán en caché el nuevo.

Por ejemplo, su servidor usa la configuración actual: 

Public-Key-Pins: max-age=2592000;
pin-sha256="abcd9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";

Y el certificado con huella digital abcd9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g= expirará en 2 meses. Solo modifica la configuración del servidor para agregar el nuevo certificado LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= con los encabezados de respuesta: 

Public-Key-Pins: max-age=2592000;
pin-sha256="abcd9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";

Pero si deja que el certificado caduque, debe esperar hasta que caduque el max-age para poder enviar otro certificado.

    
respondido por el ThoriumBR 30.01.2017 - 14:57
fuente

Lea otras preguntas en las etiquetas

Nikto: los resultados difieren para IP y nombre de host Pentest de la red externa y pentest de la aplicación. ¿Lo mismo?