Timeline for What role does clock synchronization play in SSL communcation
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 13, 2014 at 18:41 | comment | added | schroeder♦ | @cpast Yes, POODLE works on live streams only and not recorded packets. I'm fighting a cold, so I might just delete this whole answer. It's clear to me, but I seem to be unable to articulate. | |
| Nov 13, 2014 at 18:35 | comment | added | cpast | @schroeder POODLE, as far as I can tell, involves carefully leaking a tiny component of a communication, and can't be used to decrypt the whole message (also, it requires the ability to modify their plaintext before encryption, and doesn't work at all to decrypt intercepted SSL communications). I don't see how POODLE has the slightest relevance to recorded packets, because it is not an attack that can be used on them. | |
| Nov 13, 2014 at 18:21 | comment | added | schroeder♦ | @cpast I might need to edit to show that modification is an option. As for SSL being secure, have you heard about POODLE? | |
| Nov 13, 2014 at 18:17 | comment | added | schroeder♦ | @ThomasPornin I wasn't just thinking about SSL, but things like REST and authentication schemes where timestamps are useful for protecting against replay. | |
| Nov 13, 2014 at 17:38 | comment | added | Thomas Pornin |
Even with inaccurate clocks, SSL cannot be replayed (because of the client_random and server_random values). Bad clocks may imply issues with certificate validation, though.
|
|
| Nov 13, 2014 at 17:36 | comment | added | mclark1129 | @cpast I was kind of thinking the same thing. How susceptible are packets to being captured, and does this mean that it is reusable throughout the acceptable window? | |
| Nov 13, 2014 at 17:31 | comment | added | cpast | How could they decrypt the packets? I thought the point of a replay attack was that the data wasn't modified, it was just resent as-is to trigger the same operation again, because SSL is not decryptable for the forseeable future (i.e. the time decryption takes is long enough that synchronizing the clocks to around a couple billion years is enough to prevent decryption before the timestamp expires). | |
| Nov 13, 2014 at 17:03 | history | answered | schroeder♦ | CC BY-SA 3.0 |