[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141017155057.GK1844@sentinelchicken.org>
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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
