Questo è non un difetto in TLS; è un semplice bug di sicurezza della memoria in OpenSSL.
Le migliori spiegazioni che ho incontrato finora sono i post del blog Diagnosis of the OpenSSL Heartbleed Bug di Sean Cassidy e Attack of the week : OpenSSL Heartbleed di Matthew Green.
In breve, Heartbeat consente l'uscita di un endpoint "Ti sto inviando alcuni dati, restituiscilo a me". Invia sia una lunghezza che i dati stessi. La cifra della lunghezza può essere fino a 64 KiB. Sfortunatamente, se si usa la lunghezza per claim "sto inviando 64 KiB di dati" (per esempio) e poi solo veramente invia, ad esempio, un byte, OpenSSL ti rimanderebbe il tuo byte - e 64 KiB (meno uno) di altri dati dalla RAM.
Ops!
Ciò consente all'altro destinazione di ottenere porzioni casuali di memoria dal processo utilizzando OpenSSL. Un utente malintenzionato non può scegliere quale memoria, ma se provano a sufficienza, la struttura dei dati della sua richiesta rischia di finire accanto a qualcosa di interessante, come le chiavi private, i cookie o le password degli utenti.
Nessuna di queste attività verrà registrata ovunque, a meno che non registri, come, tutti i dati di connessione TLS non elaborati.
Non buono.
Il fumetto xkcd sopra fa un buon lavoro illustrando il problema.
Modifica: ho scritto in un commento qui sotto che i messaggi di heartbeat sono crittografati. Questo non è sempre vero. Puoi inviare un heartbeat all'inizio dell'handshake TLS, prima che la crittografia sia stata attivata (anche se non dovresti). In questo caso, sia la richiesta che la risposta saranno non criptate. Nell'uso normale, gli heartbeat dovrebbero sempre essere inviati in seguito, crittografati, ma la maggior parte degli strumenti di exploit probabilmente non si preoccuperanno di completare l'handshake e attendere la crittografia. (Grazie, RedBaron.)