Re: [TLS] TLS and KCI vulnerable handshakes

Clemens Hlauschek <clemens.hlauschek@rise-world.com> Tue, 11 August 2015 23:15 UTC

Return-Path: <clemens.hlauschek@rise-world.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E4B1B2AAA for <tls@ietfa.amsl.com>; Tue, 11 Aug 2015 16:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 HmsWjmLbC95M for <tls@ietfa.amsl.com>; Tue, 11 Aug 2015 16:15:51 -0700 (PDT)
Received: from mail01.rise-w.com (mail01.rise-w.com [88.116.105.226]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F6C1B2A95 for <tls@ietf.org>; Tue, 11 Aug 2015 16:15:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail01.rise-w.com (Postfix) with ESMTP id E85BF40E43C; Wed, 12 Aug 2015 01:15:48 +0200 (CEST)
Received: from [10.199.13.81] (unknown [12.238.56.12]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rise-world.com (Postfix) with ESMTPSA id D81AB40E431; Wed, 12 Aug 2015 01:15:43 +0200 (CEST)
Message-ID: <55CA821B.9090101@rise-world.com>
Date: Tue, 11 Aug 2015 19:15:39 -0400
From: Clemens Hlauschek <clemens.hlauschek@rise-world.com>
User-Agent: mutt 1.5.23 (Plan 9)
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "tls@ietf.org" <tls@ietf.org>
References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/tDRwsPLmq4dqSRqCBib8qSeRvlw>
X-Mailman-Approved-At: Mon, 17 Aug 2015 17:43:04 -0700
Subject: Re: [TLS] TLS and KCI vulnerable handshakes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 11 Aug 2015 23:15:54 -0000


On 08/11/2015 02:05 PM, Peter Gutmann wrote:
> Clemens Hlauschek <clemens.hlauschek@rise-world.com> writes:
> 
>> I published a paper today on KCI-attacks in TLS. This might be of interest to
>> the TLS WG.
>>
>> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
> 
> Some comments on this, it looks like it requires a "cert with static (EC)DH
> key" in order to work, which would mean an X9.42 cert.  Since no (public) CA
> that I know of can handle or issue such certs, this probably provides a
> reasonable amount of defence against this attack...



Thanks for the critical reading. Actually, your point is touched upon in
the paper. Instead of an ECDH certificate, an ECDSA certificate can be
used by the attacker. The case for DH/DSS is different, and your point
is valid for this latter case. I am working on a video showcasing the
attack (Safari <-> Facebook), but if you decide that you still would not
trust our claims made in the paper, it would be trivial to reproduce the
attack: our MitM proof-of-concept implementation was realized with less
than 10 patched lines of the openssl/stunnel codebase.


See also RFC 4492:
"Note that there is no structural difference between ECDH and ECDSA
keys.  A certificate issuer may use X.509 v3 keyUsage and
extendedKeyUsage extensions to restrict the use of an ECC public key
to certain computations"

> 
> In terms of the suggested countermeasures:
> 
>> Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and
>> disable specifically the KeyAgreement flag
> 
> Since the keyUsage flags are widely ignored by implementations, this won't
> provide the protection that the text implies.
> 


In case of the vulnerable Safari / SecureTransport / Mac OS X clients,
it does make a difference, so having correct X509 KeyUsage settings is
the best (and only sensible for servers supporting ECDSA) recommendation
for server-side mitigation, from our perspective. The facebook.com
security teams very quickly implemented that change. While it is
certainly true that keyUsage flags are ignored by many implementations
(this is also mentioned in the paper), checking (it is ambiguous
according to the TLS specs whether it is mandatory for ECDH, but it is
mandatory for DH if the KeyUsage extension is present) seems to have
become more widespread recently.


Best,
Clemens