Quanto è pratico / importante l'attacco Lucky Thirteen TLS?

Quando l'attacco è stato descritto per la prima volta nel 2003 (il "bad padding" oracle attraverso l'analisi dei tempi), lo scenario di attacco previsto era un client di posta elettronica (ad esempio Outlook Express) che si collegava regolarmente (ad esempio una volta al minuto) al server per sapere se è arrivata nuova posta (non puoi essere notificato di nuova posta quando usi il protocollo POP , devi sondare). Poiché ogni connessione inizia con la stessa fase di autenticazione, la password di destinazione si trova in una posizione deterministica e riproducibile nello stream e, poiché Outlook Express è notoriamente negativo nella segnalazione degli errori (ovvero è silenzioso o aggiorna solo una vecchia messaggio di errore che l'utente è stato addestrato a ignorare), quindi è stata una buona configurazione per l'attacco.

Un punto importante da fare è che tali attacchi devono verificarsi vicino al punto decrittazione , dove i "dati interessanti" (la password) sta per essere decodificati. Nello scenario del server di posta, questo è vicino al server , non al client.

Il "Lucky Thirteen" aggiunge due nuovi punti dati:

1. Sottolinea che la difesa comune contro gli attacchi temporali (vale a dire, quando il padding è sbagliato, si comporta come se fosse buono e calcola comunque il MAC) può perdere un po '(perché il "padding supposto" non avere la lunghezza esatta della "buona imbottitura"). Quando l'attacco iniziale del 2003 ha usato ritardi di circa 1 millisecondo, la nuova perdita è circa un migliaio di volte più breve, circa 1 microsecondo.

2. Dimostra che in condizioni di laboratorio (100 Mbit / s ethernet con un solo switch tra target e attacker, milioni di misure) misure fino a circa 1 microsecondo sono fattibili.

Il primo punto è ovviamente interessante. Vorrei affermare, tuttavia, che il secondo punto ha questo difetto fondamentale: se l'attaccante può avvicinarsi al bersaglio, quindi può vincere in molti altri modi. Infatti, gli attacchi temporali riguardano l'estrazione di informazioni da un sistema chiuso attraverso perdite di dati basate sul tempo. Noi crittografi tendiamo a concentrarci sullo strato crittografico, perché quello è il nostro lavoro, e la crittografia riguarda esclusivamente la concentrazione dei segreti : la "chiave" è l'essenza della segretezza e un obiettivo molto prezioso. Tuttavia, l'intero punto di crittografia è proteggere i dati sensibili e qualsiasi elaborazione di dati riservati può perdere parte di essa attraverso i tempi .

In uno stack di elaborazione dati completo, il livello SSL / TLS rimane tra lo stack TCP / IP di basso livello e "l'applicazione" che utilizza i dati riservati in vari modi. Poiché la decrittografia si verifica in TLS, il livello TCP / IP vede solo chunk cifrati e quindi non ha nulla da perdere. Tuttavia, sarebbe troppo ottimistico, rasentando le assurdità, credere che le perdite potrebbero verificarsi solo nel livello TLS. Il codice di applicazione completo è potenzialmente vulnerabile agli attacchi di temporizzazione. Mentre un attacco a TLS è di per sé più interessante, dichiaro che gli attacchi al codice dell'applicazione hanno molte più probabilità di essere devastanti.

Per riassumere, l'attacco "tredici fortunati" è interessante ma non molto realistico. Per quanto riguarda gli attacchi temporali, il livello TLS è solo la punta dell'iceberg. Per abusare ulteriormente della metafora, preoccuparsi dei "tredici fortunati" è un po 'come preoccuparsi della corrosione a bordo del Titanic: una preoccupazione valida in un modo astratto, ma non così pressante come altre questioni legate alla nautica.

Ti rimando a questo post sul blog in particolare di Matthew Green che fornisce una buona descrizione dell'attacco. In particolare questa citazione.

But there's no way this will work on TLS! It'll kill the session! Please recall that I described this as a practical attack on Datagram TLS (DTLS) -- and as a more theoretical one on TLS itself.* There's a reason for this.

The reason is that TLS (and not DTLS) includes one more countermeasure I haven't mentioned yet: anytime a record fails to decrypt (due to a bad MAC or padding error), the TLS server kills the session. DTLS does not do this, which makes this attack borderline practical. (Though it still takes millions of packet queries to execute.)

The standard TLS 'session kill' feature would appear to stop padding oracle attacks, since they require the attacker to make many, many decryption attempts. Killing the session limits the attacker to one decryption -- and intuitively that would seem to be the end of it.

But actually, this turns out not to be true.

You see, one of the neat things about padding oracle attacks is that they can work across different sessions (keys), provided that that (a) your victim is willing to re-initiate the session after it drops, and (b) the secret plaintext appears in the same position in each stream. Fortunately the design of browsers and HTTPS lets us satisfy both of these requirements. To make a target browser initiate many connections, you can feed it some custom Javascript that causes it to repeatedly connect to an SSL server (as in the CRIME attack). Note that the Javascript doesn't need to come from the target webserver -- it can even served on an unrelated non-HTTPS page, possibly running in a different tab. So in short: this is pretty feasible. Morover, thanks to the design of the HTTP(S) protocol, each of these connections will include cookies at a known location in HTTP stream. While you may not be able to decrypt the rest of the stream, these cookie values are generally all you need to break into somebody's account. Thus the only practical limitation on such a cookie attack is the time it takes for the server to re-initiate all of these connections. TLS handshakes aren't fast, and this attack can take tens of thousands (or millions!) of connections per byte. So in practice the TLS attack would probably take days. In other words: don't panic.

On the other hand, don't get complacent either. The authors propose some clever optimizations that could take the TLS attack into the realm of the feasible (for TLS) in the near future.

Chiedi:

How difficult it would be to take out of a lab environment into a known LAN, or from a known LAN to a WAN?

Poiché l'attacco comporta la misurazione di differenze temporali molto piccole, potrebbe essere leggermente difficile sfruttarlo al di fuori dell'ambiente di laboratorio.

How difficult and how necessary would it be to defend against this attack given that I don't necessarily have control over the software? Are there methods of randomly padding and delaying HTTPS responses to avoid timing attacks?

Sembra che ci sia poco che un utente finale possa fare per difendersi da questo attacco. Gli amministratori di sistema possono contribuire a mitigare ciò aggiornando le loro implementazioni SSL, passando alla crittografia RC4 (come misura temporanea) e utilizzando le cipheritee AEAD come AES-GCM.

How does this interact with current attacks against SSL/TLS such as BEAST? Does it provide an amplifying effect?

Come il team dietro l'attacco suggerito , l'attacco può essere migliorato combinandolo con lo stile BEAST tecniche.

How important is this result when considering future implementations?

L'attacco non è niente di nuovo quando si tratta di teoria, è common knowledge che devi sempre criptare prima di applicare il MAC.

Per quanto riguarda la difesa, sotto Linux si potrebbe fare qualcosa del genere:

tc qdisc add dev eth0 root netem delay 3ms 1ms

aggiungere un ritardo casuale a un'interfaccia di rete come difesa di base dagli attacchi temporali, come menzionato in Presvisazione delle Black Ops 2012 di Kaminsky .

Ovviamente c'è un compromesso tra prestazioni, ma pochi millisecondi sono banali in molte situazioni.