Quale ruolo gioca la sincronizzazione dell'orologio nella comunicazione SSL

In SSL, gli orologi vengono utilizzati per la convalida del certificato . Il cliente deve assicurarsi che parli con il server giusto; per questo, il client convaliderà il certificato del server. La convalida implica la verifica di molte cose; due di questi riguardano gli orologi:

• Il certificato del server (e tutti i certificati CA coinvolti) devono includere l'ora presente nell'intervallo di tempo di validità. Ogni certificato come notBefore e a notAfter campi; l'ora corrente deve essere compresa tra queste due date.

• Si suppone che il client ottenga lo stato di revoca di ciascun certificato, ottenendo (e convalidando) un CRL (Certificate Revocation List) dagli emittenti appropriati (la CA). Un CRL è ritenuto accettabile se (in particolare) è "non troppo vecchio": ancora, il CRL ha un campo thisUpdate che dice quando è stato prodotto e un campo nextUpdate che più o meno serve come scadenza data per il CRL.

Se l'orologio del client è disattivato, interromperà una o entrambe queste funzionalità. Ad esempio, il certificato del server sarà considerato come "scaduto" o "non ancora utilizzabile", che porta al rifiuto.

Accettare che l'orologio del client sia spento significa che il client è stato modificato per ignorare le date in certificati e CRL. L'ultima conseguenza per la sicurezza è che se un utente malintenzionato riesce a rubare la chiave privata di un server, allora quell'attaccante sarà in grado di impersonare quel server per sempre. Il punto di revoca è di avere un metodo verificato per recuperare da tale compromesso; e il punto di scadenza del certificato è di mantenere il CRL in crescita indefinitamente. Se i clienti ignorano la revoca e / o la scadenza, la conseguenza è che una volta che si verifica un compromesso, allora sei condannato per sempre . Di solito è considerato una cosa negativa.

Su una nota più brillante, questo è un problema per i client, non per il server. Se gestisci il server, allora il lavoro del cliente , non il tuo, per validare correttamente il tuo certificato. Se il cliente insiste davvero nel fare le cose in modo insicuro e vulnerabile, allora non puoi impedirlo, almeno non tecnicamente (puoi fare cose contrattualmente : se l'incompetenza del cliente consente una violazione, il cliente dovrebbe pagare per questo).

In una nota simile, se i client possono parlare con il tuo server, allora sono connessi a una sorta di rete, il che significa che Internet la sincronizzazione dell'ora basata su è una possibilità. Richiedere un orologio preciso è una sfida per alcuni dispositivi embedded, ma non dovrebbe essere per i computer in rete (inclusi gli smartphone).

Versione semplice (per gestori): le sincronizzazioni temporali possono impedire attacchi di riproduzione. Senza di loro, qualcuno potrebbe registrare i pacchetti inviati tra client e server, decodificare, modificare i dati, quindi inviare di nuovo il flusso del pacchetto e nessuno sarebbe più saggio. Ma, poiché la decrittazione richiede tempo, un timestamp (convalidato su entrambi i lati) può indicare che lo stream è un "replay".

Forse potresti considerare un periodo di timeout più lungo per la tua azienda / applicazione? Invece di una finestra stretta, potresti realizzare dei benefici allargando la finestra. Questo dovrebbe essere analizzato per il suo pieno impatto sui sistemi, naturalmente.