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

Hubert Kario <hkario@redhat.com> Thu, 04 January 2018 12:17 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E24127275 for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 04:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.931
X-Spam-Level:
X-Spam-Status: No, score=-6.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHG5GDKYB8xA for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 04:17:30 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71321127010 for <tls@ietf.org>; Thu, 4 Jan 2018 04:17:30 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2F3455B2F4; Thu, 4 Jan 2018 12:17:30 +0000 (UTC)
Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 26BB3608EE; Thu, 4 Jan 2018 12:17:30 +0000 (UTC)
Received: from zmail21.collab.prod.int.phx2.redhat.com (zmail21.collab.prod.int.phx2.redhat.com [10.5.83.24]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 1EDE5410AE; Thu, 4 Jan 2018 12:17:30 +0000 (UTC)
Date: Thu, 4 Jan 2018 07:17:30 -0500 (EST)
From: Hubert Kario <hkario@redhat.com>
To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= <colm@allcosts.net>
Cc: tls@ietf.org
Message-ID: <323483915.3215386.1515068250003.JavaMail.zimbra@redhat.com>
In-Reply-To: <CAAF6GDcQY0n6e+dfB-JX4=EpM461k-DtuXt0BU9zpkJWeH+XZw@mail.gmail.com>
References: <CAAF6GDeeo2xjv1Xu7SFXVZ_zM=XUVJHT=eqH4_-G3+4UHsfvgg@mail.gmail.com> <3291250.UCJXXru3mW@pintsize.usersys.redhat.com> <CAAF6GDcQY0n6e+dfB-JX4=EpM461k-DtuXt0BU9zpkJWeH+XZw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [78.102.32.78, 10.4.196.25, 10.4.195.10]
Thread-Topic: A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS
Thread-Index: nJGMiP3BxD9y3Z4mW0dHtDzRFUOVdA==
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 04 Jan 2018 12:17:30 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OCDqFZzkItmuu2DL_OLsiLF78js>
Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jan 2018 12:17:32 -0000

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

> From: "Colm MacCárthaigh" <colm@allcosts.net>;
> To: "Hubert Kario" <hkario@redhat.com>;
> Cc: tls@ietf.org
> 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 < hkario@redhat.com > 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: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic