Re: [TLS] debugging tools [was: Industry Concerns about TLS 1.3]

Florian Weimer <fw@deneb.enyo.de> Wed, 05 October 2016 18:16 UTC

Return-Path: <fw@deneb.enyo.de>
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 62D7B1293FC for <tls@ietfa.amsl.com>; Wed, 5 Oct 2016 11:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 1xPVmJIr_QZr for <tls@ietfa.amsl.com>; Wed, 5 Oct 2016 11:16:31 -0700 (PDT)
Received: from albireo.enyo.de (albireo.enyo.de [5.158.152.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20881293F8 for <tls@ietf.org>; Wed, 5 Oct 2016 11:16:31 -0700 (PDT)
Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1brqjz-0003jZ-D5; Wed, 05 Oct 2016 20:16:27 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.84_2) (envelope-from <fw@deneb.enyo.de>) id 1brqjz-0004rv-9H; Wed, 05 Oct 2016 20:16:27 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: Hubert Kario <hkario@redhat.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <1474627597.2773.14.camel@redhat.com> <c1c32cd8-98df-7d51-bcce-d217bbcd5e74@cs.tcd.ie> <1948820.OppVitlkjc@pintsize.usersys.redhat.com>
Date: Wed, 05 Oct 2016 20:16:27 +0200
In-Reply-To: <1948820.OppVitlkjc@pintsize.usersys.redhat.com> (Hubert Kario's message of "Fri, 23 Sep 2016 15:41:14 +0200")
Message-ID: <87h98q64qs.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5JNhznmJhU6cKbQkjavENR-vSsQ>
Cc: tls@ietf.org
Subject: Re: [TLS] debugging tools [was: Industry Concerns about TLS 1.3]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 05 Oct 2016 18:16:33 -0000

* Hubert Kario:

> those secret keys are on the client machines and they will stay on client 
> machines
>
> making it hard to extract master key from process memory is just security 
> through obscurity, not something that will stop a determined attacker

I think extracting the master key is probably not what you want to do
anyway, just adding Systemtap probes to get cleartext copies
(preferably along with connection detail information) should be
sufficient.