Come difendersi dagli attacchi SSL-Esaurimento?

9

Il problema degli attacchi di estinzione SSL è ben noto da anni, ma a nessuno importa davvero fino a quando il THC non ha pubblicato il strumento di exploit di recente. THC parla delle contromisure nel loro rilascio:

Non esistono soluzioni reali. I seguenti passaggi possono attenuare (ma non risolvere) il problema:

1. Disabilita rinegoziazione SSL

2. Investire in SSL Accelerator

Ciascuna di queste contromisure può essere elusa modificando THC-SSL-DOS. È auspicabile una soluzione migliore. Qualcuno dovrebbe aggiustarlo.

L'idea 1 semplicemente non funziona perché il nucleo del problema non è basato sulla rinegoziazione SSL. Non sono sicuro dell'idea 2, gli acceleratori SSL. Quanti sistemi dedicati per l'accelerazione SSL avresti bisogno di prevenire un grosso attacco SSL-Esaurimento? Questo ha senso per un server SSL medio?

Quindi, quello che sto chiedendo è, cosa possiamo fare per prevenire tali attacchi fino a quando non sarà disponibile una soluzione al problema principale? Come possiamo proteggere i nostri server che si basano sulla crittografia?

    
posta Demento 28.10.2011 - 11:43
fonte

2 risposte

10

"Esaurimento SSL" è un'espressione mediocre per un attacco più generico noto come "non giocare bene". In termini generali, va così: un server offre un servizio di rete, che, sul server, non è libero: quando arriva un cliente, il server deve investire alcuni dei suoi preziosi cicli di CPU in risposta a quel cliente. L '"attaccante" è quindi qualcuno che imita molti clienti bisognosi, sovraccaricando il server. Nel caso di SSL, l'investimento è sostanziale a causa della crittografia coinvolta; ma il concetto funziona anche quando lo sforzo del server è la magra quantità di CPU e RAM necessarie per stabilire semplicemente una connessione TCP (che si chiama SYN flood , ma, da un punto di vista di alto livello, questa è la stessa cosa).

Una possibile contromisura (non possibile nel caso di SSL così com'è, ma potrebbe essere aggiunta come parte di una modifica del protocollo) è richiedere una "prova di lavoro" da parte del cliente. In SSL, è facile imitare i passaggi iniziali di una connessione client senza eseguire alcuna operazione di crittografia (è sufficiente inviare una posta indesiderata casuale anziché la chiave pre-master crittografata con RSA prevista o la chiave pubblica client Diffie-Hellman): questo è ciò che dovrebbe essere cambiato. Ci sono alcuni suggerimenti sulla pagina di Wikipedia su questo argomento.

Per SSL come attualmente specificato e distribuito, non hai altra scelta che:

  • cerca di identificare i trasgressori abbastanza presto, ad es. troppe richieste di connessione ripetute dallo stesso IP (questo significa che blocchi DoS che non è DDoS - in parole semplici, l'attaccante dovrà assumere underlings / zombies);
  • seleziona le suite di crittografia che sono "economiche" per il server (non utilizzare chiavi sovradimensionate! 1536 bit sono sufficienti) (prova RSA invece di DHE_RSA);
  • neutralizza l'attaccante inserendo più muscoli in esso, ad es. acceleratori hardware o più PC (il PC potrebbe essere più economico, ma utilizzare più spazio di hosting e il bilanciamento del carico richiede un'amministrazione di sistema aggiuntiva).
risposta data 28.10.2011 - 15:41
fonte
2

Penso che tu abbia perso il punto, lo strumento di THC non riguarda lo sfruttamento dei sistemi. Si tratta più di testare i propri sistemi per assicurarsi che tu sia al sicuro. Se sei preoccupato, la prima cosa che devi fare è eseguire THC-SSL-DOS contro il tuo sistema per vedere quanto sei sostenibile ad attaccare . SSL non è rotto, è ancora la cosa migliore che abbiamo.

I modi per mitigare questo attacco è usare una suite di cifratura leggera . E come hai sottolineato Cisco consiglia vivamente utilizzando un acceleratore hardware SSL ($$$) e disabilitazione della "rinegoziazione sicura" di ssl.

    
risposta data 28.10.2011 - 16:05
fonte

Leggi altre domande sui tag