Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Oct 2014 08:50:57 -0700
From: Tim <tim-security@...tinelchicken.org>
To: oss-security@...ts.openwall.com
Subject: Re: attacking hsts through ntp

> It's not entirely a bad idea. You could say "if http header time and
> system time differ severely (> 1 week or something) then don't connect
> to hsts sites".


Well, the premise here is that the attacker has the ability to modify
plaintext traffic between you and your server AND has some way to
perform an HTTPS->HTTP downgrade attack.  That's what HSTS is for,
right?  So if you receive an HSTS header at some point, then an
attacker uses NTP to change your system time, then before you even
connect to the server, you no longer require HTTPS.  So, the attacker
can perform that downgrade attack, at which point any Date header
can't be trusted.  So I don't think a Date header would help at all.

It seems to be a better place to put HSTS-like information is the DNS.
If we ever got to the point where DNSSEC were actually deployed and
not downgradable, then a record of some kind indicating which services
should be "secure" could solve this.  Even when records expire, they
wouldn't be MitM-able since there should be a full chain of trust from
the root servers.  The same problem exists for a variety of protocols,
including all STARTTLS ones, which are often trivially downgradable in
practice.

tim

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ