On Wed, 21 Sep 2011 13:54:45 +1200 RussellMc wrote: > People with major dependence on HTTPS / SSL security may wish to > consider if short term action is necessary re this issue. >=20 > >=20 > 'Whitehat' demo code shows that Paypal, Google/GMAIL and most other > SSL "secured" sites/links are vulnerable to attack. > (HTTPS is THE primary method of protection generally used in most > internet transactions so this vulnerability is *potentially* of > relevance to most secure internet access systems). > The demonstration system is due for demonstration at the 3 day > Ekoparty conference in Buenos Aires which starts today > so it's highly likely that no > real-world security breach exists. Yet. >=20 > The next two paragraphlets may or may not make sense :-) : >=20 > Exploit is "certain" given specified conditions but with processing > power used by demo system takes around 1 to 2 seconds per byte of the > encrypted permissions cookie which is used to mount the attack so say > typically half an hour to 'crack' a Paypal account. >=20 > I'm unaware if the method is amenable to acceleration by vast parallel > attack but, if so, use of "web resources" would allow much more rapid > decodes. Presumably also a dedicated solver may help and would almost > be worth implementing during this "window of opportunity". >From looking at the major differences between TLS1.0 (vulnerable) and TLS1.1 (not vulnerable), this caught my eye: "Handling of padding errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks." (RFC4346 section 1.1). This reminds me of the following attack against SSH: http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf Although the mechanisms implied are different (the former being examining the failure mode of the decryption and the latter being examining how much data is accepted before failure), they are similar in that both involve exploiting the fact that corrupt ciphertext may be used by the recipient in some way before the MAC is checked (in the former case to verify the padding, in the latter case to extract the packet length field) and that the attacker can therefore extract information from the result of that use. I have no idea if this is what the authors of the TLS presentation were going for, but it's what I was reminded of when I read the article, and I wonder if they've found something similar. Chris --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .