¿Qué papel juega la sincronización del reloj en la comunicación SSL?

En SSL, los relojes se utilizan para validación de certificados . El cliente debe asegurarse de que habla con el servidor correcto; para eso, el cliente validará el certificado del servidor. La validación implica verificar muchas cosas; Dos de ellos involucran relojes:

• El certificado del servidor (y todos los certificados de CA involucrados) deben incluir la hora actual en su rango de tiempo de validez. Cada certificado como un notBefore y un notAfter campos; la hora actual debe estar entre estas dos fechas.

• El cliente debe obtener el estado de revocación de cada certificado al obtener (y validar) una CRL (Lista de revocación de certificados) de los emisores correspondientes (la CA). Una CRL se considera aceptable si (en particular) "no es demasiado antigua": nuevamente, la CRL tiene un campo thisUpdate que dice cuándo se produjo, y un campo nextUpdate que más o menos sirve como vencimiento fecha de la CRL.

Si el reloj del cliente está apagado, se interrumpirá una o ambas funcionalidades. Por ejemplo, el certificado del servidor se considerará como "caducado hace mucho tiempo" o "aún no se puede utilizar", lo que lleva al rechazo.

Aceptar que el reloj del cliente está apagado significa que el cliente se modifica para ignorar las fechas en los certificados y CRL. La última consecuencia para la seguridad es que si un atacante logra robar la clave privada de un servidor, ese atacante podrá suplantar ese servidor para siempre. El punto de revocación es tener un método verificado para recuperarse de tal compromiso; y el punto de expiración del certificado es evitar que el CRL crezca indefinidamente. Si los clientes ignoran la revocación y / o el vencimiento, entonces la consecuencia es que una vez que se produce un compromiso, estará condenado para siempre . Lo que generalmente se considera algo malo.

En una nota más brillante, esto es un problema para los clientes, no para el servidor. Si opera el servidor, entonces es el trabajo del cliente , no el suyo, validar su certificado correctamente. Si el cliente realmente insiste en hacer las cosas de forma insegura y en ser vulnerable, entonces realmente no puede evitarlo, al menos no técnicamente (puede hacer las cosas por contrato : si la incompetencia del cliente permite una violación, el cliente debería pagar por ello).

En una nota similar, si los clientes pueden hablar con su servidor, entonces están conectados a algún tipo de red, lo que significa que Internet La sincronización horaria basada en es una posibilidad. Requerir un reloj preciso es un desafío para algunos dispositivos integrados, pero no debería serlo para computadoras en red (incluidos los teléfonos inteligentes).

Versión simple (para administradores): las sincronizaciones de tiempo pueden evitar ataques de reproducción. Sin ellos, alguien podría registrar los paquetes enviados entre el cliente y el servidor, descifrar, modificar los datos y luego reenviar el flujo de paquetes y nadie sería más sabio. Pero, debido a que el descifrado lleva tiempo, una marca de tiempo (validada en ambos lados) puede indicar que la transmisión es una "reproducción".

¿Quizás podría considerar un período de tiempo de espera más prolongado para su empresa / aplicación? En lugar de una ventana estrecha, podría obtener algún beneficio al ampliar la ventana. Esto tendría que ser analizado para su impacto total en sus sistemas, por supuesto.