Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

From: Hubert Kario <[email-masked]>
Date: Wed, 03 Jan 2018 12:45:14 +0100

On Thursday, 14 December 2017 23:20:54 CET Colm MacCárthaigh wrote:
> Based on our experiences with all of this over the last few weeks, I'd like
> to summarize and throw out a few suggestions for making TLS stacks more
> defensive and robust against problems of this class. One or two may be even
> worth considering as small additions to the forthcoming TLS RFC, and I'd
> love to get feedback on that.
> 

> *Second: hide all alerts in suspicious error cases*
> Next, when the handshake does fail, we do two non-standard things. The
> first is that we don't return an alert message, we just close the
> connection. 
> 
> *Third: mask timing side-channels with a massive delay*
> The second non-standard thing we do is that in all error cases, s2n behaves
> as if something suspicious is going on and in case timing is involved, we
> add a random delay. It's well known that random delays are only partially
> effective against timing attacks, but we add a very very big one. We wait a
> random amount of time between a minimum of 10 seconds, and a maximum of 30
> seconds.

Note that both of those things only _possibly_ frustrate attackers while they 
definitely frustrate researchers trying to characterise your implementation as 
vulnerable or not. In effect making it seem secure while in reality it may not 
be.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Wed, 03 Jan 2018 12:51:53 +0100

On Friday, 15 December 2017 19:07:16 CET Eric Rescorla wrote:
> I'm not quite following how this helps. It's true that if SHA-256 is
> broken, we're in serious trouble, but that's largely because of the fact
> that that's what people's certificates have, so clients really can't refuse
> to support SHA-256 certificates. So, how does adding new algorithms help?
> (That's why I would argue that the existing SHA-384 support doesn't help).
> 

we are in the process of standardising Ed25519 for X.509 and TLS which doesn't 
use SHA-256 or SHA-384, so the fact that TLS will still use SHA-256 PRF with 
such certificates is a liability.

> On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara <[email-masked]>
> 
> wrote:
> > On Fri, Dec 15, 2017 at 02:57:33PM +0000, Andrei Popov wrote:
> > > From: TLS [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
> > > 
> > > > Even nastier dependency: SHA-2. If that breaks, currently both TLS
> > > > 1.2 and 1.3 break. There are no alternatives defined.
> > > 
> > > Here's an attempt to define a SHA-2 alternative:
> > https://tools.ietf.org/html/draft-wconner-blake2sigs-01
> > 
> > Also would need TLS ciphersuite codepoints with alternative handshake
> > hash algorithms.
> > 
> > 
> > -Ilari
> > 
> > _______________________________________________
> > TLS mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tls

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 Jan 2018 09:23:03 -0800

> vulnerable or not. In effect making it seem secure while in reality it may

No, I strongly disagree here. Firstly, frustrating attackers is a good
definition of what the goal of security is. Some times increasing costs for
attackers does come at the cost of making things harder to analyze or
debug, but we shouldn't make the latter easier at the expense of the
former.

In practical terms; it's not that big a deal. For the purposes of research
it's usually easy to remove the delays or masking - I did it myself
recently to test various ROBOT detection scripts; turning off the delay was
a one line code patch and I was up and running, it hardly hindered research
at all.

Similarly, we've already had to reduce the granularity of TLS alerts, so
TLS experts and analysts are used to having to dive into code,
step-throughs, to debug some kinds of problems. I can't how many hours I've
spent walking through why a big opaque blob didn't precisely match another
big opaque blob. We could make all of that easier by logging and alerting
all sorts of intermediate states, but it would be a terrible mistake
because it would leak so much information to attackers.

As for delays possibly making an attackers job harder; I'm working on some
more firm, signal-analysis based, grounding for the approach as the impact
varies depending on the amount of noise present, as well as the original
distribution of measurement due to ordinary scheduling and network jitter,
but the approach certainly makes timing attacks take millions to trillions
more attempts, and can push real-world timing leaks well into unexploitable
in the real world.

-- 
Colm

---

From: Hubert Kario <[email-masked]>
Date: Thu, 4 Jan 2018 07:17:30 -0500 (EST)

----- Original Message ----- 

> From: "Colm MacCárthaigh" <[email-masked]>
> To: "Hubert Kario" <[email-masked]>
> Cc: [email-masked]
> Sent: Wednesday, January 3, 2018 6:23:03 PM
> Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in
> general, and what we can do in TLS

> On Wed, Jan 3, 2018 at 3:45 AM, Hubert Kario < [email-masked] > wrote:

> attackers does come at the cost of making things harder to analyze or debug,
> but we shouldn't make the latter easier at the expense of the former.

No, the goal of security is to stop attacks from being successful, not make them harder. Making attack harder is security through obscurity. Something that definitely doesn't work for open source software. 

> it's usually easy to remove the delays or masking - I did it myself recently
> to test various ROBOT detection scripts; turning off the delay was a one
> line code patch and I was up and running, it hardly hindered research at
> all.

now multiply that by 20 different libraries and as a researcher you will give up on the third one. Or rather on the first one as the 18.5 other do send alerts and implement RFC recommended behavior. 

> Similarly, we've already had to reduce the granularity of TLS alerts, so TLS
> experts and analysts are used to having to dive into code, step-throughs, to
> debug some kinds of problems. I can't how many hours I've spent walking
> through why a big opaque blob didn't precisely match another big opaque
> blob. We could make all of that easier by logging and alerting all sorts of
> intermediate states, but it would be a terrible mistake because it would
> leak so much information to attackers.

"the dose makes the poison". Yes, we need to strike a balance between enough and not enough information. One thing is for sure, the correct solution does not lie in the extremes. 

> more attempts, and can push real-world timing leaks well into unexploitable

honestly, I consider this approach completely misguided. If you are OK with tying up a socket for 30 seconds, simply start a timer once you get the original client hello (or the first message of second flight, in TLS 1.2), close the socket if the handshake is not successful in 30 seconds. In case of errors, send nothing, let it timeout. The only reason why this approach to constant time error handling is not used is because most people are not ok with tying up resources for so long. 

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [email-masked]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 4 Jan 2018 11:01:03 -0800

On Thu, Jan 4, 2018 at 4:17 AM, Hubert Kario <[email-masked]> wrote:

> debug,
> No, the goal of security is to stop attacks from being successful, not
> make them harder. Making attack harder is security through obscurity.
> Something that definitely doesn't work for open source software.
>

Unless you're shipping one-time-pads around, cryptography is founded on
making successful attacks highly improbable, but not impossible. There are
measures of likelihood of key and plaintext recovery for all of the
established algorithms. The delay approach is no different, and risk can be
expressed in mathematical ways.  The numbers are lower, for sure, delays
can add a security factor of maybe up to 2^40, but that's still very very
effective and unlike encryption or hashes, do not have to withstand
longterm attacks.

This bears repeating: attempting to make OpenSSL rigorously constant time
made it *less* secure. The LuckyMinus20 bug was much worse than the Lucky13
bug the code was trying to fix. It would have been better to leave it
un-patched (at least for TLS, maybe not DTLS). A delay in the error case on
the other hand, would have made either issue un-exploitable in the real
world. Evaluating that trade-off takes a lots of "grey area" analysis
though; one has to have a sense of judgement for how much risk a complex
code change is "worth", being mindful that complex code changes come with
their own risks.

honestly, I consider this approach completely misguided. If you are OK with
> tying up a socket for 30 seconds, simply start a timer once you get the
> original client hello (or the first message of second flight, in TLS 1.2),
> close the socket if the handshake is not successful in 30 seconds. In case
> of errors, send nothing, let it timeout. The only reason why this approach
> to constant time error handling is not used is because most people are not
> ok with tying up resources for so long.
>

This is real code we use in production; thankfully errors are very
uncommon, but connections also cost very little, in part due to work done
for DDOS and trickle attacks, a different kind of security problem.

Delaying to a fixed interval is a great approach, and emulates how clocking
protects hardware implementations, but I haven't yet been able to succeed
in making it reliable. It's easy to start a timer when the connection is
accepted and to trigger the error 30 seconds after that, but it's hard to
rule out that a leaky timing side-channel may influence the subsequent
timing of the interrupt or scheduler systems and hence exactly when the
trigger happens. If it does influence it, then a relatively clear signal
shows up again, just offset by 30 seconds, which is no use.

-- 
Colm

---

From: Hubert Kario <[email-masked]>
Date: Mon, 08 Jan 2018 13:29:26 +0100

On Thursday, 4 January 2018 20:01:03 CET Colm MacCárthaigh wrote:
> > > definition of what the goal of security is. Some times increasing costs
> > 
> > for
> > 

except that what we call "sufficiently hard plaintext recovery" is over triple 
of the security margin you're proposing as a workaround here

2^40 is doable on a smartphone, now
2^120 is not doable on a supercomputer, and won't be for a very long time
 
> made it *less* secure.

yes, on one specific hardware type, because of a bug in implementation

I really hope you're not suggesting "we shouldn't ever build bridges because 
this one collapsed"...

also, for how long was it *less* secure? and for how long was it vulnerable to 
Lucky13?

> The LuckyMinus20 bug was much worse than the Lucky13
> world. 

I'm sorry, you're saying that you're able to prove a negative?
Or to put it other way: "Anyone can invent a security system that he himself 
cannot break."

> Evaluating that trade-off takes a lots of "grey area" analysis

"we shouldn't fix it because it's not completely broken" is how we get 
million+ strong botnets of systems that never got updated

and any issue with known exploit needs to be fixed
 
> shows up again, just offset by 30 seconds, which is no use.

*if*

in other words, this solution _may_ leak information (something which you can 
actually test), or the other solution that _does_ leak information, just 
slowly so it's "acceptable risk"
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 8 Jan 2018 09:45:32 -0600

> 2^120 is not doable on a supercomputer, and won't be for a very long time

This isn't how these kinds of attacks work. 2^40 would be small for
something that could be attacked in parallel by a very large computing
system. But it's an absolutely massive difficulty factor against a live
on-line attack. Can you propose a credible mechanism where an attacker
would be able to mount say billions (to use the low end) of repeated
connections, without detection? And that's before they wean the signal out.
And since the delay can't be avoided, the attack also costs thousands of
years of attacker-controlled computer time.  I have much much more
confidence in that simple kind of defense giving me real-world security
than I do in my code being absolutely perfect, which I've never achieved.

I'm being stubborn and replying here because I want to argue against a
common set of biases I've seen that I think are harmful to real-world
security, Making attacks billions to trillions of times harder absolutely
does protect real-world users, and we shouldn't be biasing simply for what
we think the research community will take seriously or not scoff at, but
for what will actually protect users.  Those aren't the same.

I'll give another example: over the last few years we have significantly
*regressed* on the real-world security of TLS by moving to AES-GCM and
ChaCha20. Both of their cipher suites leak the exact content-length and
make content-fingerprinting attacks far easier than they were previously
(CBC blocks made this kind attack exponentially more expensive). The
current state is that passive tappers with relatively unsophisticated
databases can de-cloak a high percent of HTTPS connections. This
compromises secrecy, the main user benefit of TLS. That is staggering me,
but it's also an uninteresting attack to the research community, it's long
known about and isn't going to result in much publication or research
grants.

> also, for how long was it *less* secure? and for how long was it

I'm saying that trade-offs are complicated and that constant-time "rigor"
isn't worth it sometimes. Adding ~500 lines of hard-to-follow
hard-to-maintain code with no systematic way to confirm that it stays
correct was a mistake and it led to a worse bug. Other implementations
chose more simple approaches; code-balancing, that were
close-to-constant-time but not rigorously so.  I think the latter was
ultimately smarter, all code is dangerous because bugs can be lurking in
its midst, and those bugs can be really really serious like memory
disclosure and remote execution, so leaning towards simple and easy to
follow should be heavily weighted.  So when we see the next bug like
Lucky13, which was un-exploitable against TLS, but still publishable and
research-worthy, we should lean towards simpler fixes rather than complex
ones, while also just abandoning whatever algorithm is effected and
replacing it.

> slowly so it's "acceptable risk"

Sorry, I'll try to be more clear: A leak in a fixed-interval delay would be
catastrophic, because it will result in a very clean signal, merely offset
by the delay. A leak in a random-interval delay will still benefit from the
random distribution and require many samples.

-- 
Colm