Quando avviene l'handshake SSL, c'è un punto in cui il lavoro computazionale svolto dal client è significativamente inferiore al lavoro di calcolo eseguito dal server?
Potrebbe essere sfruttato tale squilibrio per produrre un DoS con maggiore efficacia? Ci sono documenti accademici o implementazioni proof-of-concept di questo?
Sì, un DoS basato su CPU su server SSL è facile. Considera i due tipi principali di suite di crittografia, come comunemente usato in SSL:
Scambio chiave RSA : il server invia il certificato con una chiave pubblica RSA; il client genera un blob casuale (la chiave segreta pre-master) crittografato con la chiave pubblica del server; il server la decrittografa.
Scambio chiave DHE : il server invia la metà dello scambio di chiavi Diffie-Hellman, firmato con la chiave privata del server. Il cliente invia la propria metà del DH. Il server completa lo scambio di chiavi DH applicando la sua chiave privata DH (un esponenziamento modulare).
In entrambi i casi, il server deve eseguire un'operazione di crittografia relativamente pesante: una decodifica RSA o un esponenziazione modulare DH (per DHE, il server può riutilizzare i suoi parametri DH temporanei, a condizione che non si riavvii, ma non possa eludere l'esponenziazione modulare finale calcolata su ciò che il cliente invia). D'altra parte, un client che tenta di eseguire il server non ha bisogno di fare alcun lavoro: ha solo bisogno di inviare un blob di circa la giusta dimensione. La decifrazione sul server fallirà, ma la spesa della CPU sarà comunque persa.
(Già con i client honest e lo scambio di chiavi RSA, il costo della CPU è più alto nel server, perché la crittografia RSA è molto più veloce della decodifica RS . Ma un malvagio cliente, intento a DoSing, può totalmente evitare di lavorare.)
Tali attacchi sono stati osservati in modo selvaggio e non occorrono un documento accademico per spiegare come funzionano.
Sì, ci sono questi punti. Soprattutto se la rinegoziazione SSL è attiva, questi possono essere sfruttati per abbattere un server in modo abbastanza efficace:
Questografico,trattoda
For example, with 2048bit RSA certificates and a cipher suite like AES256-SHA, the server needs 6 times more CPU power than the client. However, if we use DHE-RSA-AES256-SHA instead, the server needs 34% less CPU power. The most efficient cipher suite from the server point of view seems to be something like DHE-DSS-AES256-SHA where the server needs half the power of the client.
Per informazioni dettagliate su questo, checkout attenuazione DoS computazionale SSL e il note di rilascio originali del THC-Tool utilizzate per dimostrare questo dDoS: DOS SSL THC
spero di averti aiutato,
gewure
La risposta sarebbe no, dato che sei il primo a fare il maggior numero di lavori. Ma puoi ancora attaccarlo.
La chiave della tua domanda è distribuita. Anche se l'attaccante ha la stessa quantità (o quasi la stessa), ci sono numerosi clienti per iniziare una stretta di mano. Il che significa che non è necessario impegnarsi al massimo durante l'handshake, basta dividere il carico di lavoro su diversi client e nessun cliente può provare un cambiamento significativo nelle prestazioni, mentre il server potrebbe essere al limite.
Penso che il trucco sia avviare più sessioni SSL, ma non fare mai nulla di più che dire HELLO, il server risponderà e attenderà. Ciò significa che puoi farlo con le sue risorse e la quantità massima di sessioni allo stesso tempo. (un po 'come un attacco SYN TCP)
Leggi altre domande sui tag denial-of-service tls ddos