Non è possibile verificare la presenza di difetti di implementazione. Quello che puoi vedere da un cliente sono:
-
Utilizzo di protocolli intrinsecamente deboli . Controllando che il server supporti TLS 1.1 e 1.2, lo stai già escludendo.
-
Inappropriatlianza flagrante . Ad esempio, se la chiave pubblica del server (vista nel certificato del server) è troppo piccola per motivi di sicurezza (ad esempio una chiave RSA a 512 bit). O se noti che il "random" del server è sempre lo stesso.
In questo modo viene invertito l' onere della prova . Normalmente, una determinata implementazione dovrebbe in modo proattivo cercare di dimostrare che fa le cose correttamente, spiegando (per esempio), nella sua documentazione, che sono state seguite le corrette regole di sviluppo durante l'implementazione. Questo può essere semplice come affermare "usiamo LibfoobarSSL versione 42.17", ma deve essere una sorta di documentazione. Non è compito tuo "convalidare" l'implementazione contro i difetti; è noto che tale convalida cieca a posteriori non funziona. Potresti notare i fori più evidenti, ma non trovare nulla non significa che non c'è nulla da trovare.
Ad esempio, circa 1996, l'implementazione SSL in Netscape (l'allora leader del browser Web) si sperava debole a causa di un pessimo PRNG - i test statistici non hanno potuto mostrare il problema, perché il problema era seeding errato : la maggior parte dello stato interno del PRNG era prevedibile, quindi era una questione di pochi secondi per rompere qualsiasi tunnel SSL, ma i test statistici non avrebbero mostrato nulla di sbagliato. La rilevazione di tale difetto ha richiesto reverse engineering . Questo non può essere automatizzato con uno strumento.