If using a bridge: your bridge can replay an old (one week old max.) consensus, which is used until HTP has fixed the time; not good, but probably a compromise we can make. If your bridge also can setup a SSL MitM attack against the HTP connections (e.g. the attacker also controls a SSL CA shipped by Debian), it can trick you into using this old consensus for max. one week, which is much worse. [1] [2]
I think the situation can be improved.
We have to trust torproject.org. These are the people who give us Tor. They are not expected to tamper the clock or to exploit the htpdate phrasing code. (idnxcnkne4qt76tg.onion torproject.org; p3igkncehackjtib.onion media.torproject.org)
usewithtor ./htpdate -d -q idnxcnkne4qt76tg.onion p3igkncehackjtib.onion
works. Encrypted end-to-end (hidden service). No SSL CA involved.
If you want more hidden service time sources, you could host your own hidden service, look if your existing htp sources have already a hidden service or ask them to host one.
Why don't you let htp ask hidden services for the time? Is my idea really new or do I oversee an obvious flaw?
[1]
https://tails.boum.org/todo/remove_the_htp_user_firewall_exception/
[2]
https://tails.boum.org/contribute/design/Time_syncing/
______________________________________________________
powered by Secure-Mail.biz - anonymous and secure e-mail accounts.
