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

[Jakob Bohm]

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>