C'è un client che supporta crittografie SSL molto vecchie, incluso
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014) TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011) TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008) TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006) TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
Probabilmente ha una vecchia libreria SSL con noti bug di sicurezza. Ma il server è aggiornato e configurato correttamente. È possibile sfruttarlo? Se sì - come?
Data la gravità di questi codici, posso immaginare che il client supporti anche SSLv2, che è rotto. Inoltre, probabilmente accetterà i certificati firmati con MD5 o MD4 o MD2, anch'essi danneggiati, quindi si dovrebbe essere in grado di creare un certificato falso accettato dal cliente. Cioè se il cliente controlla i certificati perché anche alcuni anni fa era ancora molto comune che i programmi non controllassero il certificato SSL. Quindi penso che un uomo attivo nell'attacco centrale dovrebbe essere possibile.
Non penso che le vecchie ciphersuites siano troppo preoccupanti in quanto il tuo server non dovrebbe mai negoziarle. La cosa più preoccupante è che indicano che lo stack SSL / TLS nel client in generale è molto vecchio.
In generale con ssl / tls il client autentica il server ma il server non autentica il client a un livello tls, (i protocolli di livello più alto spesso autenticano il client usando i propri meccanismi ma quell'autenticazione non fornisce la protezione MITM) .
Quindi il tipo di problemi di cui ti devi preoccupare sono i problemi che consentono all'autore dell'attacco di convincere il cliente che è il server e quindi di consentire a MITM di attaccare la connessione.
Un metodo per farlo è attaccare l'algoritmo hash del certificato. Ci sono due varianti di questo.
Se l'attaccante ha un attacco preimage fattibile contro il certificato, allora può usare tranquillamente per farsi un certificato di fiducia per qualsiasi nome host che gli piace. Tuttavia l'afaict anche per le funzioni hash molto vecchie come gli attacchi di pre-imaging MD2 sono ancora computazionalmente accessibili.
L'altro metodo consiste nello sfruttare un attacco di collisione per creare una coppia di certificati, uno dei quali è un certificato di entità finale normale per un dominio che l'utente malintenzionato possiede legittimamente ed è firmato da una CA attendibile. L'altro certificato è un certificato CA intermedio. I due certificati sono costruiti per avere lo stesso hash che consente il trapianto della firma. Tuttavia, per eliminare questo problema, l'utente malintenzionato deve trovare una CA che usi ancora la funzione di hash vulnerabile e che funzioni in modo abbastanza rapido che l'attacco di collisione possa avere successo. Un gruppo di ricercatori dell'Università è riuscito a eliminare questo attacco con MD5, ma la CA che hanno utilizzato ha cambiato le loro pratiche subito dopo.
Un'altra opzione è quella di andare dopo le chiavi RSA stesse. Se è possibile trovare un certificato CA di cui il client si fida (direttamente come certificato radice o indirettamente come intermedio firmato da uno dei certificati radice dei client) con una chiave RSA sufficientemente breve, è possibile calcolare il modulo e ottenere la chiave privata . Quindi puoi usarlo per firmare i certificati per qualunque nome host ti piaccia. L'RSA a 512 bit è calcolato con facilità ma non sono sicuro che sia mai stato utilizzato sui certificati CA (è stato utilizzato sui certificati di entità finale ma tendono ad avere una scadenza più breve e sono utili solo per impersonare un sito) 1024 bit RSA è stato ampiamente utilizzato sui certificati radice ed è probabilmente incrinabile con le risorse a livello di NSA ma è quasi certamente ancora fuori dalla portata dei criminali comuni.
Leggi altre domande sui tag tls