[TLS] The Web Security model vs.TLS (was Re: Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard)
Watson Ladd <watsonbladd@gmail.com> Thu, 22 January 2015 16:35 UTC
Return-Path: <watsonbladd@gmail.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 09A621A8AF6 for <tls@ietfa.amsl.com>; Thu, 22 Jan 2015 08:35:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 kZIr6LS8ahxO for <tls@ietfa.amsl.com>; Thu, 22 Jan 2015 08:34:59 -0800 (PST)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8932B1A8877 for <tls@ietf.org>; Thu, 22 Jan 2015 08:34:59 -0800 (PST)
Received: by mail-yh0-f42.google.com with SMTP id a41so1180067yho.1 for <tls@ietf.org>; Thu, 22 Jan 2015 08:34:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=MM0V+UZzY1g/ZPMyXa9DyNlWiU0bxfREG7EYrCIcIYg=; b=RUUouQif9dX+iD2slmGaFt152WBrXy+fg+51d4tKSvmGAoxHGTSywvVlXU3QvQby5y vFV5uG3ESZoerpescm4CsmuJdWAHkWSnwG905pN92rd7CcfxGdKikTjpVDjaUytIPIAm BPl+qW8dj91gO9XtxMZluzxDUFyTbNS9Np5VouIxOuxqHeOUnOVh7vuZTEyX6Mt1P63T IlfvciyLgjbPKi8CllM3vClFGuPBz9BI/GjAAJhY93GXFNv2GPxudlyVrdJCTnWgNAML 23Ef/6YtoVFB19txBmGxUp1GPMv6OMVf5YwD42iJI+sZ7eqEqoiGtLLUihs4UtVbe9F4 kDCA==
MIME-Version: 1.0
X-Received: by 10.236.18.194 with SMTP id l42mr1382813yhl.172.1421944498830; Thu, 22 Jan 2015 08:34:58 -0800 (PST)
Received: by 10.170.115.77 with HTTP; Thu, 22 Jan 2015 08:34:58 -0800 (PST)
Date: Thu, 22 Jan 2015 08:34:58 -0800
Message-ID: <CACsn0c=qGbZhjExyz3Ojvfyo3+Ji_5jwcjBfk_rWv0i6CjZzfg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/r-ktR0XnNdNqRD9DA6EL8vnM90E>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] The Web Security model vs.TLS (was Re: Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard)
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: <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: Thu, 22 Jan 2015 16:35:02 -0000
On Wed, Jan 21, 2015 at 10:11 PM, Martin Rex <mrex@sap.com> wrote: > Bodo Moeller wrote: >> >> If even just a *single* high-value site that you, personally, use does >> support the SCSV, you'll benefit from the SCSV (provided that you're using >> a browser that does a downgrade dance for compatibility with other servers >> and sends the SCSV in downgraded Client Hello messages). > > > I've been looking long and hard, but I'm having difficulties > to see a noticable benefit. OK, a Poodle demonstration of the CBC > padding weakness will no longer work, and maybe a minor fraction of > the script kiddies will spend their time on other activities. > > But for the security of the typical web browser, and I'm not currently > aware of any TLS clients other than web browsers that are doing > downgrade dances. I'm not seeing a measurable benefit from fallback-scsv. > > > The real problem, that is a prerequisite to Browser attacks like Poodle > (and BEAST and CRIME predecessors) are > > 1) a browsers aggressive willingness to execute *ANYTHING* from > *ANYWHERE* that looks like active content > > 2) provisioning of a cross-site-request-forgery (CSRF) facility, > where the browser will share/insert the user's authentication > credentials into *EVERY* GET/POST, irrespective where that > request originates > > For a number of sites, being able to perform crafted GETs and POSTs, > for which the browser will automatically provide/perform the > authentication on behalf of the user, will provide ample room > to cause trouble or damage to the end user. No existing nor future TLS > protocol version and no existing or future TLS cipher suites > can prevent exploitation of such a Browser (mis)feature. Go ahead and exploit this "vulnerability" you are discussing against Paypal, Gmail, Facebook, or Amazon. You won't be able to. While there is much to criticize the web security model for, and plenty of websites are open to CSRF, characterizing the issue as unresolved is wrong: there are standard, effective, protections that are regularly used. Would you use the fact that ASN.1 parsers routinely give RCE as an argument against deployment of TLS, or removing broken ciphers? What about the significant information leaks caused by TLS's disclosure of timing and sizes of data transfers between client and server? Ultimately, if you want to look for excuses, the failure of operating systems to even attempt to provide basic security properties is a problem. Is there any historic or imaginable security issue in TLS, which this logic can't be employed to dispose of? Renegotiation bug: well, it's a consequence of internal layering we can't possibly be expected to know about. Triple handshake: oh, the real problem is not validating every certificate chain you see during the events. The fact that the implementers were never advised of these issues in the first place is conveniently omitted. There is plenty to be said about the languid pace with which the IETF addresses known security issues, the general apathy with which designing for security is greeted in general, and the slow adoption of known solutions, but none of this is an excuse for worsening the problem. I agree that if browsers could use existing extensions as indicators of functioning servers, that would be a better approach that provides security benefit to far more connections. > > A single Poodle attack on a browser requires the attacker to be on-path > between browser and server, for which the attacker intends to recover the > users basic authentication credentials or SSL session cookie through > repeated guessing -- and to perform active attacks on thousands of > network connections between browser and server, creating thousands > of otherwise quite rare TLS MAC errors in the server's logfile. You assume people a) read logs, b) recognize these errors c) connect them to an attack, d) have an action to take and e) take it. This is unlikely. You also assume that being "on-path" is a constraint. It isn't. Sitting in between the user and the website are dozens of poorly secured routers, many with default passwords and hard coded SSH keys. These routers are more than capable of mounting Poodle. > > When (ab)using the browsers CSRF facility directly, rather than for noisy > and boring Poodle, it will be sufficient to piggy-back one single arbitrary > page that the user's browsers happens to load (or can be lured to load). > When properly done, the attack will be indistinguishable from a genuine > action of the user for the server, and be noticable for the user only > by forensic inspection. The browser's CSRF facility may even > allow (ab)use of TLS PSK credentials or TLS client certificates, > a form of credential that can not be attacked/recovered by Poodle. I hadn't thought of that last idea. Should be easy enough to test. > > > Attacking an *arbitrary* page is still quite trivial depressingly often, > because so many sites force their users to use plaintext HTTP for at > least parts of their stuff -- effectively throwing all security > overboard each time. > > lots of online shops. a popular auction site. > > Today I visited the site of a popular video/phone/chat software. > Even when accessing their site via https: the "Sign in" and "Join us" > URLs (at the upper right of all pages of the site) will _force_ the > user through plaintext-HTTP. The link to their Download section > is https, but in the download section, the actual green software > download button, again, forces you through plaintext-HTTP -- OUCH! So what? I don't see why Johnny with the screen door on his house means that the bank shouldn't have a bank vault. There are plenty of outdated Wordpress versions out there: does that mean we shouldn't stop SQL injections? Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin