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

[Hubert Kario <[e-mail]>]

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

> From: "Colm MacCárthaigh" <[e-mail]>
> To: "Hubert Kario" <[e-mail]>
> Cc: [e-mail]
> 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 < [e-mail] > wrote:
> > > *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.
> 

> 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.

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. 

> 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.

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. 

> 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.

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: [e-mail]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic