Guard against MITM sdwdate

Development
1

Facts:

-sdwdate is as safe as the trust put into centralized TLS CA authorities.
-This is by no means a sdwdate specific problem but an outcome of a broken CA model that has haunted the internet for years.

-Viable solutions suggested by the cryptographer community is decentralized WoT notary system like the Perspectives Project which track SSL cert usage over time independently and verify its authenticity thru consensus.

-The Perspectives Project is a product of the academic community at Carnegie mellon university and an inspiration to the convergence.io experiment run briefly by m0xie for trustworthy CA drop in replacements.

-Perspectives consists of a server and a Firefox addon as a client which is problematic for our implementation purposes for directing its usage by sdwdate for certificate verification of the servers it communicates with.

-No matter there is a clever workaround of using a python clientside script that listens on localhost to perform queries on behalf of other programs to the community run Perspectives notary servers.
The idea was conceived as a workaround for browsers that had not yet been supported by Perspectives.
http://perspectives-project.org/2011/07/08/perproxy-ubuntu-chrome/

Recommendation:
Adoption of this measure potentially strengthens sdwdate against TLS MITM attacks considerably. Its an important topic also best discussed with projects that have a shared interest in such time sync systems.

2
PerProxy is a proof of concept and is no longer being developed.

So we’d need to maintain it ourselves.

3

Ok what about using Tor consensus data in addition to the time server pools? Its a hybrid of what we are doing and Liberte’s Tordate. That way we a have a trusted time source to factor into the “time pool data” which is currently based almost exclusively on TLS’s broken authentication models.

4

I actually like that idea, something like this is planed for Whonix 10:
https://github.com/Whonix/Whonix/issues/244

Although doing this on Whonix-Workstation could be a bit difficult because tordate parses files from local hdd.

5

In reply to the problems brought up in: TimeSync: Whonix Time Synchronization Mechanism

If clock is too much off, Tor will be able to fetch the Tor consensus file, but won't be able to verify it?
The only instance that Tor wouldn't be able to directly verify consensus is when its using a bridge. Else its fetched from Directory Authorities in the clear.
Provides only rough time. 
web fingerprint would differ from most other Tor users.
Would cause lots of support requests complaining about skewed clocks.
Might trouble hidden services (such as hidden web servers) that need to show time to clients?
Might trouble people attempting to tunnel i2p through Tor?
Might cause other (gpg) verification issues?</blockquote>

-Forgive my question is it seems rather slow, but how would the web fingerprint differ? A global community of Tor users will give different host time if their torbrowser is queried by a site’s JS. Timestamps being disabled means that this information isn’t leaked by Tor or TCP connections made by the gateway. To rephrase for a response: What is being fingerprinted in your definition?

-About complaints, people already know that the purpose of timesync is to make Whonix’s time differ from the host’s.

  • Hidden servers are ideally supposed to revel as little information about themselves as possible.

-The other problems associated with time skews are speculation at this point. I doubt that they sky will fall because of a couple of hours deviation tops. If we use a value that falls in the middle of the consensus data’s range, it could handle this better than a random choice.

Hidden services can only be accessed if the clock is no more than 30 minutes slow or fast. [12]

Read the ticket, seems to have been a bug that has been patched since.

As per Comparison with Others#Fingerprint, quoted from the Tails Design about Time syncing: "Our initial time guess based on the Tor consensus is probably easier to fingerprint, though: a fresh Tor is started, and restarted again right after the consensus has been downloaded."

If the time is off Tor won’t be able to start though. Then a refresh of consensus is warranted. If Tor can work with the current time range set, then all is good, no download and restart needed. I don’t see what’s fingerprintable about this in our design where we have persistence for guard-data.

A suggestion is for consensus data to be fetched over Tor whenever possible else, fallback to clearnet.

6

the 30 min problem can cause hs to refuse connections indeed.

I saw on tails mail list how they dealt with that when using tordate :
https://mailman.boum.org/pipermail/tails-dev/2012-January/000854.html

Actually the entire thread is a good read, shows they did considerable effort intackling problems you brought up. Why not use their code instead of reinventing the wheel?

7
-Forgive my question is it seems rather slow, but how would the web fingerprint differ? A global community of Tor users will give different host time if their torbrowser is queried by a site's JS.
There would be the time users are using that are most likely using NTP and be the time users are using that are most likely using anondate. Browsers still do leak it in lots of places (https://trac.torproject.org/projects/tor/ticket/3059).
-About complaints, people already know that the purpose of timesync is to make Whonix's time differ from the host's.
Yes, but it is somewhat accurate, not wrong by an hour.

And one point that I failed to explain, this whole “time from verified consensus”… It is a lot less great and magic than you think.

From Tails - Time synchronization

First, replaying a consensus older than one week or so results in preventing access to the Tor network, and that's all, because onion keys will be wrong. An attacker who is in a position to replay a consensus to you could anyway do this, unrelated to time, so the issue at hand boils down to replaying a consensus not older than one week or so.
So an ISP level adversary could send an old Tor consensus that is 6 days old. The "time from verified consensus" could result in a clock that is 6 days too slow.

You can still verify messages that I signed with gpg a year ago. And those also include a signed time stamp from my local machine. Should you set your clock to it just because you can verify that time even if you trust that I didn’t forge the time? No. The trick with Tor is, that relays won’t accept any connections from someone that uses keys from a consensus that is older than a week.

So the issue you want to solve here “guard against MITM, be more resilient against MITM” changes the MITM target from remote ssl web servers and breaking CA’s to Tor where a MITM is in fact much simpler, since an adversary only needs to replay an old Tor consensus without even needing to break CA’s.

In case of Whonix, things would go even worse with solely relying on Tor Consensus Method rather than Remote Web Servers Method. At the moment ISP level adversaries can do a denial of service, but not influence the users clock, because that comes from remote web servers that are asked through Tor. On the other hand, with Tor Consensus Method, ISP level adversaries can decide what consensus they will be feeding the user, and guess in what range anondate will set the users clock then. And if they additionally also control some remote web servers that the user is visiting and JS leaks the time, they can easily guess which user they just have deanonymized.

- Hidden servers are ideally supposed to revel as little information about themselves as possible.
Supposed to, but hiding that information isn't documented for lots of service perhaps it is not even possible due to lack of feature or even required (this forum needs some kind of time for example).
[quote]Hidden services can only be accessed if the clock is no more than 30 minutes slow or fast. [12][/quote]

Read the ticket, seems to have been a bug that has been patched since.


To what value have they changed it?

[quote]As per Comparison with Others#Fingerprint, quoted from the Tails Design about Time syncing: "Our initial time guess based on the Tor consensus is probably easier to fingerprint, though: a fresh Tor is started, and restarted again right after the consensus has been downloaded." [/quote]

If the time is off Tor won’t be able to start though.


It is the terminology “won’t be able to start” that is ambiguous and problematic here. It means, “it starts, attempts fetching the consensus, but then won’t be able to establish circuits. It’s trying though.”

Then a refresh of consensus is warranted. If Tor can work with the current time range set, then all is good, no download and restart needed.
When no restart is required, it is not fingerprintable.

It causes a “Fingerprintable reaction [129] when big clock skew attack was used.”

“Network fingerprint: ISP can not guess which anonymity software is being used because of tordate [73]”

“No (bad), if clock is too much off when booting. [73]”

“Quoted from the Tails Design about Time syncing: “Our initial time guess based on the Tor consensus is probably easier to fingerprint, though: a fresh Tor is started, and restarted again right after the consensus has been downloaded.””

I don't see what's fingerprintable about this in our design where we have persistence for guard-data.
This would apply to first start of Whonix-Gateway because then we don't have a Tor consensus yet.

Also thinking through what would happen on computer reboot, when the host’s clock was modified (attack against NTP) or buggy would be required, since when VM starts, VM time = host time.

A suggestion is for consensus data to be fetched over Tor whenever possible else, fallback to clearnet.
It's a bootstrap problem and much different topic. A suggestion to be made for Tor, not Whonix. In summary, Tor clients need to know what the current Tor network is (=consensus) before they can use Tor. Related, see also: http://tor.stackexchange.com/questions/287/how-can-tor-use-a-one-hop-circuit-to-a-directory-server-during-initial-bootstrap
8
  • Because their code is highly Tails specific.
    – Depending on non-persistent Tor data dir.
    – Entangled with Tails specific gui notifications.
    – Entangled into the Tails specific boot process with other scripts.
    – Not a clean abstraction of “tell me what Tor’s log / Tor’s consensus thinks about date/time”.
    – Quote: “Currently we use tordate to set the initial clock. It’s very messy and error prone, so we desperately need a robust replacement.” (https://labs.riseup.net/code/issues/5774)
  • I wouldn’t want opening up to the fingerprinting risks without the user being aware of it.
  • I wouldn’t know how to just re-use it on Whonix without cleaning it up.
  • After all, I am very happy about all their grep / date / sed magic, and re-using that code without modification. Just cleaning up API / abstraction layer / boot process. During the process I am understanding it better and fixing the robustness issues.
9

Thank you for taking the time to explain everything so well. I think its best to keep things as they are, seeing how the current design is superior in overcoming limitations tordate runs in to. Besides waiting for TPO to introduce a time query scheme into Tor itself I don’t see much future improvement possible in this area. Or you could use your power of persuasion to bring it to their attention.

Quote from TAILS ticket on this and links to TPO discussion:

Extend Tor some how, e.g https://lists.torproject.org/pipermail/tor-talk/2011-January/008551.html https://trac.torproject.org/projects/tor/ticket/6894

I decided to post the other not so good ideas of mine here to for archival purposes. The Whonix 10 priority ticket wasn’t a good place for that. If you want, you could discuss whether they have any relevance.

Alternatives: 
use Jacob's tlsdate.

–Advantages:

1.Less maintenance burden as its maintained by him and included in Debian repos.

2.Can take advantage of additional security safeguards like seccomp while parsing the same untrusted content we already do.

Used by ChromeOS as per: https://labs.riseup.net/code/issues/5774

Considered as an alternative by TAILS for future adoption. Could be configured to use multiple sources for time requests although it uses just the one Google server by default.

–Disadvantages:

1.It’s a binary written in C which might mean problems for your reproducible build system.

[s] - Only use communication with Keyservers/ WoT to fetch time. Using their version of secure protocol HKPS, we can send requests with timesync and parse the timestamps with something like parcimonie. that way we leave the baggage of CAa behind and could potenitally rely on a small trusted pool with a gpg based system to bootstrap off of.

Imagine someone sends you a signed then encrypted email. Your mail client happily retrieves the key for the signature. Evan is watching the traffic and sees the key fly by. Now he knows 1) that you can read messages encrypted with the key he sent to, 2) that you did read that particular message, and 3) the approximate time you read it. If this kind of confirmation attack worries you, use hkps and Tor to get keys, and don't do it automatically. parcimonie is a tool that works to solve this problem. [/s]

The keyservers idea is a poor one as few servers use HKPS. Their root of trust is a self signed .pem which you want to avoid because of revocation problems. and rightly so.

10

If you want to discuss tlsdate, please open a new topic since it is very different from the suggestion of this thread (improving sdwdate). (Off topic, just now written: TimeSync: Whonix Time Synchronization Mechanism)

Thank you for taking the time to explain everything so well.
Thank you as well. I always wanted to think throughly through the tordate approach. Always thought even if Whonix isn't using it as Tails it may be useful anyway, even if just used to advice / diagnosing issues for the user. Just now updated again https://www.whonix.org/wiki/Dev/TimeSync#Tor_Consensus_Method based on the discussion with you. :)
Or you could use your power of persuasion to bring it to their attention.
Already did that up to the point where I think it is useful. Any more persuasion without adding new interesting (major) points would to my understanding rather discourage them from doing it.
11
If you want to discuss tlsdate, please open a new topic since it is very different from the suggestion of this thread (improving sdwdate). (Off topic, just now written: https://www.whonix.org/wiki/Dev/TimeSync#tlsdate)

Amazing, looks like you were two steps ahead on this and discussed it with Jacob sometime back. :smiley: By excluding what won’t work its a really constructive process. I’ll stick to strictly discussing improving sdwdate.

-Are sdwdate’s requests homogenous with normal traffic? what I mean is, its not possible to know if timesync’s requests are any different than those made by any web-browser just by passively observing exit traffic.

-I have a suggestion but am reluctant in making it because I don’t want you to lose interest in the concept altogether when you’ve just started to dabble in it and because of the potential effort it entails. There is no rush to get this off the ground,if anything its more probable that this will materialize before TPO adds the necessary bits to Tor. Please, just keep it on the backburner but keep it on the todo list.
Its clear that until we can get a reliable and trusted time feature from upstream, we will be stuck in having to parse untrusted input, to achieve maximum security its best if we use the secure audited components to deal with any network facing traffic, in general. Its rational to have sdwdate scripts be ported to mksh.

12
Are sdwdate's requests homogenous with normal traffic? what I mean is, its not possible to know if timesync's requests are any different than those made by any web-browser just by passively observing exit traffic.
Looking like curl requests. The only chance (not guarantee) to make them look like Firefox or Tor Browser requests would be using Firefox or Tor Browser or at least re-use their related code. Re-using their code requires knowledge of C, a custom program and constantly keeping up with changes in Firefox. Alternatively, more promising would perhaps be using some kind of automation API. http://seleniumhq.org could do in theory. No idea how robust it would be across browser updates. But I don't know if it would work out of the box or if a browser add-on would have to be installed beforehand (haven't researched). Although it would be nice to have, and certainly doable, we don't have coders to implement such things.
Its rational to have sdwdate scripts be ported to mksh.
Already considering this: https://github.com/Whonix/Whonix/issues/301
13
Looking like curl requests.

The reason I bring this up is because the TAILS dev describe their requests as not fingerprintable somehow. I was wondering if there is a way to follow whatever they’re up to for timesync

https://tails.boum.org/contribute/design/Time_syncing/

Fingerprinting Tails users

Tails runs HTP through Tor, so the fingerprintability should be limited to traffic flow only. It should be noted that HTP only fetches the HTTP header, so fingerprinting based on the known traffic pattern when fetching the full page of any of the members of Tails’ HTP source pools is not possible.

SeleniumHQ is an interesting find in its own right even if its not going to be used in whonix. The part that simulates user actions in the browser is indeed an addon. In its list of supported browsers, it seems to track the stable Firefox channel that uses the 3.x nomenclature. The software is current though and actively developed.

Already considering this: https://github.com/Whonix/Whonix/issues/301
Great. thanks :D
14

(Topic diverted from “Guard against MITM sdwdate” to “Guard against fingerprinting sdwdate”.)

[hr]

There shouldn’t be any differences in fingerprinting Tails htpdate vs fingerprinting Whonix sdwdate.

The confusion is coming from the terminology.

Talking about ISP level fingerprinting:

Tails runs HTP through Tor, so the fingerprintability should be limited to traffic flow only.

(…same for Whonix. (Using Firefox vs wget vs curl is more a question of fingerprinting at exit relays and destination servers.))

[hr]

Talking about ISP level fingerprinting as well as “Website traffic fingerprinting” (as defined within The Design and Implementation of the Tor Browser [DRAFT]):

It should be noted that HTP only fetches the HTTP header, so fingerprinting based on the known traffic pattern when fetching the full page of any of the members of Tails' HTP source pools is not possible.

If using htpdate with “get” rather than “head” is being discussed inside here somewhere:

[hr]

Related to fingerprinting:
[Tails-dev] Faking htpdate user agent worth it?:
https://mailman.boum.org/pipermail/tails-dev/2012-October/001871.html

[hr]

Not related to this thread, but since you’re interested in all sorts of sdwdate aspects, you may also wish to read/follow/join:
[Tails-dev] Tails htpdate - why use time information from neutral and foe pools?:
https://mailman.boum.org/pipermail/tails-dev/2014-August/006821.html

15
(Topic diverted from "Guard against MITM sdwdate" to "Guard against fingerprinting sdwdate".)

My worry was that sdwdate traffic be easily singled out by them , leaving it more probable that exploits could be employed against it on a mass scale.

16

My worry was that sdwdate traffic be easily singled out by them , leaving it more probable that exploits could be employed against it on a mass scale.[/quote]
Yes, a valid point.
Unfortunately difficult (not impossible) to fix as per my answer Whonix Forum.

17

Come to think of it, defeating fingerprinting using SeleniumHQ, even if it was easy, brings in the entire browser codebase as part of the trusted code base. Not good, its a cure worse than the disease in this situation.

18

Yes. For getting the exact same web fingerprint, we’d need to run all javascript (if that still were the default setting in Tor Browser).

So we indeed rather accept the fingerprinting issues and care about making it as secure as possible. (I’d still accept a patch making this an option, but given the obscure nature of this issue, I doubt anyone will be ever interested.)

19

I’ve given this approach some more thought since you explained it. I have some ideas on how we can get over the ISP level adversary and fingerprinting issue. It will involve changing use-advice in the guide and thats about it. Figuring out how to distill a more finegrained time reading that’s close as possible to the real time is subject of another post.

  • At first it looks like a chicken-egg problem: It would be better to fetch consensus data over Tor to prevent the fingerprinting issues and the possibility of being fed outdated data. But Tor can’t connect without a correct time to enable this.

-For normal non-virtualized hosts running Tor, if the clock is too much off there is no connection established even though this is attempted. Tor waits for the user to manually correct the time on the host for a connection to be successful.

-Doing a system suspend is the cause for the guest clock to be very inaccurate if it was in a saved/running state.

  • Our current settings isolate guest time from the host’s forcing it to rely on timesync as the sole source of time accuracy.

BUT

  • Whenever a guest is started or restarted it bases its time on the host’s.

  • Let’s assume that the host’s clock falls within the accurate range that allows Tor to connect. And also that (Linux) users are following best protocol; by disabling timestamps on the host and not running anything on there. Because really if they are not doing this they are defeating a large part of the protection a hypervisor is about.

  • No time is leaked from the host to compare with, but at the same time host time is accurate enough to use to bootstrap with by Tor.

Conclusion:

-Fetching consensus data is one over Tor, ideally this can be done multiple times over different exits and the results compared as to stop an exit’s ISP from doing the attack described above.

  • Users will be advised to make sure their host time is roughly accurate and close enough to the actual which they can check out of band for example a wallclock.

  • If time is off and Tor can’t connect, the user will be advised to reboot the gw, so the host’s time be used but the occurence of this will be rare and not fingerprintable provided the action described below is taken.

  • Users will be advised to poweroff the guest to avoid drifts as this is corrected on subsequent starts. inconvenient? somewhat but not a deal breaker. Guests start darn fast on modern hardware, more so if the gateway is not running the DE because its configured with less ram. These steps are only needed for the gateway.

  • We can rely solely on anondate to fetch a fresh consensus soley for the purpose of making the guest clock differ from the host’s (provided that we figure out ways on get a more realistic reading from this data).

  • This remedy is not necessary for the workstation because as long as the the Gateway can connect to Tor, anondate would be able to fetch its consensus via this Tor connection. There is no other Tor instance that needs the time accurate for bootstrapping in there. A user can keep his session running without rebooting or shutting down his workstation.


I think the whole necessity for securely setting time goes away if the Host’s clock is kept private, which it can be.The bootstrapping issues are fixed with restarting the gateway. But the point of this proposal is to keep secure time syncing mechanism available.

20

N.B. that its not necessary for people to really change their use habits. If they run stuff on the host they will be ok for the most part, because nothing running on the gateway will give away the timestamps.

Once the gateway connects, then the workstation can use anondate to set a different time in case something on there leaks time to the web, in addition to another program on the host doing that too.

According to Nick OpenSSL 1.0.1f has timestamps disabled.

Situation A: typical user

-Host leaky, gateway not, Workstation leaky = user safe.
Workstation can have time set safely. gateway does not betray time when restarting.