On Thu, Sep 22, 2011 at 9:11 AM, Guyer, Don <[email protected]> wrote: > I don’t even pretend to be a security expert by any means, I find this > article confusing…..
Most likely, the author of the article was confused, too. The tech press is something akin to blind men describing an elephant. Additionally, even original information is limited right now (they haven't given their presentation yet). > It seems to be a high vulnerability, but when I read the sentence “It has > long been theorized > that attackers can manipulate the process to make educated guesses about the > contents > of the plaintext blocks.” I've seen differing analyses so I'm not really sure, but this is one that makes the most sense to me: The attack uses JavaScript injection (browser compromise) and a packet sniffer (compromise of the network medium) to force a chosen-plaintext, which can then be used to recover other plaintext from the SSL ciphertext. No man-in-the-middle is needed, although that may be a force-multiplier. A1. SSL is a chained block cipher. Bytes on the wire are sent in ciphered blocks, where each block's key is dependent on the previous block. B1. The user browses to a site like PayPal using SSL. They authenticate using their credentials. B2. PayPal gives them an HTTP cookie containing some very large random data. This data serves to authenticate their login session. The cookie is a temporary shared secret granting access to their user account. B3. The cookie from B2 is protected by SSL on the wire, and thus should be secure against sniffing. B4. The cookie is marked as "secure" in the browser's cookie jar, and thus won't be given to non-SSL pages. C1. The attack injects some JavaScript into the browser somehow. C2. C1 constructs a URL that is just long enough to push all but the first byte of the cookie C3. C1 forces the browser to request C2 from the SSL site. C4. The attack sniffs C3 from the wire. C5. The attack now has a know-plaintext (the URL) and a single unknown byte -- the first byte of the B2 cookie. C6. The attack does crypto magic on C5, benefiting from the known-plaintext, to decrypt the first byte of the B2 cookie. C7. The attack repeats C2 through C6, shortening the URL each time, to decrypt the rest of the cookie one byte at a time. B5. After C7 is done, the attack now has the entire B2 authentication cookie, and can masquerade as the user. (from http://news.ycombinator.com/item?id=3016175) There may be scenarios other than B (auth cookie recovery) which could also use the technique in C to gain valuable plaintext. Or not; I dunno. Again, I'm waiting for the full release, and good trusted third-party analysis, before I really react. I know enough about crypto to understand a good analysis, but not enough to do it on my own. There are very likely aspects of this I'm not seeing. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
