IETF Logo Mail Archive

[OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTPS

Dick Hardt <dick.hardt@gmail.com> Wed, 27 July 2016 00:15 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC8F12DA6C for <oauth@ietfa.amsl.com>; Tue, 26 Jul 2016 17:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pYUlVaKlf1qy for <oauth@ietfa.amsl.com>; Tue, 26 Jul 2016 17:15:42 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 609A412DA60 for <oauth@ietf.org>; Tue, 26 Jul 2016 17:15:41 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id u186so130699219ita.0 for <oauth@ietf.org>; Tue, 26 Jul 2016 17:15:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=jaZiyoxFri0qWuo/3QTFBukgK4RGDolaGlPDMz2SvJ0=; b=asZkBAp+J+x+wT9j4ftthrIBIZt0RBx3mpyNCmVaewsCoCClq9cGfWqDzZSHirK5SC w3IbkSnxoNaOByhhTwFLL2KSRSCSEvUxmx/EaMt9HQMNjTl0G+ljX+zbClGEmczycFex lTy+Kv7nPNFXhyTs0OCS8U8Vr/BeMWzlC7P8Ali5ph1XKNCaI32+EPdAQvTVikUh2dhq O87763+Nmln2RiPbG1XZ9i/4WuXrhL0s5AnLJrqINfo/6yqOOYrtQUnDQJqw9NUlgtT8 W85KGBwM7kF9F89Rz2m5hrBjWwXsRXLdgRz5cfs4ZLmHkdgNssqq97dzCSLJQFlV/geK bKFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jaZiyoxFri0qWuo/3QTFBukgK4RGDolaGlPDMz2SvJ0=; b=LreN/1P1YkKfhCDe4601gd1PKTPZK0CtK+IVIPw9oEdc/dsShwzlHQer8Wh5+yxvGZ MLK7t/IQDRRyBUQinkO6RA1qZYKhqWpn98n86Ic7i/EE25d0em/fCjW/ufxqV5WCwrtO b0recTAiIJSamvXEEbLUZZWPeLpxaAXdy3shKm0HO1Vv5CanPPoOyvGN0clDWwv24akJ TPCYgOv5cvB39SGPNKMkyddlYzszo+Vpw8BOU1weik3QTCqd0W70LKIEvvhy43LSJ1TG 7TYw1nAZu8k2jmgDdud4ACJzm2bRODns0Zf/TUI8MdxwPCDxg4eD0QuuqCb+ssmPin+6 I5+Q==
X-Gm-Message-State: AEkoousAMunPSE9D532M7Q2ymNeFE9bUwIyPEMRCFZ8DCbPHQT/bVbL1CGbx553EMaQarn+saLRZu92ka5tmgA==
X-Received: by 10.36.26.81 with SMTP id 78mr30692035iti.4.1469578540498; Tue, 26 Jul 2016 17:15:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.42.197 with HTTP; Tue, 26 Jul 2016 17:15:21 -0700 (PDT)
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 26 Jul 2016 17:15:21 -0700
Message-ID: <CAD9ie-uStPcN=6CYf-Hg-=+DP2-Sx=NLtfBB0CZX8eGWwtY93Q@mail.gmail.com>
To: Oauth Wrap Wg <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a1144648ae045a6053892ea84"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/pA8MZhsHKyg735d0B-wGajv_8-Q>
Subject: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTPS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2016 00:15:43 -0000

http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/

Access tokens included as a URL query parameter when accessing a resource
are susceptible to this attack.

Authorization codes are also visible. From what I know, we have not
depended on the confidentiality of the authorization code.

What are the best current practices that we can point people towards to
ensure they are not susceptible to this attack?

-- Dick
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!

v2.23.0 | Report a Bug | By Email