Re: [TLS] [oss-security] CVE-2009-3555 for TLS renegotiation MITM attacks

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 08 November 2009 08:42 UTC

Return-Path: <pgut001@wintermute01.cs.auckland.ac.nz>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A1728C0EF for <tls@core3.amsl.com>; Sun, 8 Nov 2009 00:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.346
X-Spam-Level:
X-Spam-Status: No, score=-4.346 tagged_above=-999 required=5 tests=[AWL=-1.747, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxssn2-BUxGG for <tls@core3.amsl.com>; Sun, 8 Nov 2009 00:42:36 -0800 (PST)
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 562973A689B for <tls@ietf.org>; Sun, 8 Nov 2009 00:42:34 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 143F49CEF7; Sun, 8 Nov 2009 21:42:45 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No8hGFkY4Jmb; Sun, 8 Nov 2009 21:42:44 +1300 (NZDT)
Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B2ECD9CEEF; Sun, 8 Nov 2009 21:42:38 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1N73M6-0004E8-Gw; Sun, 08 Nov 2009 21:42:38 +1300
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1N73M6-0002z0-5Y; Sun, 08 Nov 2009 21:42:38 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: marsh@extendedsubset.com, rea-sec@codelabs.ru
In-Reply-To: <4AF59F32.1030408@extendedsubset.com>
Message-Id: <E1N73M6-0002z0-5Y@wintermute01.cs.auckland.ac.nz>
Sender: pgut001 <pgut001@wintermute01.cs.auckland.ac.nz>
Date: Sun, 08 Nov 2009 21:42:38 +1300
Cc: oss-security@lists.openwall.com, tls@ietf.org, coley@linus.mitre.org
Subject: Re: [TLS] [oss-security] CVE-2009-3555 for TLS renegotiation MITM attacks
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Sun, 08 Nov 2009 08:42:37 -0000

Marsh Ray <marsh@extendedsubset.com> writes:

>For one thing, browsers' behavior of allowing automatic certificate sending
>is suspect and should be reconsidered.

It's not actually safe to reconsider this because many servers (including some
at very large sites) always request client auth, often without the site admins
being aware of this or knowing how to disable it.  I became aware of this when
I changed my code to add a roadblock until the user explicitly responded to a
client cert request, leading to many complaints about sites that formerly
"worked" and now didn't (I've found all sorts of other broken behaviour around
client-auth, for example servers that send a list of 150-odd CAs, every one
they know of, as an indication of who they'll accept certs from, and other
strangeness).  Disabling the automatic sending of client certs would therefore
obviously break, to the client, a number of (what I consider) broken servers.
What my code currently does is:

  if( cert request received )
      if( client cert present )
          send cert;
      else
          send no-cert alert;

This isn't totally safe though because there's no "tell user to make their
cert available" option if they haven't pre-emptively done so, it "works"
mostly because the extreme rarity of client cert use and stereotyped behaviour
of existing clients hides all the glitches in implementations.

Peter.