Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Marsh Ray <marsh@extendedsubset.com> Tue, 12 January 2010 17:44 UTC

Return-Path: <marsh@extendedsubset.com>
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 E8BC13A6A7D for <tls@core3.amsl.com>; Tue, 12 Jan 2010 09:44:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 AM4PKhzi-IWF for <tls@core3.amsl.com>; Tue, 12 Jan 2010 09:44:22 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id D42FE3A6821 for <tls@ietf.org>; Tue, 12 Jan 2010 09:44:19 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NUkmu-000GMj-T7; Tue, 12 Jan 2010 17:44:17 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B10AB6076; Tue, 12 Jan 2010 17:44:14 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/OcvYEMiiJLmYTozMO49421ZkSjTXQrBY=
Message-ID: <4B4CB4F0.7080007@extendedsubset.com>
Date: Tue, 12 Jan 2010 11:44:16 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mrex@sap.com
References: <201001121652.o0CGqj3v008312@fs4113.wdf.sap.corp>
In-Reply-To: <201001121652.o0CGqj3v008312@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: DPKemp@missi.ncsc.mil, tls@ietf.org
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
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: Tue, 12 Jan 2010 17:44:24 -0000

Martin Rex wrote:
> 
> The DH_anon ciphersuites have been known and documented to be 
> susceptible to man-in-the-middle attacks for several years. This much
>  more a defect in the design of the DH_anon ciphersuites, not of the 
> TLS protocol itself.  This flaw of those ciphersuites seems to have 
> been so non-interesting, that no-one has tried to do anything about 
> it.

It's a fundamental property of anon-anon connections, not any "defect in
the design of DH".

> Btw. the TLS secure renegotiation spec does _not_ affect the 
> susceptibility of the DH_anon ciphersuite to man-in-the-middle 
> attacks in any way.

Not true.

The RI fix allows you to negotiate an anonymous connection then
renegotiate it to provide certificate authentication which retroactively
covers data exchanged over the previous session.

This is how HTTPS client certificates work, but you know that already.

> Which particular (broken) clients do you have in mind that you think 
> need to be educated with a complete ban on interoperability?

Probably anything implemented with Perl:

http://search.cpan.org/dist/Net_SSLeay.pm/SSLeay.pm
> At this moment the implementation of verify_callback is crippeled in 
> the sense that at any given time there can be only one call back 
> which is shared by all SSL contexts, sessions and connections...
> ...
> KNOWN BUGS AND CAVEATS
> 
> Callback set using SSL_set_verify() does not appear to work. This may
> well be eay problem (e.g. see ssl/ssl_lib.c line 1029). Try using
> SSL_CTX_set_verify() instead and do not be surprised if even this
> stops working in future versions.
> 
> Callback and certificate verification stuff is generally too little
> tested.

Except perhaps things using a higher-level
Net::HTTP("https://dns.name/")-type API.

Take a look at the client example code:
http://search.cpan.org/dist/Net_SSLeay.pm/SSLeay.pm#EXAMPLES
I would say it's vulnerable to this except that it doesn't bother to
check the name on the cert at all. :-)

Show me one tutorial on the web of "Here's how to use this SSL/TLS
library safely" which provides example code that does this correctly. It
may exist, but I haven't found it yet. The fact that I haven't found it
suggests strongly to me that there are plenty of vulnerable client apps
out there.

- Marsh