Re: [Tails-dev] Please review and test feature/tordate

Delete this message

Reply to this message
Autore: anonym
Data:  
To: The Tails public development discussion list
Oggetto: Re: [Tails-dev] Please review and test feature/tordate
10/02/2011 10:34 PM, intrigeri:
> Hi,
>
> I eventually got fed up with HTP-related issues reports enough to
> implement the new time setting system we designed quite a long time
> ago, and validated only recently.
>
> Please review and test feature/tordate.
>
> The feature was documented there:
> https://tails.boum.org/todo/remove_the_htp_user_firewall_exception/
> ... but I've left in a pretty bad shape some time ago, so the Git
> branch log should greatly help understand what's happening.


I skimmed through the branch, and it sure looks clean and robust in
comparison to the old mess.

> According to my quick initial tests (most of this was developed
> offline):
>
>   - in the general case i.e. system time is quite correct: Tor and
>     Internet are immediately usable, no need to wait for HTP


Confirmed. In fact, in my build of the tordate feature branch Tor is
usually up and running before Iceweasel starts so the site is actually
loaded instead of timing out.

>   - when the system time is wrong by a few hours: Tor and Internet are
>     usable much sooner than previously


Confirmed.

> - when the system time is way off: not tested yet


Everything from the year 2000 up until some months into the future works
for me. The problem is "way in the future", e.g. 2013. Then the all the
authority certificates are invalid, so there's no valid consensus.

In 20-time.sh we're only looking at cached-consensus for the
valid-{after,before} values, but due to the outdated certs, the
consensus will be put in unverified-consensus. We *could* take that into
account, see attached patch. I'm not pushing it as I'm not sure we want
to do this. After all, the consensus hasn't been verified, so the time
could be arbitrarily chosen by a malicious authority. That can't be good.

>   - htpdate (now torified) seems to fail a bit too often to my taste;
>     perhaps the shiny new Tor has a hard time establishing circuits,
>     resolving DNS and retrieving files from the web; needs to be
>     investigated; note to myself: if htpdate forwarded wget's stderr,
>     things would get easier to debug. It may may make sense to wait
>     for cached-descriptors (see tor_is_running function in 20-time.sh)
>     before running htpdate / touch'ing $TORDATE_DONE_FILE.


Confirmed. Perhaps we could add a --retries X option to htpdate, where
each wget fetch is allowed to fail X times (duh!). Issue: the retried
fetches may use the same faulty circuit and just fail again.

Cheers!
diff --git a/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh b/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh
index e8dcefa..8134867 100755
--- a/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh
+++ b/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh
@@ -13,7 +13,8 @@
 TORDATE_DIR=/var/run/tordate
 TORDATE_DONE_FILE=${TORDATE_DIR}/done
 TOR_DIR=/var/lib/tor
-TOR_CONSENSUS=${TOR_DIR}/cached-consensus
+TOR_CACHED_CONSENSUS=${TOR_DIR}/cached-consensus
+TOR_UNVERIFIED_CONSENSUS=${TOR_DIR}/unverified-consensus
 TOR_DESCRIPTORS=${TOR_DIR}/cached-descriptors
 INOTIFY_TIMEOUT=60
 DATE_RE='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]'
@@ -54,7 +55,7 @@ tor_is_working() {
 wait_for_tor_consensus() {
     log "Waiting for the Tor consensus file to contain a valid time interval"
     while :; do
-        if grep -qs "^valid-until ${DATE_RE}"'$' ${TOR_CONSENSUS}; then
+        if grep -qs "^valid-until ${DATE_RE}"'$' ${TOR_CACHED_CONSENSUS} ${TOR_UNVERIFIED_CONSENSUS}; then
             break;
         fi


@@ -84,9 +85,20 @@ ${vendcons}"
}

 maybe_set_time_from_tor_consensus() {
+    local consensus
+
+    # See which consensus is available. If the system time is too much in
+    # the future, the authorities' certs will be considered invalid, and
+    # the consensus will remain unverified.
+    if [ -e "${TOR_CACHED_CONSENSUS}" ]; then
+        consensus="${TOR_CACHED_CONSENSUS}"
+    elif [ -e "${TOR_UNVERIFIED_CONSENSUS}" ]; then
+        consensus="${TOR_UNVERIFIED_CONSENSUS}"
+    fi
+
     # Get various date points in Tor's format, and do some sanity checks
-    vstart=$(sed -n "/^valid-after \(${DATE_RE}\)"'$/s//\1/p; t q; b n; :q q; :n' ${TOR_CONSENSUS})
-    vend=$(sed -n "/^valid-until \(${DATE_RE}\)"'$/s//\1/p; t q; b n; :q q; :n' ${TOR_CONSENSUS})
+    vstart=$(sed -n "/^valid-after \(${DATE_RE}\)"'$/s//\1/p; t q; b n; :q q; :n' ${consensus})
+    vend=$(sed -n "/^valid-until \(${DATE_RE}\)"'$/s//\1/p; t q; b n; :q q; :n' ${consensus})
     vmid=$(date -ud "${vstart} -0130" +'%F %T')
     log "Tor: valid-after=${vstart} | valid-until=${vend}"