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

[Michael R. Hines]

By the way, these responses have been very thoughtful. I just wanted to 
say thanks!

/*
  * Michael R. Hines
  * Staff Engineer, DigitalOcean.
  */

On 07/28/2018 08:44 AM, Michael Wojcik wrote:
>> From: Michael R. Hines [mailto:mrhines at digitalocean.com]
>> Sent: Friday, July 27, 2018 19:06
>>
>> Forgive the stupid question, but what's the takeaway for a cloud
>> provider?
> Well, in general, it's probably the commonplace that security is a process, not a product. There will always be new attacks of some sort.
>
>> Do we gather from these points that the entire set of timing
>> attacks will never really be known?
> That's probably a safe assumption, particularly if "timing attacks" is defined broadly. (There was a famous timing attack against the TENEX logon mechanism back in the 1970s; does that count?)
>
> Even for computational timing attacks (like Kocher's) and microarchitectural timing attacks (like TLBleed), it would be impossible to prove you had the complete set unless the entire system was formally verified and the implementation could somehow be demonstrated to conform to the forrmal specification under all conditions.
>
> In theory you can increase the noise on the channel to the point where it's no longer economical. Research on that goes back to at least the early 1990s. The problems, of course, are making sure you comprehensively inject noise into all the known channels, and finding users willing to pay the cost - increased noise means reduced efficiency. We see this trade-off in all sorts of side-channel attacks; in the cloud, for example, you have the various results showing security issues with memory deduplication.
>
> For cloud computing, we've had at least a decade of research into this issue (see e.g. Ristenpart et al, "Hey, you, get off my cloud", published nine years ago so work presumably started no later than 2008). And it's still a problem, which means it's complicated and likely to be durable.
>
>> What does this confirm (or not confirm) about openssl's vulnerability
>> (or knowable status) to TLBleed?
> Specifically? Not much. It goes more to the general principle that systems leak information as they do work. Ultimately it comes down to thermodynamics, and you never bet against thermodynamics.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>