Re: [websec] HSTS: Infinite max-age to address NTP spoofing attack?

Yoav Nir <> Mon, 10 November 2014 20:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2F73A1ACDB7 for <>; Mon, 10 Nov 2014 12:10:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Status: No, score=0.3 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, MANGLED_BACK=2.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XeozrhT8V5PV for <>; Mon, 10 Nov 2014 12:10:03 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9ABDD1A9073 for <>; Mon, 10 Nov 2014 12:09:46 -0800 (PST)
Received: by with SMTP id h11so11811415wiw.9 for <>; Mon, 10 Nov 2014 12:09:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ALXfoh5yuBPdABtkMlILiZZ8c8VWE31aqRINlpDVnw8=; b=d1gG022d5ve4cxJJBqKgXhqrtUk8YH28/0o5JOEx4iv18r4VZ5nepqepoPgPz2BhTZ kBkz7Q5Bb1uml6lCmFrqT5q6EgnAS797h2sqsx0qKr3heMIMafOLhgho7JPs7OjdNMx2 zaRIjX5rLWsqRQ8ToRFRaT+zcKG2r8adlVrMTL7CXSsVU1KP/+qMqwBBwcJVxVTmhahm oWAX2BQ4ZBrfxwJlaaqOc4hi7tf/9N7ZmgnTQFesANrabmqMoGGfdzD8DECJvkUONKkH Z5DBQYBnFhuIk7r2XKuagt0kehAGZrHDB1aYDV8mhiy+pe1xYbfBkDnJELiUV24iiYEy OBUQ==
X-Received: by with SMTP id gm19mr46613944wjc.51.1415650184483; Mon, 10 Nov 2014 12:09:44 -0800 (PST)
Received: from ( [2001:67c:370:160:143:5d87:602e:7faf]) by with ESMTPSA id b6sm14667448wiy.22.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 12:09:43 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 10 Nov 2014 10:09:39 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <BAY180-W65945DCD6DB8531AB08F2BFF850@phx.gbl> <20141107161452.2b834f23@pc> <> <>
To: Tobias Gondrom <>
X-Mailer: Apple Mail (2.1990.1)
Subject: Re: [websec] HSTS: Infinite max-age to address NTP spoofing attack?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Nov 2014 20:10:06 -0000

> On Nov 10, 2014, at 9:49 AM, Tobias Gondrom <>; wrote:
> On 10/11/14 09:03, Hodges, Jeff wrote:
>> On 11/7/14, 7:14 AM, "Hanno Böck" <>; wrote:
>>> But I am pretty sure that no matter what, the underlying cause needs to
>>> be fixed.
>> Strongly agreed.
>>> A reliable time plays a role in a number of cases in TLS.
>>> HPKP is basically vulnerable to the same kind of attack. Certificate
>>> validity times/expirations are vulnerable.
>> Yes, there's a plethora of protocols that contain timestampes of one sort
>> or another. Thus to some degree or another, they rely upo systems' time,
>> and if that time is corrupted by an attacker then the system and its users
>> may be in trouble.
>> I don't think it's feasible, or in all or most cases a good design, to go
>> back and 'patch' those protocols to try to guard against NTP-based attacks
>> (as one example of how system time may be corrupted), rather, platforms
>> should (as AGL noted in a earlier thread "NTP vs. HSTS" on [1]) "fix the
>> clock" (I.e. Address NTP and other clock vulns).
> <wg chair hat= off>
> I agree with Jeff. It would better to aim fixing the clock issue (or the relying on fake clocks), than trying to give "infinite" to all kinds of protocol parameters.
> Tobias


And DKG has mentioned not wanting to create a permanent foot-gun. That is right, but I don’t think telling management “our website is bricked forever” is any better than telling them that “our website is bricked for two years”.

Besides, if you move so far in the future that a 1-year or 2-year HSTS header expires, you’re going to see expired certificates anyway.