L'utilizzo della data dal server stesso è controproducente: un server falso potrebbe inviare una data falsa.
In realtà c'è SSL stesso campo per la data: i primi quattro byte di client_random e% i campi diserver_random contengono la data e ora correnti , come noto rispettivamente dal client e dal server, . Ciò implica quanto segue:
- Un attaccante passivo, intercettazione sulla linea, può rilevare i clienti il cui orologio non funziona.
- Un utente malintenzionato attivo che esegue un server falso può conoscere la data e l'ora del cliente con una precisione di 1 secondo.
Lo scenario di attacco qui è un utente malintenzionato che ha rubato la chiave privata di un server. Il certificato è stato revocato; tuttavia, l'autore dell'attacco ha anche ottenuto certificati CA e CRL che hanno "dimostrato" che il certificato è valido in varie date precedenti. L'autore dell'attacco, in grado di fare MitM , esegue quindi un server falso ed emula Internet in quel modo tempo, in particolare rimandando al cliente il CRL passato recante la data in cui il cliente crede di essere aggiornato.
Un client non aggiornato potrebbe fallire le connessioni nel caso in cui la data corrente sia troppo lontana nel passato o troppo lontana nel futuro. Il recupero normale per quel caso è quello di presentare un reclamo all'utente, in modo che egli imposti correttamente la data e l'ora. Su una base teorica pura, non può essere un qualsiasi altro metodo che funzioni sempre contro gli aggressori MitM: un tale attaccante può, come ho detto, "emulare" una vecchia versione di Internet (nel suo insieme), impedendo così al dispositivo di ottenere la vera data corrente o anche di notare che il suo orologio non è impostato correttamente.
Potresti provare ad ottenere un timestamp da qualche Autorità di timestamp ; tuttavia, ciò implica la convalida del certificato TSA o, più precisamente, l'assunzione di che che la chiave privata TSA non sia mai stata rubata. Quindi, nella pratica , è possibile fare un'ipotesi ragionevolmente strong della data e dell'ora attuali in un modo in cui gli aggressori troveranno difficile inganno. Ma questo è costoso (connessioni extra a TSA) e dipende da questi TSA esterni, che potrebbero non essere liberi e / o potrebbero non essere d'accordo con ottenere così tante richieste di timestamp dai dispositivi distribuiti.
Modifica: se esegui verifiche di revoca con OCSP, e il cliente insiste per includere un nonce nella richiesta, quindi ottieni (in qualche modo) la stessa proprietà di la TSA - con gli stessi avvertimenti: devi ancora supporre che la chiave di qualche entità non sia stata rubata (TSA, risponditore OCSP, CA ...), e devi ancora fare connessioni extra.