On 07/27/2018 01:44 PM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
