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

Marsh Ray <marsh@extendedsubset.com> Tue, 12 January 2010 18:55 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 ED33A3A68B5 for <tls@core3.amsl.com>; Tue, 12 Jan 2010 10:55:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_101=0.6]
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 imCVw9wm9sNr for <tls@core3.amsl.com>; Tue, 12 Jan 2010 10:55:41 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 9A7823A6ABF for <tls@ietf.org>; Tue, 12 Jan 2010 10:55:41 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NUltx-000291-1I; Tue, 12 Jan 2010 18:55:38 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 87D866076; Tue, 12 Jan 2010 18:55:35 +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: U2FsdGVkX18wzz24pJYLQoGmavX1Z+MCEMrWN43dFFE=
Message-ID: <4B4CC5A8.5070508@extendedsubset.com>
Date: Tue, 12 Jan 2010 12:55:36 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mrex@sap.com, "tls >> \"tls@ietf.org\"" <tls@ietf.org>
References: <201001121815.o0CIFr0s013587@fs4113.wdf.sap.corp>
In-Reply-To: <201001121815.o0CIFr0s013587@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 18:55:43 -0000

Martin Rex wrote:
> Marsh Ray wrote:
>> 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".
> 
> It's a defect in the design of the DH_anon ciphersuites which lead to
> the deprecation of these ciphersuites in rfc-5246 (TLSv1.2)-- and if
> you check,

How about you check freaking Wikipedia
http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange

> In the original description, the Diffie–Hellman exchange by itself
> does not provide authentication of the communicating parties and is
> thus vulnerable to a man-in-the-middle attack. A person in the middle
> may establish two distinct Diffie–Hellman key exchanges, one with
> Alice and the other with Bob, effectively masquerading as Alice to
> Bob, and vice versa, allowing the attacker to decrypt (and read or
> store) then re-encrypt the messages passed between them. A method to
> authenticate the communicating parties to each other is generally
> needed to prevent this type of attack.

It's a well-understood and fundamental limitation of all anon-anon
connections, not a "defect" in a particular ciphersuite.

> these ciphersuites are quite difficult to find (being
> enabled by default) in most of the installed base of SSLv3, TLSv1.0
> and TLSv1.1 as well

So they decided to make it difficult for their customers to shoot
themselves in the foot. Probably a wise decision.

> rfc-5246, Appendix A.5 (mid of page 76):
> [...] (Anonymous key exchange may sometimes be acceptable, for 
> example, to support opportunistic encryption when no set-up for 
> authentication is in place, or when TLS is used as part of more 
> complex security protocols that have other means to ensure 
> authentication.)

Did you see that part about "Anonymous key exchange may sometimes be
acceptable" and "other means to ensure authentication"?

Conducting safe renegotiation to elevate the level of authentication on
the connection is such a means.

> While you started off with clients using DH_anon plus renegotiation, 
> you are now quoting clients that completely botch server
> authentication.
> [...]
> What you quote is SSL clients that effectively do not perform server
> endpoint identification at all, not even the weak endpoint 
> identification suggested by rfc-2818 (HTTP over TLS).
> 
> To such clients, an MitM attacker can always perform a complete 
> server impersonation, and secure TLS renegotiation is not going to
> affect that at all.

It is sad, isn't it?

How about this pseudo-code:

String dnsName = "secure.example.com";
IpAddress ip = dnsResolve(dnsName);
Socket s = connectTo(ip);

SSL ssl = connectSSL(s, REQUIRE_SERVER_CERT);

Cert serverCert = ssl->getPeerCert();

if (serverCert->getSubjectName() != dnsName)
    dieWithError("cert mismatch");

exchangeCriticalData(ssl);

This code was secure with SSLv2, but silently becomes vulnerable when
used with SSLv3+ and an upatched stack that handles renegotiation
transparently for the app (most of them).

Patching both the client and server to support RI makes this application
code secure again. It also re-enables interesting new possibilities.

not vulnerable -> vulnerable -> not vulnerable
   SSLv2            SSLv3+        SSLv3+RI

I believe this code is representative of many applications.

I don't know how to put it more simply than that.

>> 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.

Still waiting.

> Please do _not_ mislead others about what secure TLS renegotiation 
> addresses and fixes, and what it leaves untouched and in whatever 
> miserable situation that it has always been.

Likewise.

- Marsh