[openssl-users] request for TLBleed information / non-constant-time vulnerabilities

[Michael R. Hines]

On 07/27/2018 01:44 PM, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Jakob Bohm
>> Sent: Friday, July 27, 2018 11:52
>>
>> And once you have done all that work to protect the cryptographic
>> library, the CPU vulnerability still allows the attacker to observer
>> the non-cryptographic application code that actually creates or uses
>> the plain text (after all, you don't need the plaintext if you are
>> not going to use it, or at least create it).
> An interesting point. The limited bandwidth of most side-channel attacks means that these sorts of secondary secrets aren't usually targeted, but in many cases even small portions of plaintext might be useful. For example, extracting the Request-URIs from HTTP requests, or the RCPT TO lines from SMTP ones, can be useful for traffic and metadata analysis.
>
> We're in an interesting period. Back in the '90s, practitioners like Bruce Schneier were saying that cryptography wasn't the problem - that it had developed to the point where it was too difficult to attack, and there were myriad weaknesses in how cryptography was used, and in the applications that relied on it, and in infrastructure aspects such as PKI, and in the users themselves, so those were the practical targets.
>
> Then we had a couple of decades of ever-more and increasingly effective attacks on cryptosystems, including on the primitives themselves, and attacking the crypto became economically feasible again.
>
> Meanwhile we've had a gradual accumulation of attacks against the physical mechanisms implementing the crypto. These started long ago, of course (Kocher's timing attacks, and TEMPEST before that, and indeed well before the advent of computational cryptography), but they've been picking up speed.
>
> And the issues peripheral to cryptography - applications, infrastructure, users - haven't gone away.
>
> More and better cryptography; more and better attacks against it.

Forgive the stupid question, but what's the takeaway for a cloud 
provider? Do we gather from these points that the entire set of timing 
attacks will never really be known?

What does this confirm (or not confirm) about openssl's vulnerability 
(or knowable status) to TLBleed?

- Michael