Hi, there seems to be some misunderstanding, so let me ask questions aimed at clearing it up. I'll also add a bit of technical information you seem to have missed.
adrelanos wrote (12 May 2013 21:24:59 GMT) : >> * Tor censorship + a system that runs htpdate over Tor without >> checking whether Tor actually works (which our fork of htpdate is >> not designed to deal with) > No, that was not my concern. I sincerely fail to understand how this can not be your concern, while all non-imaginary problems you're describing below apparently involve exactly this: running htpdate over Tor without first checking whether Tor is working. See below, and please enlighten me... and/or add non-imaginary problems that do happen even if Tor is working -- I'd be delighted :) >> * a badly configured upstream router + a system that runs htpdate >> without checking whether the Internet is reachable (which our fork >> of htpdate is not designed to deal with) > As far I understand the tails_htp init script (in Tails), it does not > check if the Internet (Tor) is available or not. Unless I'm missing something, this service is started by /etc/NetworkManager/dispatcher.d/20-time.sh, once networking is up and Tor is working. AFAIK we don't rely on it working properly offline. >> * some other cause I'm missing -- care to enlighten me? > I think you may assume, if Tor knows "I can't connect" or "I am not > fully connected yet", that it will send a reply on curl's SocksPort > "offline", curl recognizes and instantly stops. No, I'm not assuming that. > Current situation: > If Tor is censored - curl will instantly fail and tails_htp will inform > about it. Sure, but how can this happen unless the system is starting htpdate over Tor, without first checking whether Tor actually works? > I don't see any extra fingerprinting issues introduced by > --connect-timeout + --max-time, under the assumption, that --max-time > was accepted before already. IIRC 180s for --max-time was arbitrarily chosen because it's the default behaviour of a well-spread HTTP client library. I doubt it's hard, for an attacker sitting at the exit node being used (or at the ISP if not using Tor) to delay the initial connection a bit longer than 60s and see if there's a timeout configured at this level, regardless of --max-time. So the combination of --connect-timeout = 60s and --max-time = 180s is probably easily fingerprintable. I'd be glad to be proven wrong, though :) (I must admit I've not looked at --connect-timeout in details yet, and I don't intend to do any such thing before someone else does their homework first, so I've no idea if that timeout is about TCP or HTTP connection yet, which makes it hard to discuss the matter at hand seriously.) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
