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

[Hubert Kario <[e-mail]>]

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