4 ms·
The underlying vulnerability in TLS1.0 is described here: http://www.mail-archive.com/openssl-dev@openssl.org/msg10664.html http://www.mail-archive.com/openssl-
by caf 15y ago
The underlying vulnerability in TLS1.0 is described here: http://www.mail-archive.com/openssl-dev@openssl.org/msg10664.html http://www.mail-archive.com/openssl-dev@openssl.org/msg10664...
Surmising from this and the scant details released: It is a chosen-plaintext attack. Requests to the logged-in SSL site are made by injected Javascript in a separate non-SSL page. By changing the length of the requested URL (easily done by appending GET variables), the authentication cookie header is pushed out so that the first unknown character is right at the end of a cipher block. This allows us to make guesses at that character, testing each guess using the method described by Wei Dai in the linked email (using another crafted request to the server). Once we've found the first character, we push the cookie one byte further back and work on the second character, repeating until we have the entire unknown portion of the cookie.
If this turns out to be somewhat accurate, a workaround could be to have the browser force the HTTP headers to be block-aligned, by inserting a dummy first header if necessary.
- benmmurphy 15y agoi think this is the original paper: http://eprint.iacr.org/2006/136 http://eprint.iacr.org/2006/136
- caf 15y agoNote that the mail I'm quoting is from 2002, predating Bards paper by several years.
- asdfaoeu 15y agoI think you would need to have the last unknown character at the start of the next cipher block as you would need to control the content of the cipher block directly after that.
- caf 15y agoThe idea is that if you force the browser to produce the ciphertext of a block like "kie: sessionid=f", where the first 15 characters are already known, then you don't have to try many candidate plaintext blocks through your adaptive-chosen-plaintext oracle to find that unknown 16th character.