Re: [TLS] New version of Multiple OCSP mode of Certificate Status

Martin Rex <mrex@sap.com> Wed, 04 August 2010 18:26 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 D6B7A3A6845; Wed, 4 Aug 2010 11:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.621
X-Spam-Level:
X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[AWL=0.628, 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 xwyrAPWHYkqi; Wed, 4 Aug 2010 11:26:07 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B6D603A680A; Wed, 4 Aug 2010 11:26:06 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o74IQZjd015243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Aug 2010 20:26:35 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201008041826.o74IQY9c006745@fs4113.wdf.sap.corp>
To: agl@imperialviolet.org
Date: Wed, 04 Aug 2010 20:26:34 +0200
In-Reply-To: <AANLkTik-p__N7mCE2ARwV=C3GD99ahOjZEYFR84zUTiG@mail.gmail.com> from "Adam Langley" at Aug 4, 10 02:01:54 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: pkix@ietf.org, tls@ietf.org
Subject: Re: [TLS] New version of Multiple OCSP mode of Certificate Status
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: Wed, 04 Aug 2010 18:26:08 -0000

Adam Langley wrote:
> 
> That seems a little hyperbolic. Accessing completely unverified URLs
> is something that browsers do for every single web page.

Not really.

Example scenario:

newly booted PC. User logs on, starts the web Browser (about:blank homepage)
and navigates to the HTTPS-url for his online banking.  If HTTPS works
as designed, this should be a safe operation--any "unsafe" content
that the browser would be allowed to serve/access with the consent
of the user is the content served by the online bankings site.

Now if the browser performs AIA retrieval for unverified server
certs, then this scenario is suddenly completely unprotected against
active attacks where the attacker serves a manufactured server
certificate with crafted AIA (but matching the server identity
of the online banking account in the CN= or dNSName SAN.


Essentially, that "safe mode of operation" for your web browser is gone.

-Martin