On 09/12/2014 21:46, Jeffrey Walton wrote: > On Tue, Dec 9, 2014 at 2:07 PM, Amarendra Godbole > <amarendra.godbole at gmail.com> wrote: >> So Adam Langley writes "SSLv3 decoding function was used with TLS, >> then the POODLE attack would work, even against TLS connections." on >> his the latest POODLE affecting TLS 1.x. >> (https://www.imperialviolet.org/). >> >> I also received a notification from Symantec's DeepSight, that states: >> "OpenSSL CVE-2014-8730 Man In The Middle Information Disclosure >> Vulnerability". >> >> However, I could not find more information on OpenSSL's web-site about >> POODLE-biting-again. Did I miss any notification? Thanks. > Here's some more reading: > https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls > > There's nothing specific to OpenSSL. Its a design defect in the > protocols (its been well known that TLS 1.0 had the same oracle as > SSLv3 since only the IV changed between them). > > Its not surprising that a PoC demonstrates it against TLS 1.0. Many > have been been waiting for it. > > It looks like Ubuntu is going to have to enable TLS 1.1 and 1.2 in > 12.04 LTS for clients. > https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576. > _______________________________________________ Stop spreading FUD and lies. This is NOT a protocol weakness in any TLS version, it is an implementation *bug* affecting multiple TLS implementations, specifically those that don't implement the *required* checks of the padding during decryption. So far, there have been public reports about which server side TLS implementation have this particular bug, OpenSSL is in the clear, some (which?) NSS versions are insecure, F5 and A10 load balancing devices need a recently released patch for this specific issue. I have seen no reports on which client side TLS implementations have the bug. P.S. Also, Mr. Langley seems to blindly reiterate an over-interpretation of the well known dangers of bad mac-then-pad-then-encrypt to ban all mac-before-encrypt schemes in favor of the much more fragile "Authenticated Encryption" modes such as GCM. If you read the original paper that warned against mac-then-encrypt, its proofs explicitly depended on the possibility that multiple related encrypted strings would decrypt to the same mac+data and be accepted as identical, thus providing the oracle used in the POODLE and BEAST attacks, amongst others. Thus any Mac-then-encrypt scheme which guarantees that any change in the encrypted value will cause the mac check to fail (within the strength of the mac), should in my opinion remain at least as safe as encrypt-then-mac, and in my opinion be even safer, since the attacker can no longer observe and probe the mac protection independently of the encryption itself. SSLv3 and TLS have always done this right for stream ciphers, its just that the specific stream cipher RC4 has its own (unrelated) problems. One scheme, that I personally like, is to do pad-then-macprefix-then-encrypt. By including the padding in the mac calculation (as if part of the data), the classic oracle vulnerability goes away. By putting the high entropy keyed mac first, the predictable IV problem in CBC cipher modes (and similar) is solved in a stronger way than by sending an unencrypted IV (like TLS 1.2 does). I suspect (but have not done the math yet) that this is as strong as AuthEnc modes with perfect block ciphers, and stronger than those in the eventuality of either the cipher or mac having unexpected weaknesses. Despite these improvements, this scheme has the same implementation and size costs as the broken SSLv3 scheme, using the same implementation functions. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141212/debc4229/attachment-0001.html>
