On 12-12-2014 21:31, Jeffrey Walton wrote:
On Fri, Dec 12, 2014 at 5:23 AM, Jakob Bohm <jb-open...@wisemo.com> wrote:
On 09/12/2014 21:46, Jeffrey Walton wrote:
On Tue, Dec 9, 2014 at 2:07 PM, Amarendra Godbole
<amarendra.godb...@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.
The cryptographers would disagree with you. The various attacks
against the design defects appear to offer proof by counter example.
Here's the analysis by Krawczyk: "The Order of Encryption and
Authentication for Protecting Communications",
http://www.iacr.org/archive/crypto2001/21390309.pdf.
Here's his recent remarks on the TLS WG mailing list where he
revisited his conclusions, and called out SSL/TLS as being
unconditionally insecure (due to a misunderstanding in the way padding
was applied). From
http://www.ietf.org/mail-archive/web/tls/current/msg13677.html:
So the math in the paper is correct - the
conclusion that TLS does it right is wrong.
It doesn't.
He is saying exactly what I said (padding before mac is safe, TLS with
CBC does thatwrong). The only thing I said was right was the SSL case
with no padding at all (stream ciphers, in casethere was a good one in
SSL 3).
Now the POODLE against TLS 1.0 is NOT about all that. It is about
*broken* TLS 1.0implementations that fail to implement the indirect
protection of the padding specified in the TLS 1.0 RFC.Specifically,
those implementations fail to implement that only a single padding
content value is authenticfor each given padding size, and at most 32
padding size/value pairs are valid for any given authenticatedmessage
size.
This indirect protection in TLS 1.0 greatly reduces the power of the
padding oracle, since the chance thatan interesting plaintext snippet
matches one of the 32 permitted values is a lot less than the chance of
matching one of the 2**61 permitted values in SSL 3 padding. These
numbers are for 64 bit block size,for 128 bit block size, the numbers
are 16 vs 2**124 . Variations in how the attacker detects "acceptance
as padding" could change the numbers to 256 or 1 for *correct* TLS 1.0
pad checks versus 2**64 or 2**56for SSL 3.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Soborg, 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
_______________________________________________
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
