Timeline for SSL3 "POODLE" Vulnerability
Current License: CC BY-SA 3.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 7, 2021 at 7:24 | history | edited | CommunityBot |
replaced https://tools.ietf.org/html/draft with https://datatracker.ietf.org/doc/html/draft
|
|
| May 22, 2015 at 11:57 | comment | added | Thomas Pornin | No. The reference to IETF in the draft and RFC 6979 is generic; it comes in "automatically" when submitting an informational RFC. | |
| May 22, 2015 at 3:59 | comment | added | Pacerier | @ThomasPornin, Btw, are you from IETF? | |
| Oct 23, 2014 at 10:49 | comment | added | Thomas Pornin | @Eddie: in CBC, whenever a block is encrypted, it is first XORed with the result of the encryption of the previous block. Since the first block does not have a "previous block", the IV is used. (In the case of SSL 3.0, the IV for a record is the last encrypted block of the previous record, and the very first IV is generated from the key exchange mechanism at the same time as the encryption key.) | |
| Oct 23, 2014 at 2:41 | comment | added | Eddie | @ThomasPornin, in your description, you mention the previous encrypted block is e0-e7. But then you say c0 is XOR'd with e0. How can there be an encryption block "previous" to the 0th' block of cipher? I think the answer is e0 is the Initialization Vector, but I wanted to ask to be sure. In your explanation of "What enters 3DES", is e0 the IV? | |
| S Oct 17, 2014 at 9:32 | history | suggested | Andrew Grimm | CC BY-SA 3.0 |
Remove gender specific pronouns
|
| Oct 17, 2014 at 9:06 | review | Suggested edits | |||
| S Oct 17, 2014 at 9:32 | |||||
| Oct 17, 2014 at 2:35 | comment | added | Ky - | your "in a nutshell" is very long and confusing, and takes a while to get to the point. Perhaps distill it or unlabel it as a nutshell? | |
| S Oct 16, 2014 at 1:16 | history | suggested | Tim | CC BY-SA 3.0 |
Adjusted phrasing to make it clear the vulnerability is what was released yesterday, not the protocol
|
| Oct 16, 2014 at 0:48 | comment | added | gsgx | @cpast Yes, the attacker needs to vary the request. This is very easy to do though, because there are often parameters in the HTTP headers that come before the cookie that can be varied. | |
| Oct 16, 2014 at 0:12 | review | Suggested edits | |||
| S Oct 16, 2014 at 1:16 | |||||
| Oct 16, 2014 at 0:11 | comment | added | Tim |
Might want to adjust this phrasing: The "Poodle" vulnerability is an attack on the SSL 3.0 protocol released on October 14th, 2014. Initially I thought this meant that the vulnerable protocol was released Oct 14th, 2014, and I figured that since no day-old protocol could possibly be widespread, I don't have to do anything...
|
|
| Oct 15, 2014 at 17:55 | review | Suggested edits | |||
| Oct 15, 2014 at 18:17 | |||||
| Oct 15, 2014 at 15:47 | comment | added | armb | The SSL 3.0 symmetric cipher that doesn't use CBC mode is RC4, which may well be disabled for reasons also well explained by Thomas (and the NULL "cipher") - security.stackexchange.com/questions/32497/tls-rc4-or-not-rc4/… | |
| Oct 15, 2014 at 14:48 | comment | added | Thomas Pornin | @MatthewPeters: I like to write. Writing makes more sense when there are readers. | |
| Oct 15, 2014 at 14:47 | comment | added | Matthew Peters | @ThomasPornin, what motivates you to write such amazing and detailed answers -seriously? | |
| Oct 15, 2014 at 14:38 | comment | added | Graeme Perrow | One option is to use the new SSL extension (TLS_FALLBACK_SCSV) to prevent connections from being forcibly downgraded to SSLv3; this means you don't have to disable SSLv3 entirely, in case you need to connect to a server that doesn't support anything above SSLv3. But if you make a connection to that server, aren't you still vulnerable? | |
| S Oct 15, 2014 at 14:27 | history | edited | Thomas Pornin | CC BY-SA 3.0 |
Also two-exponents
|
| S Oct 15, 2014 at 14:27 | history | suggested | user | CC BY-SA 3.0 |
Also two-exponents
|
| Oct 15, 2014 at 14:19 | review | Suggested edits | |||
| S Oct 15, 2014 at 14:27 | |||||
| Oct 15, 2014 at 10:31 | comment | added | Tomalak | @ThomasPornin No ciphers don't have the string "CBC" in the FireFox "about://config" page, that's why I asked. | |
| Oct 15, 2014 at 10:30 | comment | added | Thomas Pornin |
@Tomalak: cipher suites have symbolic names like SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA; see the list for SSL 3.0 in RFC 6101. The cipher suites that use CBC are exactly those that contain "CBC" in their name.
|
|
| Oct 15, 2014 at 9:45 | comment | added | Stéphane Chazelas | What about the forced/unsafe out of protocol downgrade to SSLv3? What are the software affected by that? | |
| Oct 15, 2014 at 6:38 | comment | added | Luke Rehmann | Check if SSL 3.0 is enabled on your server at poodlebleed.com | |
| Oct 15, 2014 at 6:35 | comment | added | Tomalak | "Disable support for CBC-based cipher suites" - A list of which ciphers run in CBC mode would be nice to help decide what to disable. | |
| Oct 15, 2014 at 4:54 | comment | added | cpast | I'm still somewhat confused. Does the attacker also have to vary the request in order to vary the final byte of the final block (aside from the padding block) until that final byte XOR the cookie byte in question is equal to 7? And is there a reason you said the last cookie byte, or can it work on any byte of the cookie if the attacker arranges things so that byte ends a block? | |
| Oct 15, 2014 at 2:10 | comment | added | user2813274 | "Cryptographic attacks are neat, but they involve more effort than exploiting the bottomless well of user's gullibility." I have the feeling I will be quoting this at some point.. +1 | |
| Oct 15, 2014 at 2:05 | comment | added | KnightOfNi | "If you do not install the patches then Níðhöggr will devour your spleen." I think that should be the new Backtrack/Kali motto. Needless to say, +1 for not only posting a freaking dissertation, but also making it... well, let's say 'easy to remember.' | |
| Oct 15, 2014 at 1:46 | comment | added | user49075 | At least Firefox has a user friendly way (described in that answer). | |
| Oct 15, 2014 at 1:13 | comment | added | gertvdijk | @RickyDemer As a user you can configure that in your browser. But don't ask for a user friendly way. See askubuntu.com/a/537197/88802 | |
| Oct 15, 2014 at 1:11 | comment | added | user49075 | Is "Disable SSL 3.0 support in the client" something that ordinary users can easily do, or something that would require a change in the software? | |
| Oct 15, 2014 at 1:07 | vote | accept | tylerl | ||
| Oct 15, 2014 at 0:57 | history | answered | Thomas Pornin | CC BY-SA 3.0 |