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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ