[openssl-users] Multithreading: Global locks causing bottleneck in parallel SSL_write calls

[Jakob Bohm]

On 13/04/2017 22:01, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dipak Gaigole
>> Sent: Thursday, April 13, 2017 15:12
>>   I will try with disabling FIPS.
> Opinions differ, but many people - including myself - recommend not enabling FIPS mode unless it is explicitly required (generally because you work for the US Federal Government or a relatively small number of other organizations that let bureaucracy stand in the way of security).
>
>> Where can i find current best practice cipher list? Or Can you suggest few?
> The free ebook /OpenSSL Cookbook/ from Feisty Duck is a good place to start. It was updated only a year ago, so it's reasonably current.
>
> https://www.feistyduck.com/books/openssl-cookbook/
>
> Beyond that, you really need to be following current research, or at least the people who write knowledgeably about current research.
>
> Ben wrote "AES256-SHA is both CBC and SHA1, neither of which is really a current best practice". Certainly the bloom is off the rose of SHA1, particularly since the "SHAttered" demonstration of a successful collision. The reality is that SHA1 is still fine for many purposes in practice; but if you're in a position to pick a better digest, it makes sense to do so. That means SHA-256 or SHA-384; or perhaps SHA3 with appropriate parameters, but SHA3 hasn't seen widespread adoption yet. (That's more or less by design - NIST wanted to standardize SHA3 before it was needed.)
>
> Regarding CBC, he presumably was referring to the various issues with CBC mode and the general move to various AE and AEAD combining modes, particularly GCM. AES-GCM suites are most people's default recommendation these days, when there aren't any compelling reasons to use something else. With GCM you have to be careful that you have a solid implementation and you never reuse an IV, so it's a bit easier for a non-expert to screw up. But considering the aforementioned issues with CBC, it's easy to see why people recommend it.
>
> There's a ton of information - more than a non-expert can be expected to absorb - on these topics available online, even if we ignore the actual primary research and just look at treatments for lay readers. Adam Langley talks about the problems with AES-CBC in particular in this post, for example:
>
> https://security.googleblog.com/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html
>
> In TLS, AES-CBC is vulnerable to the BEAST (TLS 1.0 only) and Lucky13 attacks, given certain other conditions. Lucky13 (aka "Lucky Thirteen") actually applies to all block ciphers in CBC mode, if the implementation exposes certain timing side channels. These days decent implementations (including OpenSSL) try to remove or whiten side channels, but that's actually quite difficult to do comprehensively (see various pieces of research published over the past several years). Again, for many applications, these attacks simply aren't feasible. But many applications are developed without the benefit of a cryptographer who can look at them and decide whether you need to worry about them.

Please note that all of these "CBC vulnerabilities" you specifically
mention are SSL/TLS vulnerabilities in the particular ways that SSL3
and current TLS versions handle padding and IV management, not
issues with CBC itself.

Also note that GCM is very much a "marginal" design, operating at the
very edge of what is safe to do and furthermore putting all the
cryptographic "eggs" in one basket (AES and GF-2^n arithmetic).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://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