Durante el protocolo de enlace, el cliente y el servidor se envían mutuamente "valores aleatorios", que son secuencias de 32 bytes aleatorios. El "cliente aleatorio" forma parte del mensaje ClientHello , mientras que el "servidor aleatorio" forma parte del mensaje ServerHello .
En ambos casos, los primeros cuatro bytes del valor aleatorio codifican la fecha y la hora actuales (número de segundos desde el 1 de enero de 1970, 00:00 UTC). La razón por la que lo hacen es un poco confusa y se ha perdido en la niebla del Tiempo. La mejor explicación que podemos encontrar es la siguiente: si el cliente o el servidor no tiene una buena fuente de aleatoriedad, entonces al menos la inclusión del tiempo hará que Asegúrese de que no reutilicen exactamente el mismo valor "aleatorio". Por supuesto, la falta de una buena fuente aleatoria puede inducir otras debilidades (por ejemplo, si se usa un intercambio de claves basado en RSA, el cliente genera la clave pre-maestra aleatoria, por lo que el cliente DEBE tener un PRNG fuerte a mano).
Para validar el certificado del servidor, el cliente debe tener un conocimiento aproximado de la hora actual, ya que los certificados y CRL tienen fechas de caducidad. Esto no requiere que el servidor sepa la hora actual; tampoco necesita una sincronización precisa entre el cliente y el servidor.
Se ha argumentado que SSL se puede (ab) utilizar como una forma de obtener la hora actual: simplemente conectarse a un servidor SSL; haga el apretón de manos completo para que sepa que está hablando con el servidor correcto; use la noción de tiempo del servidor (de los primeros cuatro bytes de server_random como hora actual). Esto no es confiable. A partir de mis propias mediciones, aproximadamente el 15% de los servidores SSL implementados están totalmente desactivados (por años ), o simplemente no siguen el estándar y usan bytes aleatorios para los primeros cuatro bytes de server_random . En cualquier caso, un cliente no debe usar la hora del servidor para validar el certificado del servidor: el cliente debe validar el certificado para asegurarse de que habla con el servidor correcto, y el cliente debe asegurarse de que habla con el servidor correcto para poder confiar en que el server_random recibido realmente proviene del servidor esperado y, por lo tanto, contiene el momento adecuado. Aquí hay un problema intrínseco del huevo y la gallina.
Desde el punto de vista del protocolo SSL / TLS (como se especifica en RFC 5246 ), la validación del certificado está fuera de alcance: el servidor envía algunos certificados al cliente y, de alguna manera , el cliente obtiene conocimiento (con cierto grado de certeza) de la clave pública del servidor. En la práctica, los clientes hacen eso mediante la validación de certificados, que requiere (al menos) una noción de la fecha actual. Esta necesidad de un reloj local es un problema conocido para los sistemas integrados (al menos, para el cliente SSL incorporado que no puede contener una copia codificada de la clave pública esperada del servidor).