[HASMAT] wrt handling TLS establishment - comment 41 bug 495115 (bugzilla.mozilla.org)
=JeffH <Jeff.Hodges@KingsMountain.com> Sat, 17 July 2010 05:19 UTC
Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: hasmat@core3.amsl.com
Delivered-To: hasmat@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49BB3A67FC for <hasmat@core3.amsl.com>; Fri, 16 Jul 2010 22:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.554
X-Spam-Level:
X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334]
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 hjOrThmAQjLJ for <hasmat@core3.amsl.com>; Fri, 16 Jul 2010 22:19:11 -0700 (PDT)
Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id F0ECA3A6876 for <hasmat@ietf.org>; Fri, 16 Jul 2010 22:19:10 -0700 (PDT)
Received: (qmail 6324 invoked by uid 0); 17 Jul 2010 05:19:23 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 17 Jul 2010 05:19:23 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=MmVttEg6vCemfAQGephXjyKwNw6DrNDEmn64FWs/pgIhDtoaeNR9advl5GkW6SGiAtLsW64dL3lkePWJZWsnB1NMLmSU58GUVBiw8sOgGYDYHTNUXusW7SDj7lFiePm5;
Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1OZzo2-00021M-V6; Fri, 16 Jul 2010 23:19:23 -0600
Message-ID: <4C413D59.4070304@KingsMountain.com>
Date: Fri, 16 Jul 2010 22:19:21 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Kai Engert <kaie@kuix.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Cc: IETF HASMAT list <hasmat@ietf.org>
Subject: [HASMAT] wrt handling TLS establishment - comment 41 bug 495115 (bugzilla.mozilla.org)
X-BeenThere: hasmat@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HTTP Application Security Minus Authentication and Transport <hasmat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hasmat>
List-Post: <mailto:hasmat@ietf.org>
List-Help: <mailto:hasmat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Jul 2010 05:19:12 -0000
Adam replied: > > Kai proposed: > >> I propose to clarify section 7.3 of the STS document. >> >> It currently says: >> >> "When connecting to a Known STS Server, the UA must terminate the >> connection with no user recourse if there are any errors (e.g. certificate >> errors), whether "warning" or "fatal" or any other error level, with the >> underlying secure transport." >> >> I propose to add another section: >> >> During the initial https connection to a STS server, >> the server certificate verification performed by a UA happens prior to >> receiving the http headers. >> If a user has configured the UA to continue the connection >> despite certificate errors, the UA must ignore any such configuration >> as soon as the server identifies itself as a STS server. >> >> Based on comment 23 in this bug I conclude we agree on this, but I'm worried >> that some readers of the spec might overlook this detail. > > I'm not sure exactly what that means, but a server opting into STS > should trump user configuration to ignore certificate errors. That's > the whole point of the protocol. :) agreed. >> Also, I'm worried that someone might be able to construct an attack based on >> the fact that the initial connection is not yet strict. > > That's correct. The protocol requires a secure initialization step. > If an active network attacker is present during the first connection > to the site, there's nothing the protocol does to help the user. Yes, and that's also why the spec mentions, and Chrome implements, a "preloaded STS list" <http://dev.chromium.org/sts> >> I propose to be more >> restrictive for the initial connection if it involved errors and error >> overrides, and propose to add this: >> >> If an https connection to a not-yet-known-as-STS-server involves >> certificate errors and a user's decision to ignore certificate errors, >> and the server identifies itself as being a STS server, >> then the UA MUST show an error message and >> MUST NOT display the information received from the server. > > This situation is most likely to be a configuration error on the > server where it both has a bogus certificate and is sending the STS > header. It's essential that we don't anoint the server as an STS > server, The spec as currently written (-02) has this base covered in the first para of section "7.1. Strict-Transport-Security Response Header Field Processing" > but either proceeding with the connection or erroring out is > probably fine. However, it is silent on this -- it presently specifies neither option in this particular situation. > I don't think there's a security reason to prefer one > over the other. It's a question of what you think its a better > experience for users and/or developers. I think leaving it silent in the protocol portion of the spec is fine, and that it's another item to add to section "10. UA Implementation Advice". =JeffH
- [HASMAT] wrt handling TLS establishment - comment… =JeffH
- Re: [HASMAT] wrt handling TLS establishment - com… Adam Barth
- Re: [HASMAT] wrt handling TLS establishment - com… Marsh Ray
- Re: [HASMAT] wrt handling TLS establishment - com… Adam Barth
- [HASMAT] wrt handling TLS establishment - comment… =JeffH