Durante l'handshake, il client e il server si scambiano "valori casuali", ovvero sequenze di 32 byte casuali. Il "client random" fa parte del messaggio ClientHello , mentre il "server random" fa parte del messaggio ServerHello .
In entrambi i casi, i primi quattro byte del valore casuale codificano la data e l'ora correnti (numero di secondi dal 1 ° gennaio 1970, 00:00 UTC). Il motivo per cui lo fanno è un po 'oscuro e si è perso nella nebbia del Tempo. La migliore spiegazione che possiamo dare è la seguente: se il client o il server non ha una buona fonte di casualità, allora almeno l'inclusione del tempo farà sicuro che non riutilizzino esattamente lo stesso valore "casuale". Naturalmente, la mancanza di una buona fonte casuale può indurre altri punti deboli (ad esempio se si utilizza lo scambio di chiavi basato su RSA, il client genera la chiave pre-master casuale, quindi il client DEVE avere un PRNG strong a portata di mano).
Per convalidare il certificato del server, il client dovrebbe avere una conoscenza approssimativa dell'ora corrente, poiché i certificati e il CRL hanno date di scadenza. Ciò non richiede che il server conosca l'ora corrente; non richiede alcuna sincronizzazione precisa tra client e server.
È stato sostenuto che SSL può essere (ab) usato come un modo per ottenere l'ora corrente: basta connettersi a un server SSL; fai l'intera stretta di mano in modo che tu sappia che stai parlando con il server giusto; usa la nozione di tempo del server (dai primi quattro byte di server_random come ora corrente). Questo non è affidabile. Dalle mie misurazioni, circa il 15% dei server SSL implementati sono o completamente disattivati (per anni ), o semplicemente non seguono lo standard e usano byte casuali per i primi quattro byte di server_random . In ogni caso, un client non deve utilizzare il tempo del server per la convalida del certificato del server: il client deve convalidare il certificato per assicurarsi che parli con il server giusto, e il client deve essere sicuro che parli con il server giusto essere in grado di credere che il server_random ricevuto provenga realmente dal server previsto e quindi contenga il momento giusto. C'è un problema intrinseco di pollo e uova qui.
Dal punto di vista del protocollo SSL / TLS non elaborato (come specificato in RFC 5246 ), la convalida del certificato è esaurita scope: il server invia alcuni certificati al client e, in qualche modo , il client acquisisce conoscenza (con un alto grado di certezza) della chiave pubblica del server. In pratica, i clienti lo fanno eseguendo la convalida dei certificati, che richiede (almeno) una nozione di data corrente. Questa necessità di un orologio locale è un problema noto per i sistemi embedded (almeno, per i client SSL incorporati che non possono contenere una copia codificata della chiave pubblica prevista del server).