By admin | 17 October 2014 | 0 Comments
SSL 3.0 [RFC6101] is an obsolete and insecure protocol. While for most practical purposes it has been replaced by its successors TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], and TLS 1.2 [RFC5246], many TLS implementations remain backwardscompatible with SSL 3.0 to interoperate with legacy systems in the interest of a smooth user experience. The protocol handshake provides for authenticated version negotiation, so normally the latest protocol version common to the client and the server will be used. However, even if a client and server both support a version of TLS, the security level offered by SSL 3.0 is still relevant since many clients implement a protocol downgrade dance to work around serverside interoperability bugs. In this Security Advisory, we discuss how attackers can exploit the downgrade dance and break the cryptographic security of SSL 3.0. Our POODLE attack (Padding Oracle On Downgraded Legacy Encryption) will allow them, for example, to steal “secure” HTTP cookies (or other bearer tokens such as HTTP Authorization header contents). We then give recommendations for both clients and servers on how to counter the attack: if disabling SSL 3.0 entirely is not acceptable out of interoperability concerns, TLS implementations should make use of TLS_FALLBACK_SCSV. CVE20143566 has been allocated for this protocol vulnerability
The POODLE Attack
- The padding fills an entire block (encrypted into Cn).
- The cookies’ first asofyet unknown byte appears as the final byte in an earlier block (encrypted into Ci)
Usually, the server will reject this record, and the attacker will simply try again with a new request. Occasionally (on average, once in 256 requests), the server will accept the modified record, and the attacker will conclude that DK (Ci ) ⊕ Cn1  = 15, and thus that Pi  = 15 ⊕ Cn1  ⊕ Ci1 . This reveals the cookies’ first previously unknown byte. The attacker proceeds to the next byte by changing the sizes of request path and body simultaneously such that the request size stays the same but the position of the headers is shifted , continuing until it has decrypted as much of the cookies as desired. 1 The expected overall effort is 256 SSL 3.0 requests per byte. As the padding hides the exact size of the payload, the cookies’ size is not immediately apparent, but inducing requests GET /, GET /A, GET /AA, ... allows the attacker to observe at which point the block boundary gets crossed: after at most 16 such requests, this will reveal the padding size, and thus the size of the cookies.
The attack described above requires an SSL 3.0 connection to be established, so
disabling the SSL 3.0 protocol in the client or in the server (or both) will completely avoid it.
If either side supports only SSL 3.0, then all hope is gone, and a serious update required
to avoid insecure encryption. If SSL 3.0 is neither disabled nor the only possible protocol
version, then the attack is possible if the client uses a downgrade dance for
Disabling SSL 3.0 entirely right away may not be practical if it is needed occasionally to
work with legacy systems. Also, similar protocol version downgrades are still a concern
with newer protocol versions (although not nearly as severe as with SSL 3.0). The
TLS_FALLBACK_SCSV mechanism from [draftietftlsdowngradescsv00] addresses the
broader issue across protocol versions versions, and we consider it crucial especially for
systems that maintain SSL 3.0 compatibility. The following recommendations summarize
how TLS_FALLBACK_SCSV works.
TLS clients that use a downgrade dance to improve interoperability should include the
value 0x56, 0x00 (TLS_FALLBACK_SCSV) in ClientHello.cipher_suites in any fallback
handshakes. This value serves as a signal allowing updated servers to reject the
connection in case of a downgrade attack. Clients should always fall back to the next
lower version (if starting at TLS 1.2, try TLS 1.1 next, then TLS 1.0, then SSL 3.0) because
skipping a protocol version forgoes its better security. (With TLS_FALLBACK_SCSV,
skipping a version also could entirely prevent a successful handshake if it happens to be
the version that should be used with the server in question.)
In TLS servers, whenever an incoming connection includes 0x56, 0x00
(TLS_FALLBACK_SCSV) in ClientHello.cipher_suites, compare ClientHello.client_version
to the highest protocol version supported by the server. If the server supports a version
higher than the one indicated by the client, reject the connection with a fatal alert
(preferably, inappropriate_fallback(86) from [draftietftlsdowngradescsv00]).
This use of TLS_FALLBACK_SCSV will ensure that SSL 3.0 is used only when a legacy implementation is involved: attackers can no longer force a protocol downgrade. (Attacks remain possible if both parties allow SSL 3.0 but one of them is not updated to support TLS_FALLBACK_SCSV, provided that the client implements a downgrade dance down to SSL 3.0.)
- [BEAST] T. Duong, J. Rizzo: “Here Come The ⊕ Ninjas”, 2011.
- [draftietftlsdowngradescsv00] B. Möller, A. Langley: “TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks”, InternetDraft draftietftlsdowngradescsv00, 2014.
- [Lucky13] N.J. AlFardan, K.G. Paterson: “Lucky Thirteen: Breaking the TLS and DTLS Record Protocols”, IEEE Symposium on Security and Privacy, 2013.
- [RC4biases] N.J. AlFardan, D.J. Bernstein, K.G. Paterson, B. Poettering, J.C.N. Schuldt: “On the Security of RC4 in TLS and WPA”, USENIX Security Symposium, 2013.
- [RFC2246] T. Dierks, C. Allen: “The TLS Protocol Version 1.0”, RFC 2246, 1998.
- [RFC4346] T. Dierks, E. Rescorla: “The Transport Layer Security (TLS) Protocol Version 1.1”, RFC 4346, 2006.
- [RFC5246] T. Dierks, E. Rescorla: “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, 2008.