IETF Logo Mail Archive

Re: [websec] Some questions about HSTS

"Steingruebl, Andy" <asteingruebl@paypal-inc.com> Mon, 22 November 2010 16:56 UTC

Return-Path: <asteingruebl@paypal-inc.com>
X-Original-To: websec@core3.amsl.com
Delivered-To: websec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B173A6AE1 for <websec@core3.amsl.com>; Mon, 22 Nov 2010 08:56:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.117
X-Spam-Level:
X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=6.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 ngCbH9gERPiw for <websec@core3.amsl.com>; Mon, 22 Nov 2010 08:56:27 -0800 (PST)
Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id C1B673A6A3E for <websec@ietf.org>; Mon, 22 Nov 2010 08:56:27 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=O/XxIaw/vM6WzvT5PXgzdHSn0/I8HpbnPK93+y3YKvMTPWkbiXCQEtoS 6SB6/QFZgP286hDQ9wtEK9fGZ2OAkFrHmOfN2Iai86IB0KhhXBi4YXu+e 9X73MKYK0Ph8nWD;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1290445044; x=1321981044; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20<asteingruebl@paypal-inc .com>|To:=20Yoav=20Nir=20<ynir@checkpoint.com>,=20"'webse c@ietf.org'"=20<websec@ietf.org>|Date:=20Mon,=2022=20Nov =202010=2009:57:21=20-0700|Subject:=20RE:=20Some=20questi ons=20about=20HSTS|Message-ID:=20<5EE049BA3C6538409BBE6F1 760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com> |References:=20<006FEB08D9C6444AB014105C9AEB133F012E6FCD4 474@il-ex01.ad.checkpoint.com>|In-Reply-To:=20<006FEB08D9 C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint. com>|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=FdGKAsZY+WzjNFZEZEFQq1YjhcjIACJhwaDS2J5KKAE=; b=VU8LkjNKY1JYgKHi7s3Opirvi72LFeLGN2SO5Q2b8V++4NW64vNU6c/R FE2hzvdsZMBRxl0/yVWB2ySQyoMHzU7D+G/RZwlD0SNi4YurWBRJxnOa5 NPgSfwBhj2m4Bmt;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.59,237,1288594800"; d="scan'208";a="163122"
Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 22 Nov 2010 08:57:23 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Mon, 22 Nov 2010 09:57:23 -0700
From: "Steingruebl, Andy" <asteingruebl@paypal-inc.com>
To: Yoav Nir <ynir@checkpoint.com>, "'websec@ietf.org'" <websec@ietf.org>
Date: Mon, 22 Nov 2010 09:57:21 -0700
Thread-Topic: Some questions about HSTS
Thread-Index: AcuKMCvl2Kbio+VwTnaTxClZiBSGNQANX9bQ
Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB18842ED6@DEN-MEXMS-001.corp.ebay.com>
References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com>
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F012E6FCD4474@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Subject: Re: [websec] Some questions about HSTS
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Nov 2010 16:56:29 -0000

> In sections 2.4.1.1, point #9 says:
>    9.  UAs need to prevent users from clicking-through security
>        warnings.  Halting connection attempts in the face of secure
>        transport exceptions is acceptable.
> What exactly are these secure transport exceptions?  Expired certificates?
> Mismatched FQDN? Revoked certificates? Unreachable CRL? Untrusted CA?
> Self-signed?

Anything that would currently pop a browser warning for a user currently.  Browsers differ slightly in how they handle OCSP, etc.  In any case where a browser has already made the policy decision it should show a certificate "error", it must now abort.

> Also, I don't understand why this change is needed. HSTS is supposed to stop
> a very specific attack vector - a user duped into using insecure HTTP over the
> (presumably secure) HTTPS. 
> 
> As it is, HSTS cannot be used by servers with self-signed or corporate
> certificates, for fear that user agents may not allow the user to browse.

That is correct.  I personally believe, as do several of the contributors on this (and I hope I'm not speaking too much out of turn) that self-signed certificate warnings are just a punt, and an easy way for a user to make a bad security decision.  If  you want to support HTTPS, do it with a cert that your browser already trusts.  Anything else is just a recipe for a MiTM attack.  If a host advertises HSTS, it is specifically opting into this scheme, whereby all certificate warnings will cause abort, with no chance to "fool" the user into making the wrong decision.
 
> My second question regards the UA behavior when policy changes. Suppose
> a website has had the HSTS header for a while. The UA has a cache entry with
> a TTL of several more weeks. Now the UA connects to the server (over
> HTTPS) and does not get an HSTS header at all. What now?  If there was a
> header and it was merely changed, the spec says to update the cache entry.
> But if the header is missing altogether, does that mean that the UA should
> delete the cache entry?

I think we can make this clear, but until the client receives a new header, it does not tinker with the cache.  We do say the header should be present in all /most server responses, but the behavior should be that the value persists until set to something else.

- Andy

v2.23.0 | Report a Bug | By Email