An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers.
第三個則有可能直接爆破執行程式碼：
A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server.
Turning off compression is not an option for large dynamic sites such as Facebook because it would hinder performance dramatically.
而且就算關掉 TLS 的 compression，也還是有疑慮：
Even if TLS-level compression is disabled, it is very common to use gzip at the HTTP level. Furthermore, it is very common that secrets (such as CSRF tokens) and user input are included in the same HTTP response, and therefore (very likely) in the same compression context,
節錄幾段 migrate 的重點：
Facebook disclosed how it’s mitigating BREACH attacks by changing the frequency in which it rotates CSRF tokens from daily to each time a Facebook session is started.
本來 CSRF token 變更的頻率是好幾天一次，把頻率拉高...
After a new token is issued, the previous tokens still remain valid for a couple days, resulting in multiple tokens being permissible simultaneously.
We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.
I managed to find this image uploaded by Varun Kumar on February 1 2013, showing that Facebook’s CDN hostname *.fbcdn.net was serving static resources like images and JavaScript via SPDY.
// Decrypt to plaintext + mac + padding
$plaintext_mac_padding = decrypt($ciphertext);
if (NULL != $plaintext_mac_padding) {
// Now decode padding part
$plaintext_mac = decode_padding($plaintext_mac_padding, $padding_length);
if (NULL != $plaintext_mac) {
// Now check MAC part
$plaintext = check_mac(plaintext_mac);
if (NULL != $plaintext) {
// Now it's okay
}
}
}
In general, the best way to do this is to compute the MAC even if the padding is incorrect, and only then reject the packet. For instance, if the pad appears to be incorrect, the implementation might assume a zero-length pad and then compute the MAC.
This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal.
The attacks apply to all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. They also apply to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to previous padding oracle attacks. Variant attacks may also apply to non-compliant implementations.
