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

Martin Rex <mrex@sap.com> Tue, 12 January 2010 18:16 UTC

Return-Path: <mrex@sap.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 92F163A67FD for <tls@core3.amsl.com>; Tue, 12 Jan 2010 10:16:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.199
X-Spam-Level:
X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 RxtgG-09+Obo for <tls@core3.amsl.com>; Tue, 12 Jan 2010 10:16:01 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 285E43A6808 for <tls@ietf.org>; Tue, 12 Jan 2010 10:16:00 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o0CIFsJO024982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 19:15:55 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001121815.o0CIFr0s013587@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Tue, 12 Jan 2010 19:15:53 +0100 (MET)
In-Reply-To: <4B4CB4F0.7080007@extendedsubset.com> from "Marsh Ray" at Jan 12, 10 11:44:16 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
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
Reply-To: mrex@sap.com
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:16:02 -0000

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, 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:

rfc-5246, Appendix A.5 (mid of page 76):

   The following cipher suites are used for completely anonymous
   Diffie-Hellman communications in which neither party is
   authenticated.  Note that this mode is vulnerable to man-in-the-
   middle attacks.  Using this mode therefore is of limited use: These
   cipher suites MUST NOT be used by TLS 1.2 implementations unless the
   application layer has specifically requested to allow anonymous key
   exchange.  (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.)


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

While you started off with clients using DH_anon plus renegotiation,
you are now quoting clients that completely botch server authentication.


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

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.  Unless the core TLS protocol offers
some kind of channel bindings (which the current spec doesn't),
there is no need to splice TLS sessions.  A simple traditional MitM 
is perfectly sufficient to attack all scenarios that do not use
SSL client certs (which is the vast majority), but either
basic authentication, form-based authentication, cookie-based
authentication or "negotiate" authentication (NTLM or Kerberos tokens).


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.

-Martin