[openssl-users] CVE-2014- and OpenSSL?

[Jakob Bohm]

On 12-12-2014 21:31, Jeffrey Walton wrote:
> On Fri, Dec 12, 2014 at 5:23 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>> 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.
> 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