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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
