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

Hanno Böck <> Fri, 07 November 2014 15:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 862311A8744 for <>; Fri, 7 Nov 2014 07:15:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.402
X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7ihoBQy7G__P for <>; Fri, 7 Nov 2014 07:14:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F98B1A86DE for <>; Fri, 7 Nov 2014 07:14:55 -0800 (PST)
Received: from pc ( [::ffff:]) (AUTH: LOGIN, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by with ESMTPSA; Fri, 07 Nov 2014 16:14:53 +0100 id 0000000000000027.00000000545CE1ED.00007C4A
Date: Fri, 7 Nov 2014 16:14:52 +0100
From: Hanno =?ISO-8859-1?B?QvZjaw==?= <>
Message-ID: <20141107161452.2b834f23@pc>
In-Reply-To: <BAY180-W65945DCD6DB8531AB08F2BFF850@phx.gbl>
References: <BAY180-W65945DCD6DB8531AB08F2BFF850@phx.gbl>
X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary=""
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: Fri, 07 Nov 2014 15:15:03 -0000

I'm not sure what I think about an infinite HSTS timespan.

But I am pretty sure that no matter what, the underlying cause needs to
be fixed. 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.

After I was in the talk at BH I changed my systems to use tlsdated
instead of ntpd. That's the thing that should happen: We need to make
our time sources more reliable.

I was thinking about an idea I had during the talk: Maybe browsers
should add some time consistency checks? Basically two things would be
1. check for sane time on startup. Browsers check for updates,
CRLsets and other things anyway. They could just use the tls timestamp
of these requests and throw a warning if they differ significantly (I
don't want to nag users that don't set their time second-precise, but a
diff of more a day could give a warning)
2. check for consistency while running. There could be periodical
checks and if the time does large jumps also throw a warning.

Hanno Böck