{{Header}} {{Title|title= TimeSync: {{project_name_long}} Time Synchronization Mechanism }} {{#seo: |description=Design Documentation of {{project_name_short}} Time Synchronization Mechanism }} {{time_mininav}} {{intro| Design Documentation of {{project_name_short}} Time Synchronization Mechanism }} = Basic Knowledge = == Introduction == The Post Install Advice is part of this design. Therefore, read [[Post Install Advice#Network Time Syncing|Network Time Syncing]] first. Also read [[Network Time Synchronization|Network Time Synchronization]]. == Local Clock Leaks == * TCP Sequence Numbers → [https://github.com/Kicksecure/tirdad tirdad] * [https://web.archive.org/web/20160624053221/https://mailman.boum.org/pipermail/tails-dev/2014-September/007062.html Tails-dev - TCP Sequence Numbers leak System Clock] * [https://gitlab.torproject.org/legacy/trac/-/issues/16659 Linux TCP Initial Sequence Numbers may aid correlation] * ICMP timestamps → blocked by {{project_name_short}} firewall for {{project_name_short}} VMs. Host: [[Disable_TCP_and_ICMP_Timestamps#Disable_ICMP_Timestamps|Recommendation]] to disable on the host. * TCP timestamps → blocked in {{project_name_short}} VMs by [https://github.com/Kicksecure/security-misc security-misc]. [[Computer_Security_Education#Disable_TCP_Timestamps|Recommendation]] to disable on the host. * NTP → Not installed by default in {{project_name_short}}. Host: TODO * Automatic updaters and other network using cron jobs that run at non-random, canned By distribution defaults. times. * JavaScript. Was [https://gitlab.torproject.org/legacy/trac/-/issues/3059 fixed] in Tor Browser, but remains open for other applications such as browsers like Mozilla Firefox. See https://ip-check.info/ for demonstration. * E-mail clients such as Mozilla Thunderbird and others. As of June 2016, Iceweasel has been replaced by Firefox-ESR in Debian, see https://wiki.debian.org/Iceweasel [https://gitlab.torproject.org/legacy/trac/-/issues/6314 prevent leak via Date header field (local timestamp disclosure)] [https://gitlab.torproject.org/legacy/trac/-/issues/6315 prevent leak via Message-ID header field (local timestamp disclosure) ] [https://blog.torproject.org/torbirdy-013-our-fourth-beta-release Quote, on October 24th, 2014 sukhbir said]:
"The timestamp disclosures are via the date and the message-ID headers (relevant tickets: [https://gitlab.torproject.org/legacy/trac/-/issues/6314 #6314], [https://gitlab.torproject.org/legacy/trac/-/issues/6315 #6315]). We have submitted patches to Mozilla ([https://bugzilla.mozilla.org/show_bug.cgi?id=902573 902573], [https://bugzilla.mozilla.org/show_bug.cgi?id=902580 902580]) that have not yet been merged. The patches probably need more work and we are looking for volunteers to work on them and help us to get them merged. We will be doing a blog post about this soon and put out a call for help." * HTTPS / SSL, older versions of OpenSSL, TLS HELLO gmt_unix_time https://gitlab.torproject.org/legacy/trac/-/issues/8751 What about other implementations of SSL / TLS, other than OpenSSL? * older For example the one shipped by Debian wheezy. versions of Tor (NETINFO) See [https://gitlab.torproject.org/legacy/trac/-/issues/4852 torproject.org #4852: Clients send NETINFO with time]. The ticket says fixed. However, [https://packages.debian.org/de/wheezy/tor Debian wheezy (which {{project_name_short}} 10 was based on) was using Tor 0.2.3] but Nick's [https://gitlab.torproject.org/legacy/trac/-/issues/4852#comment:20 patch appeared first in 0.2.4]. It was solved in {{project_name_short}} 11, because it was based on Debian jessie, that contained [https://packages.debian.org/de/jessie/tor a more recent version of Tor]. * web servers (timestamps from HTTP headers (RFC 2616)) For demonstration, you could use: 
curl -silent --head torproject.org | grep -i date:
== Virtualizers Time Synchronization Features == === VirtualBox Time Synchronization Features === {{Anchor|VirtualBox's Time Synchronization Features}} To understand the {{project_name_short}} Time Synchronization Mechanism, it is required to know VirtualBox's time synchronization features: * VirtualBox uses the host's time if it needs to correct the time for guests. * (Some of VirtualBox's time synchronization features depend on guest additions.) * By default VirtualBox corrects Virtual Machine guests' virtual hardware system clock, ** when they get powered on, ** when they resume from suspension and ** when their clock is more than X minutes off. === KVM's Time Synchronization Features === * KVM attempts (in vain) to use: ** ntpd ** If offline or manually selected (with a compatible CPU), Time Stamp Counters (TSC) from the CPU.https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/chap-kvm_guest_timing_management It is possible to check which exact method of synchronization the guest is trying to use by typing cat /sys/devices/system/clocksource/clocksource0/current_clocksource. https://www.linux-kvm.org/page/KVMClock As of 2024, on Whonix, this is TSC (KVM does not control the process as kvm-clock is not included within the output). sdwdate and bootclockrandomization fix any timing attacks that could be introduced. === Qubes Time Synchronization Features === TODO: document Xen DomUs get their initial time from Xen (Qubes dom0) at VM start. * qvm-sync-clock.service * qvm-sync-clock.timer qvm-sync-clock gets time from Qubes ClockVM. It is used because otherwise Xen DomUs would start to drift more and more. See [https://forums.whonix.org/t/whonix-ws-16-fails-to-update-due-to-timing-issue/12739/10 this answer by marmarek]. qvm-sync-clock is unwanted in {{project_name_gateway_vm}} and {{project_name_workstation_vm}} because sdwdate runs there. qvm-sync-clock is disabled in {{q_project_name_long}} Templates until version {{q_project_name_long}} 16.0.3.7. This should be reconsidered for later versions. {{q_project_name_long}} Templates get their time from dom0 at VM startup, which is then randomized using [[Boot Clock Randomization]]. Future: qvm-sync-clock should be equally safe to run inside {{q_project_name_short}} Templates, if passed through clock-random-manual-cli. When is /etc/qubes-rpc/qubes.SetDateTime run? == sdwdate Time Sources Criteria == See [[Sdwdate#sdwdate_Time_Sources_Criteria|sdwdate Time Sources Criteria]]. == Facts == People have been using: * Tor Browser and Mozilla Firefox in parallel * Tails inside VMs and Firefox on the host * Tor Browser inside {{project_name_workstation_long}} and Mozilla Firefox on the host == Other Facts == * Almost no one, and no operating system, is using Secure Network Time Synchronization or External Clocks by default. Most systems synchronize the system clock using unauthenticated NTP. An adversary tampering with NTP replies or a malicious NTP server makes things even worse. Even if there was authenticated NTP, there is a requirement for a distributed trust model. * A system not using NTP or using authenticated NTP stands out from most other users. * Clock jumps are bad: [https://www.wired.com/2012/07/leap-second-glitch-explained/ Wired: The Inside Story of the Extra Second That Crashed the Web] == Definitions == * Time Sanity Check in the context of Whonix: an init.d script that checks if the system clock is between the build timestamp and the expiration date (17 MAY 2033 10:00:00). = Attacks = A correct system clock is crucial for many reasons (see footnotes for more): * '''Attack 1:''' Replay attacks Replay old Tor consensus, see [https://tails.boum.org/contribute/design/Time_syncing/ Tails: Time syncing] for detailed explanation. * '''Attack 2:''' Feeding old/outdated/known vulnerable updates and (HTTPS) certificates Cryptographic verification depends on the system clock, i.e. a clock two years in the past will accept certificates/updates that have been expired/revoked for two years. * '''Attack 3:''' Deanonymizing [[#Local Clock Leaks]] are an issue. Imagine the user connects to an adversary controlled web server with Mozilla Firefox and connects to another web server controlled by the same adversary with Thunderbird. The adversary can link the anonymous and non-anonymous session, thus deanonymizing. * '''Attack 4:''' Linking all sessions to the same pseudonym If the clock is too much off, it is also easy for an adversary's web server to detect "Oh, that's the Tor Browser user whose clock is X in the past/future.", thus allowing the adversary to link all sessions to the same pseudonym. See Tor Browser upstream bug #3059: [https://gitlab.torproject.org/legacy/trac/-/issues/3059 Find some way to deal with time-based fingerprints]. * '''Attack 5:''' Locating onion services. For onion services a correct clock is crucial, see: * [https://murdoch.is/papers/ccs06hotornot.pdf Hot or Not: Revealing Hidden Services by their Clock Skew] * [https://web.archive.org/web/20220324134410/https://caia.swin.edu.au/talks/CAIA-TALK-080728A.pdf An improved clock-skew measurement technique for revealing hidden services] * [https://web.archive.org/web/20120522143952/http://people.cs.umass.edu/~elisha/Papers/SkewMask%20-%20final%20version.pdf SkewMask: Frustrating Clock Skew Fingerprinting Attempts] * [https://catalog.caida.org/details/paper/2005_fingerprinting Remote physical device fingerprinting] = Goals = == Completely Isolated Virtual Time == Quote https://www.kernel.org/doc/Documentation/virtual/kvm/timekeeping.txt
4.8) Covert channels and leaks In addition to the above problems, time information will inevitably leak to the guest about the host in anything but a perfect implementation of virtualized time. This may allow the guest to infer the presence of a hypervisor (as in a red-pill type detection), and it may allow information to leak between guest by using CPU utilization itself as a signalling channel. Preventing such problems would require completely isolated virtual time which may not track real time any longer. This may be useful in certain security or QA contexts, but in general is not recommended for real-world deployment scenarios.
Therefore, ideally, we would want a completely isolated virtual time. However, this is not possible with thorough x86 virtualization (at least with KVM) due to the extreme complexities of emulating time sources used in x86 hardware (the issue is deeper than the "wall clock" time that sdwdate concerns itself with). However, we do want to have guest wall clocks entirely independent from the host's wall clock if at all possible. = {{project_name_short}} Time Synchronization Mechanism = == Overview == * {{project_name_short}} leaves the host's system clock or time synchronization mechanism untouched. * {{project_name_gateway_long}} and {{project_name_workstation_short}} are commonly used inside virtualizers and therefore have their own virtual hardware system clocks. * Virtualizer time synchronization features are disabled by {{project_name_short}}. ** Most VirtualBox time synchronization features are disabled by {{project_name_short}}. *** Guest additions time synchronization is disabled by [https://github.com/{{project_name_short}}/vm-config-dist vm-config-dist] at run time. See VirtualBox bug report [https://www.virtualbox.org/ticket/10828 VBoxService --disable-timesync broken]. They say it is actually not a bug. It is a missing feature, because running instances of VBoxService cannot be modified in their settings. *** built in time synchronization features are disabled by ''VBoxManage setextradata "$VMNAME" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" "1"'' at build time. ** Qubes: TODO *** https://phabricator.whonix.org/T389 *** https://phabricator.whonix.org/T440 *** https://phabricator.whonix.org/T389 * VM Settings, Hardware Clock: set to UTC. * When they are powered on, they still get their time from the host. The user is advised to modify the biossystemtimeoffset in the Advanced Security Guide, chapter [[Advanced Security Guide#Network Time Synchronization|Network Time Synchronization]]. Developer information: If we needed or wanted to render the hardware clock unusable, we could set VirtualBox ''--biossystemtimeoffset'' several decades in the past or future. * Time Sanity Check is executed before [[sdwdate]]. This ensures that the host clock is sane and not slow in 1980. The user is advised to fix the host clock in such cases. * After they are connected to the Tor network, they use sdwdate (inspired by [https://tails.boum.org/contribute/design/Time_syncing/ tails_htp]) to set the system clock. Stream isolation has been added for the {{project_name_short}} sdwdate implementation. This prevents people using Tor Browser from notifying their exit relay that they are sdwdate or {{project_name_short}} users. * Time Sanity Check runs after sdwdate is executed. This should catch possible major bugs and attacks. The user is informed if it fails. * Using [https://github.com/{{project_name_short}}/bootclockrandomization Boot Clock Randomization], i.e. after boot, the clock is set randomly between 0 and 180 seconds into the past or future. This is useful to enforce the design goal that the host clock and {{project_name_workstation_short}} clock should always differ slightly. It is also useful to obfuscate the clock when sdwdate itself is running, because naturally at this time, sdwdate has not finished. * sdwdate runs after booting. * {{project_name_gateway_short}}: Using sdwdate is better against Attack (1) when using a bridge. * Every hour, at a random time, sdwdate will set the clock again. This is useful for machines running for long time periods without reboot. * sdwdate runs at unpredictable times to prevent the ISP or Tor guard/bridge node from guessing that the user is running {{project_name_short}}. * sdwdate adds or subtracts a random number of seconds in the range of 0.000000001 and 0.999999999. Check. 
grep -i "Made up" /var/log/sdwdate.log
This is supposed to prevent time servers from tracking individual users. * This reaches the design goal that all clocks, the host's, {{project_name_gateway_short}} and {{project_name_workstation_short}}, slightly differ. == Block Networking until sdwdate Finishes == TODO: expand '''This is not yet enabled by default.''' Network access will be limited to Tor and sdwdate until network time synchronization is done to prevent accidental traffic before that is done. {{project_name_short}} firewall runs in two different modes. After boot, it runs in timesync-fail-closed mode. 
OK: First run during current boot, therefore running in timesync-fail-closed mode.
OK: (Only local Tor control port connections and torified sdwdate allowed.)
Otherwise, after sdwdate succeeds or after manually reloading {{project_name_short}} firewall, it runs in full mode. 
OK: Consecutive run during current boot, therefore running in full mode.
OK: (Full torified network access allowed.)
Users are encouraged to test so we can enable it by default in the future. https://forums.whonix.org/t/testers-wanted-blocking-networking-until-sdwdate-finished-status-of-sdwdate-gui/5372/6 Instructions: [[Network_Time_Synchronization#Block_Networking_until_sdwdate_Finishes]] == Boot Clock Randomization == {{Boot_Clock_Randomization}} == Conclusions == * '''Attack 1''' is a general Tor problem. It is impossible to solve for {{project_name_short}}. It is unsolved in other projects as well. * '''Attack 2''' gets partially defeated. ** {{project_name_gateway_short}} and {{project_name_workstation_short}} are immune. ** This problem is unsolved in other projects as well. *** This is a general problem with all operating systems. *** The host is still at risk. *** [https://web.archive.org/web/20120905134544/http://brainstorm.ubuntu.com/idea/30050/ Ubuntu Brainstorm Idea #30050: Secure Network Time Synchronization] *** [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23687166 Debian Bug Report ntp: NTP security vulnerability because not using authentication by default] *** [https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1039420 Ubuntu Bug Report NTP security vulnerability because not using authentication by default] ** Manual workaround: Check your clock manually and read [[Other Operating Systems#About_Ubuntu|About Ubuntu]] (stale mirror attack). ([https://bugs.launchpad.net/launchpad/+bug/716535 Bug #716535: Please support Valid-Until in release files for security.ubuntu.com]) * '''Attack 3''' is defeated, {{project_name_short}} adds additional security. * '''Attack 4''' is defeated, {{project_name_short}} adds additional security. * '''Attack 5''' is a general Tor problem, which cannot be solved by {{project_name_short}} and which is unsolved in other projects as well. Since host, {{project_name_gateway_short}} and {{project_name_workstation_short}} time all differ, at least this attack becomes harder against {{project_name_short}}. When the user powers on {{project_name_gateway_short}} and the host time is too much off, it will not be able to connect to the Tor network. It is advised, when powering on {{project_name_gateway_short}}, to check that the host time is no more than 1 hour in the past or more than 3 hours in the future, otherwise Tor will be unable to establish circuits. https://lists.torproject.org/pipermail/tor-talk/2012-February/023264.html An adversary tampering with the user's clock, while the user does not recognize that, cannot do any more damage to {{project_name_short}} than he could do to Tor Browser. The worst case is a denial of service for Tor. On the other hand, an adversary capable of actively tampering with the traffic between the user and its entry guard or bridge poses much bigger risks to Tor in general. General Tor problems, Tor is known to be broken against many active attacks. This cannot be solved by {{project_name_short}}. When an adversary is capable of running active attacks, tampering with the time leading into a denial of service is the least of the worries. The adversary could also disrupt the service more easily. And as for active attacking in general, there are other attacks which are easier to deploy and which pose a greater danger. Not a {{project_name_short}} specific problem. The reason for running TimeSync on {{project_name_gateway_short}} is that onion services can only be accessed if the clock is no more than 30 minutes slow or fast. https://gitlab.torproject.org/legacy/trac/-/issues/3582#comment:3 Running TimeSync ensures that the {{project_name_gateway_short}} clock is reasonably accurate. {{Anchor|sclockadj2}} = External Clock = This topic is still under research. Help is welcome. It might make sense to add an external clock, such as a GPS, or even better an atomic clock. (Can we get an atomic USB clock?) This clock should be added to the host and/or {{project_name_gateway_short}} and/or {{project_name_workstation_short}}? Open question: would the GPS/atomic clock be too accurate and would that make {{project_name_short}} more fingerprintable? = Discarded Options = == NTP == {{Anchor|NTP authentication (autokey) is insecure}} * unauthenticated by default * NTP insecure ** https://web.archive.org/web/20200209084816/https://gist.github.com/CHEF-KOCH/12976cf15012d64b8fd2 ** https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-using-it.html * NTP authentication (autokey): ** info: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-network-time-security-00 ** insecure: http://www.innovationslab.net/~brian/NTP/autokey-analysis.pdf [down, contacted author] might be helpful alternatives [https://web.archive.org/web/20200206053329/http://zero-entropy.de/autokey_analysis.pdf Analysis of the NTP Autokey], [https://doc.ntp.org/reflib/reports/stime1/stime.pdf The Autokey Security Architecture, Protocol and Algorithms] Procedures ** insecure: https://web.archive.org/web/20210225205522/http://zero-entropy.de/autokey_analysis.pdf ** Does not work behind NAT? https://web.archive.org/web/20210618153528/http://lists.ntp.org/pipermail/questions/2010-November/028033.html https://gitlab.tails.boum.org/tails/tails/-/issues/6113 * NTP leaks the local time. Source: [https://www.ietf.org/rfc/rfc5905.txt RFC5905]
Origin Timestamp (org): Time at the client when the request departed for the server, in NTP timestamp format.
Credits: Thanks to [https://security.stackexchange.com/users/4564/dfc dfc] for [https://security.stackexchange.com/a/67142/54240 the answer on security.se]. * Does not work over Tor, because NTP uses UDP, while the Tor network does not support UDP * [https://www.ntp.org/ntpfaq/NTP-s-algo.htm Quote]:
For example standard Linux adjusts the time with a rate of 0.5ms per second.
** 500000 ns = 0.5 ms = 0.0005 s ** 1 day = 86400 s 60 s * 60 m * 24 h ** NTP can adjust the clock 43.2 s per 1 day. ** Or 1296 s (= 21.6 m) per 30 days. ** Or 15768 s (= 262.8 m) (=4.38 h) per 365 days. (4.38 h per year) == tlsdate == https://github.com/ioerror/tlsdate Pros: * uses seccomp * written by Jacob Appelbaum (security researcher; The Tor Project staff member) Due to recent news, now probably abandoned. Cons: * Only native SSL CA pinning support. No direct SSL certificate pinning support. * Does not distribute trust. As {{Code2|sdwdate}} does. https://github.com/ioerror/tlsdate/issues/112 https://github.com/ioerror/tlsdate/issues/143#issuecomment-57053323 The single time source can send wrong time replies by error or malicious intent. * Does not support hooks for user notifications about state of network time synchronization. → Users should not use the internet in {{project_name_workstation_short}} before network time synchronization has finished, and timesync informs users about this. → Implementing notifications would be difficult or require patching tlsdate. * Produces clock jumps, which confuses various applications. Does not gradually adjust as {{Code2|sdwdate}} does with [https://github.com/Whonix/Whonix/issues/169 Slow Clock Adjuster]. [https://github.com/{{project_name_short}}/sdwdate/blob/master/usr/src/sdwdate/sclockadj.c sclockadj] * Cannot connect to (most) Tor onion services, because most of those do not support SSL. Because in most cases, there is little need to combine Tor onion services with SSL. [[Onion_Services#Notes_about_End-to-end_security_of_Onion_Services|connections to Tor onion services are Tor-to-Tor encrypted by default ("not exactly end-to-end")]]. https://github.com/ioerror/tlsdate/issues/157 * Minor: {{Code2|command line parser doesn't fail closed on extraneous / unknown command line parameters}} https://github.com/ioerror/tlsdate/issues/158 - not that important in the absence of bugs, but safer behavior for {{Code2|tlsdate}} would be to fail closed on extraneous / unknown command line parameters. * Likely denial of service issue: https://github.com/ioerror/tlsdate/issues/149 == htpdate == Original. * [https://www.vervest.org/htp/ htpdate] ([https://packages.debian.org/{{Stable_project_version_based_on_Debian_codename}}/htpdate debian package]) * Detailed package status in Debian: https://packages.qa.debian.org/h/htpdate.html * unresponsive upstream [tails-dev contacted them because of their tails_htp fork - no reply] [no reply to Patrick in past] * htp=htpdate (same program as the one on rkeene.org) Tails htpdate fork * code in revision control: https://salsa.debian.org/debian/htpdate.git * Tails' reasons to fork htpdate: ** they wanted to add features such as TLS Authentication of servers ** and a source pool model. https://tails.boum.org/contribute/design/Time_syncing/#index4h1 * The htpdate implementation used by Tails is the perl one and not the C version. == Manual Time Setting == Prompts are very difficult. * GUI users: ** {{project_name_short}} users: Most laymen do not know what UTC is. Timezone/location information should also not be requested for privacy reasons. Users would have to set the time in UTC. A popup would probably say "use the clock widget and set clock in UTC", which is bad usability. ** {{kicksecure}} users: The prompt could use the timezone as defined by the user during the installer. Slightly less worse. * CLI users: ** Servers: no prompt possible for a server that reboots (such as after forced server restart). = TODO = == Consideration no TimeSync on Host == Would it be advisable to run no network time syncing daemon on the host at all? There are open questions. See:
https://forums.whonix.org/t/ntp-possible-skew-per-day-month-year/487/5 == Time Source of Time Servers == Even if we could very securely obtain the time from a server with distributed trust and everything, the question is, how do these servers themselves set their own clock? If they just use unauthenticated NTP themselves, they might not be a big help. TODO: invent sdwdate-server == Tor Consensus Method == ===== Introduction ===== '''Just an idea. Not implemented.''' Tails' [https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh {{Code2|tordate}}] ([https://tails.boum.org/contribute/design/Time_syncing/#index3h1 Guessing time based on Tor consensus]), renamed to {{Code2|[[anondate]]}} for trademark reasons and refactored to work outside of Tails provides useful bash functions to check the system clock using Tor's consensus file and Tor's log. https://github.com/{{project_name_short}}/helper-scripts/blob/master/usr/sbin/anondate Tor connects to the network. The Tor consensus file contains rough time information: since when and until when it is valid. {{Code2|tordate}} (now {{Code2|anondate}}) can provide us with a few machine readable pieces of information we can then use for whatever we may need. This is magic. 
valid-after=2014-07-31 21:00:00
valid-until=2014-08-01 00:00:00
This is simply {{Code2|/bin/date}}. 
Current time is 2014-07-31 22:44:02
Less magic. 
Current time is in valid Tor range
Less magic, but maybe useful. 
Current time is not in valid Tor range, setting to middle of this range: [2014-07-31 22:30:00]
{{Code2|anondate}} can do this by parsing Tor's verified consensus file {{Code2|/var/lib/cached-microdesc-consensus}} or by parsing {{Code2|/var/lib/tor/unverified-microdesc-consensus}}. ===== Tor Consensus Download and Verification Conditions ===== Under which conditions Tor is not able to verify the Tor consensus file? 1) If it has been tampered with by a man-in-the-middle. 2) For clocks that are more than 30 days in the past or 2 days in the future, Tor will not even be able to download a consensus. In this case anondate can parse Tor's log and report the authority's cert's valid-after date. Source, source code comment in tordate: https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh 
	# Since Tor 0.2.3.x Tor doesn't download a consensus for
	# clocks that are more than 30 days in the past or 2 days in
	# the future.  For such clock skews we set the time to the
	# authority's cert's valid-after date.

anondate --tor-cert-valid-after

Jun 16 00:00:00 2014 GMT
===== Open Questions ===== * Is the authority's cert's valid-after date signed/verified/built-into-Tor or can it be tampered with by a man-in-the-middle attack? * When the clock is more than 1 hour in the past or more than 3 hours in the future, will Tor be unable to establish circuits? https://lists.torproject.org/pipermail/tor-talk/2012-February/023264.html ===== Required Clock Accuracy for Onion Services Accessibility ===== ====== Gateway ====== Generally, computer running Tor ({{project_name_gateway_short}}): live consensus definition, quote [https://github.com/torproject/torspec/blob/master/dir-spec.txt Tor directory protocol]:
A network-status document is "live" if the time in its valid-after field has passed, and the time in its valid-until field has not passed.
reasonably live consensus definition, quote Tor directory protocol:
A reasonably live consensus is one that expired less than 24 hours ago.
How accurate does the clock have to be so onion services can be accessed? https://gitlab.torproject.org/legacy/trac/-/issues/3460 Due to issue [https://forums.whonix.org/t/most-onions-down-due-to-a-denial-of-service-attack-on-the-tor-network/10979 Most Onions Down due to a Denial of Service Attack on the Tor Network] this question received attention. Previously a live consensus was required. From Tor 0.4.5.3 and above only a reasonably live consensus will be required. ====== Workstation ====== Generally, computer running applications (such as curl or sdwdate) connecting to onions ({{project_name_workstation_short}}): Applications running on a separate computer/VM ({{project_name_workstation_short}}) can establish onion connections irrespective of an ultra slow or ultra fast system clock on that computer. That is, as long as Tor on a separate computer/VM is functional. However, that requires a correct clock as described above. ====== Summary ====== * {{project_name_gateway_short}}: Clock needs to be correct enough to be able to reach onions. * {{project_name_workstation_short}}: No clock correctness requirements for ability of reaching onions. ===== Reasons for relying solely on anondate for time setting ===== * Does not require [https://github.com/Whonix/Whonix/issues/24 SSL certificate pinning]. * Does not rely on remote web servers. * Does not require a somewhat accurate clock as Remote Web Servers Method requires to get a rough time guess. ===== anondate issues ===== Originally posted in [https://phabricator.whonix.org/T151 sdwdate Tor Consensus Time Sanity Check]: * As per [https://forums.whonix.org/t/tor-dev-mailinglist-proposal/489/10 chat log with Roger] directory authorities can lie about time - so we need to use this with care. * Tor consensus is not always downloaded directly from directory authorities, sometimes Tor downloads the Tor consensus from directory mirrors. The latter are not trusted as much as directory authorities. Those are just like normal relays. * We should have the courtesy to not explicitly download from directory authorities, because...
armadev: oh. i think that would be horrible. hundreds of thousands of users doing that could overwhelm the directory authorities.
===== Reasons against relying solely on anondate for time setting ===== * Provides only rough time. ** [[Fingerprint#For_the_websites_that_you_are_visiting|web fingerprint]] would differ from most other Tor users. ** Would cause lots of support requests complaining about skewed clocks. ** Might trouble onion services (such as hidden web servers) that need to show time to clients? ** Might trouble people attempting to [[I2P|tunnel I2P through Tor]]? ** Might cause other (gpg) verification issues? *** Debian updater APT refuses to use sources which are not yet valid. I.e. source with a signed valid-until field later than the local system clock. * Fingerprinting issues at ISP level: ** In a situation where the clock is that much off that Tor cannot establish circuits, setting time using anondate and restarting Tor are required: *** As per [[Comparison with Others#Fingerprint]], quoted from the [https://tails.boum.org/contribute/design/Time_syncing/#index5h1 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." ** Might not matter. See also [[Fingerprint#ISP_or_Local_Network_Administrators|Network Fingerprint]]. *** Related: [[Comparison with Others#Network Time related]] * Hidden services can only be accessed if the clock is no more than 30 minutes slow or fast. https://gitlab.torproject.org/legacy/trac/-/issues/3582#comment:3 * [https://gitlab.tails.boum.org/tails/tails/-/issues/5774 Tails ticket: Robust time syncing] Quote:
Currently we use tordate to set the initial clock. It is very messy and error prone, so we desperately need a robust replacement.
* Vulnerable to ISP level man-in-the-middle attacks: ** [https://tails.boum.org/contribute/design/Time_syncing/ Tails Design: Time Syncing] Quote:
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.
*** In a situation where an adversary is replaying a more than ~7 days old consensus: **** anondate could report a clock that is more than ~7 days slow. With a system clock that is that slow, Tor would no longer be able to establish circuits. But there are multiple reasons why Tor may not be able to establish circuits. So anondate could only guess, that the clock reported in Tor consensus is more than ~7 days slow, but not know with certainty. *** In a situation where an adversary is replaying a consensus up to ~7 days old: **** anondate could report a clock that is up to ~7 days slow and Tor would still be able to create circuits. **** With Tor as is at the moment, anondate cannot even in principle provide a more accurate time guess than a clock that is up to ~7 days slow. **** Using a consensus up to ~7 days old is most likely something we really should avoid? ** Therefore vulnerable to Attack 3 as per [[#Attacks]]. ===== Conclusions ===== * Relying solely on anondate for time setting is probably a bad idea. * Tor consensus time is used as a [[Sdwdate#Tor_Consensus_Time_Sanity_Check|sdwdate Tor Consensus Time Sanity Check]]. * Rough time fix. ** If clock is too much off so sdwdate cannot fix it, use anondate to get a rough time fix, then let sdwdate do the rest. ===== Why not use tordate by Tails instead of reinventing the wheel with anondate? ===== * Because Tails 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 is very messy and error prone, so we desperately need a robust replacement." https://gitlab.tails.boum.org/tails/tails/-/issues/5774 ===== Random Stuff ===== * [https://web.archive.org/web/20160629091629/https://mailman.boum.org/pipermail/tails-dev/2012-January/000822.html tails-dev mailing list: tordate: why is it safe to set time from unverified-consensus?] ** String parsing an unverified consensus using anondate is more risky [hitting hypothetical vulnerabilities in grep] than string parsing a verified Tor consensus. * Tor consensus is in some cases downloaded from Tor directory authorities and in some cases from Tor directory mirrors. The latter should not be trusted as much as the former. * https://github.com/torproject/torspec/blob/main/proposals/149-using-netinfo-data.txt {{Anchor|Status of this idea}} ===== Tor Certificate Lifetime ===== certificate lifetime 
Certificate not yet valid. Either their clock is set wrong, or your clock is wrong.
(certificate lifetime runs from Aug 27 00:00:00 2020 GMT through Aug 27 00:00:00 2021 GMT. Your time is Jan 09 07:33:33 2000 UTC.)
{{CodeSelect|code= sudo anondate --tor-cert-valid-after }} 
Aug 27 00:00:00 2020 GMT
Might be related to the following. Quote [https://github.com/torproject/torspec/blob/master/dir-spec.txt Tor directory protocol]:
Every authority has a very-secret, long-term "Authority Identity Key". This is stored encrypted and/or offline, and is used to sign "key certificate" documents. Every key certificate contains a medium-term (3-12 months) "authority signing key", that is used by the authority to sign other directory information. (Note that the authority identity key is distinct from the router identity key that the authority uses in its role as an ordinary router.)
While Authority Identity Key might be hardcoded in Tor, the certificate lifetime is likely not. Otherwise Debian (old)stable would have to ship yearly upgrades to upgrade the "Tor directory authority certificate start date" which never happens. Therefore certificate lifetime should not be trusted since it could be stale. Tor Certificate Lifetime likely has a digital software signature which gets verified by Tor. However, it is not a trustworthy source of time. It is vulnerable to replay attacks. It could be one year or older. That is because to verify its freshness, Tor requires a correct clock. For time synchronization purposes, however, the clock is assumed to be incorrect. What can be trusted, however, is that at least that time has already come. It is not a far future date because then Tor directory authorities would not have signed a Tor certificate with that lifetime yet. Related source code: https://src-ref.docs.torproject.org/tor/x509__openssl_8c.html#adcb9e22c87cb9ba135f6edf3e13386b4 Related ticket: https://gitlab.torproject.org/legacy/trac/-/issues/4370 ===== Tor Consensus Issues ===== [https://lists.torproject.org/pipermail/tor-talk/2011-January/008551.html Quote] Roger Dingledine:
Whether this is a good idea depends on where you got the consensus. If you connect to a Tor directory mirror and it hands you a consensus from last month, and you set your clock based on it, then you've opened yourself up to exactly the attack that Tor is trying to defend against.
The problem is, nowadays Tor in most cases does not download from Tor directory authorities anymore. And we ought not download the Tor consensus exclusively from Tor directory authorities. Source: https://forums.whonix.org/t/tor-dev-mailinglist-proposal/489/10
oh. i think that would be horrible. hundreds of thousands of users doing that could overwhelm the directory authorities.
https://forums.whonix.org/t/tor-dev-mailinglist-proposal/489/print ===== Fixing Time based on Tor Consensus ===== Future Implementation consideration. This is how time syncing could be performed when {{project_name_short}} starts: Credits: This is a rewrite of [https://tails.boum.org/contribute/design/Time_syncing/ Tails Time Syncing Design] # Start Tor. If Tor is already working, skip to the following anondate steps. # Let Tor fetch the Tor consensus. # (anondate related step) If the time is too badly off, the Tor directory authority certificate may not be valid, so we set the system time to the Tor directory authority certificate start date. (sudo anondate --tor-cert-valid-after) For example, see above. Which will guarantee that the Tor directory authority certificate will be valid and the Tor consensus (which includes Tor valid-until date/time) can be downloaded. # (anondate related step) Wait until Tor can tell us the Tor valid-until date/time. # (anondate related step) Set system time to Tor consensus time valid-until - 1:30. (In other words: minus 1 and 30 or minus 90 minutes.) (sudo anondate --show-middle-range) {{CodeSelect|code= anondate --show-valid-after }} 
2021-01-09 13:00:00
{{CodeSelect|code= sudo anondate --show-valid-until }} 
2021-01-09 16:00:00
{{CodeSelect|code= anondate --show-middle-range }} 
2021-01-09 14:30:00
# Wait until the Tor bootstrap process has been completed. # Use sdwdate (which exclusively uses onions as time sources) through Tor to get a more correct system time. A notification in the form of [[sdwdate-gui]] is shown while the whole process is running. Non-issues: * Use of unverified Tor consensus is not required. * The hardware clock is not affected. Security discussion: sdwdate's approach essentially removes Tor's time skew check, which is used to prevent replay of consensus data. Let's discuss this class of attacks. First, replaying a consensus older than four weeks 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 the user could anyway do this, unrelated to time, so the issue at hand boils down to replaying a consensus not older than four weeks or so. Second, the same type of attacker as above could also try to forge a completely new consensus, which would be unverifiable since the attacker doesn't have access to the authorities' keys. An attacker in that position could do denial-of-service attacks in many other ways, so this doesn't make the situation any worse. Third, things are different depending on if the user is using a bridge or not. If not using a bridge, first boot: * Tor starts without a cached consensus. * The Tor client starts by connecting directly to a [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/FallbackDirectoryMirrors fallback directory mirror] to download the Tor consensus. * Feeding a stale consensus requires the attacker either to break SSL or to control the fallback directory mirror the user's Tor client connects to. * Under these conditions the adversary could feed a stale Tor consensus up to four weeks old, which is used until sdwdate has fixed the time. * Not good, but probably a compromise we can make. If using a bridge, first boot: * Tor starts without a cached consensus. * Tor fetches Tor consensus from the bridge. * Feeding a stale consensus requires the attacker either to break SSL or to control the user's bridge. * Under these conditions the adversary could feed a stale Tor consensus up to four weeks old, which is used until sdwdate has fixed the time. * Not good, but probably a compromise we can make. If your ISP, Tor entry guard or Tor bridge, can also: * A) set up an onion MitM attack against the sdwdate onion connections, and/or * B) controls onions used by sdwdate as time sources, it can trick you into continuing to use this old consensus for max. four weeks, which is much worse. A) should be extremely unlikely. A successful MitM against a Tor onion connection has never been reported. While Tor onion servers might be vulnerable to various de-anonymization attacks, this is a different topic, this affects only the anonymity of the onion server. The client, visitor (here user's machine using sdwdate) does not have to worry about this. This also does not affect the encryption/authentication of the connection. No reports of breaking onion encryption/authentication were known at time of writing. If this was possible, this would be catastrophic anyhow. This would not make the situation any worse. B) should also be very unlikely. Onion servers targeting specific users seems very unlikely since users connect anonymously using Tor to an onion server. An attack against all users is also very unlikely since sdwdate is distributed (uses the median of 3 onion time sources), randomly chosen from the sdwdate time sources list and such an attack would be easy to notice, probably reported by users, and in response developers would remove these sdwdate time sources. In any case it should be better than using unauthenticated NTP. ===== Tor Consensus Time Setting Method Security Considerations ===== The user's local system clock being much skewed is a big issue because: * a) Stands out in javascript snooping scripts (Even if Tor Browser fixed that, other applications could leak it.) * b) Prevents Tor consensus from being downloaded leading to broken Tor connectivity. * c) Other issues discussed on top of this page, [[Time Attacks]]. It depends on the start conditions. Seems really complex. The user's clock is either: * [C]: correct * [D]: incorrect The Tor directory mirror (just normal relays) is either sending the user a Tor consensus that is: * [E]: fresh * [D]: legitimate (bug) stale * [F]: malicious (targeted attack) stale * [G]: invalid Now these are quite a few cases to combine and consider. [G] we can ignore. [D] and [F] can be regarded as approximately the same issue. user clock slow [D] + stale Tor consensus [F]: user would remain on fake Tor network user clock correct [C] + stale Tor consensus [F]: anondate would introduce a time skew. Not fix one. The user's system clock would be set to the past because the stale Tor consensus told anondate so. The worst could be prevented with a hardcoded minimum date as a safeguard but it's still a security compromise to make. user clock slow [D] + fresh Tor consensus [E]: In this case anondate would fix the connectivity/usability issue, fix a) and b). Then it also depends on how slow the user's clock is. * [H] Less than 24 hours slow clock or * [I] More than 24 hours slow clock. Therefore: * [H] + a): issue * [I] + a): no issue since no connection ===== Issues ===== The issue with looking at Tor consensus time is that after power off for a few hours (>= ~3 hours), Tor necessarily starts with a stale Tor consensus. When querying Tor consensus time (using anondate-get or otherwise), from the perspective of anondate-get the clock is fast, because Tor consensus is stale because Tor hasn't downloaded a newer Tor consensus yet. This happened up to {{project_name_short}} 16.0.3.1 after the gateway VM was offline for a few hours: 
sudo anondate-get
/usr/sbin/anondate-get: INFO: 100% Tor bootstrap, ok.
/usr/sbin/anondate-get: INFO: tor_circuit_established_check.py, ok.
/usr/sbin/anondate-get: INFO: Tor circuit already established, ok.
/usr/sbin/anondate-get: WARNING: local system time is NOT with valid time range. (valid_after: 2021-05-25 11:00:00 | middle_range: 2021-05-25 12:30:00 | valid_until: 2021-05-25 14:00:00)
/usr/sbin/anondate-get: INFO: middle_range: '2021-05-25 12:30:00'
/usr/sbin/anondate-get: INFO: time_result later than minimum-unixtime-show, ok.
2021-05-25 12:30:00
/usr/sbin/anondate-get: END: Exiting with exit_code '0' indicating 'Showed Tor consensus time middle range.'.

/usr/lib/helper-scripts/onion-time-pre-script: Start.
Static Time Sanity Check: Within minimum time 'Sun Jan 17 00:00:00 UTC 2021' and expiration timestamp 'Tue May 17 10:00:00 UTC 2033', ok.
Tor reports: NOTICE BOOTSTRAP PROGRESS=95 TAG=circuit_create SUMMARY="Establishing a Tor circuit"
Tor circuit: not established.
Tor Consensus Time Sanity Check: The clock might be too fast. Clock is faster than consensus/valid-until 2021-05-25 14:00:00.
/usr/lib/helper-scripts/onion-time-pre-script: END: Exiting with exit_code '2' indicating 'wait, show busy icon and retry.'.
The clock might be too fast. is because while the hardware clock was reasonably correct, Tor consensus time was still stale since Tor did not download a new Tor consensus yet. Approximately two minutes after VM start (Tor finished downloading a newer Tor consensus): 
sudo anondate-get
/usr/sbin/anondate-get: INFO: 100% Tor bootstrap, ok.
/usr/sbin/anondate-get: INFO: tor_circuit_established_check.py, ok.
/usr/sbin/anondate-get: INFO: Tor circuit already established, ok.
/usr/sbin/anondate-get: INFO: local system time is already within valid range, ok. (valid_after: 2021-05-25 18:00:00 | middle_range: 2021-05-25 19:30:00 | valid_until: 2021-05-25 21:00:00)
/usr/sbin/anondate-get: INFO: time_result later than minimum-unixtime-show, ok.
/usr/sbin/anondate-get: INFO: Tor certificate lifetime valid, ok.
/usr/sbin/anondate-get: END: Exiting with exit_code '4' indicating 'Setting time using anondate either not possible or not required.'.

Static Time Sanity Check: Within minimum time 'Sun Jan 17 00:00:00 UTC 2021' and expiration timestamp 'Tue May 17 10:00:00 UTC 2033', ok.
Tor reports: NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"
Tor circuit: established.
Tor Consensus Time Sanity Check: Clock within consensus parameters consensus/valid-after 2021-05-25 18:00:00 and consensus/valid-until 2021-05-25 21:00:00.
Tor already reports circuit established.
/usr/lib/helper-scripts/onion-time-pre-script: END: Exiting with exit_code '0' indicating 'success'.
Comparison: 
valid_after: 2021-05-25 11:00:00 | middle_range: 2021-05-25 12:30:00 | valid_until: 2021-05-25 14:00:00
valid_after: 2021-05-25 18:00:00 | middle_range: 2021-05-25 19:30:00 | valid_until: 2021-05-25 21:00:00
Actual time when this happened was: 
2021-05-25 18:40:00
If sdwdate had set the time to anondate-get's initial guess 2021-05-25 12:30:00 (using anondate-set), Tor connectivity would have been broken. (This issue was experienced indeed in past during experimentation using anondate-set.) Tor control protocol has no feature to query "attempting to download a newer Tor consensus done yet?" Idea: If the hardware clock is faster than valid_until, delete Tor consensus before Tor starts. (Easily implemented thanks to systemd units.) Tor would re-download the Tor consensus anyhow. This might be fingerprintable, but then again, being a user of {{project_name_short}} might be fingerprintable anyhow ([https://github.com/Kicksecure/tirdad random ISN] / [[security-misc]] network hardening). Instead of Tor starting with a stale consensus, figuring out it is stale and re-downloading one, it would go straight ahead and download a new one, which it has to do anyhow. Maybe using anondate-set to fix the clock on Whonix-Gateway only. That might mitigate introducing new fingerprinting issues inside Whonix-Workstation. And sdwdate in Whonix-Workstation should be functional anyhow as soon as Tor in Whonix-Gateway is functional. Maybe most issues with broken hardware clocks are due to them being too slow, and not too fast? Perhaps by only ever using anondate-set to move the clock into the future but never to the past, most if not all security issues can be prevented. If Tor relays send us a Tor consensus that is too new, they are in a position for denial of service anyhow. Too new is unlikely since for that, Tor directory authorities would need to be malicious/compromised. Even if that happens, it would just DOS Tor. Any TLS certificate (Debian APT) would be refused if the clock is too far in the future. Security issues with wrong system time seem to be limited to clocks that are too slow, not too fast. The latter is at worst a DOS issue. = Clock Fixing = This has been the case since a few Whonix 16 point releases ago. If Tor is running on the same machine / VM (such as Kicksecure or Whonix-Gateway): * very slow clocks can be fixed * very fast clocks cannot be fixed If Tor is running on another machine / VM (such as Whonix-Workstation): * very slow clocks can be fixed * very fast clocks can be fixed That is because Tor is not running on these machines. Once Tor is functional on Whonix-Gateway, it is easy for sdwdate in Whonix-Workstation to connect to onion time sources regardless of how far the time is skewed. = Notes = = Adjusting time slowly using adjtimex/ntp_adjtime = Under [https://github.com/{{project_name_short}}/sdwdate/pull/4 consideration] is changing the time with sclockadj2. The initial drive for this was that calling clock_settime() in the original sclockadj can result in several thousand entries in systemd's journal per invocation (can be seen with journalctrl -f) on Debian. sclockadj2 uses the adjtimex call in libc (also called ntp_adjtime) which translates to Linux kernel system call 124. This is a modal interface that is used by ntpd to change the system clock. adjtimex supports a mode with "hard" changes to the time, but those generate entries in the systemd journal, just like with clock_settime. The offset mode for adjtimex allows a change of 0.5 seconds per call (used to be ~130 milliseconds until the 2.6 kernel). The documentation of this call is incomplete, partly resulting from the limited number of clients (ntpd, chronyd) using this interface, but by tracing the kernel internals (linux/kernel/time/ntp.c and /linux/kernel/time/timekeeping.c) one can get a more complete picture, including that modern kernels support a NANO mode for easier implementation of smaller adjustments than the older microsecond based interface, without the need to do clock tick adjustment calculations. Based on this interface and mode bit definitions taken from /usr/include/linux/timex.h (more complete than the counterparts you typically find online), a Python based interface is formed via ctypes. First, set the kernel internals to handle nanosecond specifications and run in PLL mode. Then use OFFSET to adjust the time. With this call the kernel is instructed to change the time gradually. You can observe this change by making further calls to adjtimex, this time without setting any values (specified by 0 in the modes bitfield of the structure handed to adjtimex). To handle changes of more than the maximum allowed (±0.5 seconds), you need to invoke a 0.5 second change and observe if the offset has been reduced to 0, then invoke again. Writing a new offset using adjtimex will overwrite any running adjustment process, therefore you have to wait. By default the kernel uses a decreasing step size as the remaining offset approaches 0. This can be influenced by TIMECONST to start with bigger steps, or even reset the step size on a regular basis while the kernel is changing the clock according to the remaining offset. ntpd can use this offset changing possibility as is but also has a more sophisticated approach, by instructing the kernel about the drift compared to the internal clock. sclockadj2 directly uses a nanosecond offset (positive or negative) that instructs the kernel to adjust (looping multiple invocations if the absolute value of the offset > 0.5 seconds). The program has to be run as root in order to tell the kernel to make these changes (querying the status does not require this). At the start of this process a PID file is written, which is checked during loops (if running longer than 0.5 s) and will kill any previous invocation of the program. The syntax for the offset invocation is: 
sclockadj2 offset [-h] [--constant CONSTANT] [--verbose] [--quiet][--wait]  nanoseconds
For changes > 0.5s, --wait has to be specified. Increased verbosity can be used to watch the progress of what the kernel is doing with the offset. This progress can also be seen by invoking the program with the status option. Doing so has some instructional value for observing normal ntpd behaviour as well. The full options for status: 
usage: sclockadj2 status [-h] [--follow] [--set] [--verbose] [--quiet]
                         [--debug] [--wait]

adjtimex status (--quiet → only offset, --verbose → detail)

optional arguments:
  -h, --help     show this help message and exit
  --follow, -f   follow status indefinitely
  --set          set status explicitly to PLL and NANO
  --verbose, -v  increase verbosity level
  --quiet, -q    decrease verbosity level
  --debug, -D    Debug messages. Don't change date
  --wait         wait for offset to return to 0
Stopping a previous invocation of sclockadj2 (which might be looping on values > 0.5s), including stopping the internal offset, can easily be achieved by calling sclockadj2 offset 0. == Blockchain Time == * https://bitcoinmagazine.com/articles/bip-the-end-to-end-encryption-bitcoin-never-had-but-soon-will-1465401187 * https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016806.html * https://en.bitcoin.it/wiki/Block_timestamp * https://web.archive.org/web/20140213190023/http://james.lab6.com/2012/01/12/bitcoin-285-bytes-that-changed-the-world/ * https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) * https://twitter.com/_jonasschnelli_/status/1119137870592102400 **
A BIP158 based wallet rescans takes less then 5 minutes (back from genesis) on powerful consumer computer.
* https://electrum.readthedocs.io/en/latest/faq.html#does-electrum-trust-servers * https://electrum.readthedocs.io/en/latest/faq.html#i-might-run-my-own-server-are-client-server-connections-authenticated * [https://ieeexplore.ieee.org/document/8482304 Blockchain-Based Secure Time Protection Scheme in IoT] * [https://hal.univ-grenoble-alpes.fr/hal-01865259/document Secure Time Synchronization Protocol] == NTS - Network Time Security - Secure NTP == * https://fedoramagazine.org/secure-ntp-with-nts/ * https://weberblog.net/network-time-security-strengths-weaknesses/ * https://weberblog.net/setting-up-nts-secured-ntp-with-ntpsec/ * https://weberblog.net/network-time-security-new-ntp-authentication-mechanism/ **
the time data is not encrypted by NTS – but authenticated.
* https://chrony.tuxfamily.org/comparison.html * https://blog.apnic.net/2019/11/08/network-time-security-new-ntp-authentication-mechanism/ * https://www.cloudflare.com/time/ * https://blog.cloudflare.com/secure-time/ * https://blog.cloudflare.com/nts-is-now-rfc/ * https://blog.cloudflare.com/announcing-cfnts/ == roughtime == === roughtime information === * https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/ * https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/?include_text=1 * https://roughtime.googlesource.com/roughtime * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838416 * https://salsa.debian.org/lamby/pkg-roughtime * UDP * independent of TLS CAs (hardcoded keys) * server list: https://github.com/cloudflare/roughtime/blob/master/ecosystem.json * https://int08h.com/post/to-catch-a-lying-timeserver/ * https://int08h.com/post/roughtime-message-anatomy/ * https://roughtime.googlesource.com/roughtime/+/HEAD/ECOSYSTEM.md * https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL.md === roughtime client list === * https://roughtime.googlesource.com/roughtime * https://github.com/cloudflare/roughtime * https://github.com/int08h/roughenough * https://github.com/int08h/roughenough-fuzz * https://github.com/ffledgling/python-roughtime * https://github.com/dansarie/pyroughtime ** https://github.com/dansarie/pyroughtime/issues/3 * https://github.com/Merovius/notary/tree/master/roughtime * https://github.com/nahojkap/craggy * https://github.com/tajchert/securetime * https://github.com/systemd/systemd/issues/12751 * https://github.com/topics/roughtime * https://github.com/bnoordhuis/node-roughtime = Debugging = Useful to run in Qubes dom0. 
qvm-run --pass-io {{project_name_gateway_vm}} "date -u" ; date -u
= See Also = == Other == * [https://curl.se/docs/security.html List to keep track of curl advisories from the official website. Their descriptions are non-cryptic.] * [[Time Attacks]] * [[sdwdate|sdwdate - Secure Distributed Web Date - Homepage]] * [[Dev/sdwdate]] == Previous Discussion == * [https://lists.torproject.org/pipermail/tor-talk/2011-January/008551.html System time in anonymity oriented LiveCDs] * [https://web.archive.org/web/20160629151935/https://mailman.boum.org/pipermail/tails-dev/2014-August/006821.html Tails-dev mailing list - Tails htpdate - why use time information from neutral and foe pools?] * [https://web.archive.org/web/20160629152125/https://mailman.boum.org/pipermail/tails-dev/2013-February/002635.html Tails-dev Endless Data Attack and Defense] == Other Projects == * [https://tails.boum.org/contribute/design/Time_syncing/ Tails Design: Time syncing] * https://docs.google.com/a/chromium.org/document/d/1ylaCHabUIHoKRJQWhBxqQ5Vck270fX7XCWBdiJofHbU/edit == Comparison with Others == [[Comparison with Others#Network Time related|Network Time related]] == Tickets == === Qubes === ==== high priority ==== * [https://phabricator.whonix.org/T389 make sure {{q_project_name_short}} has no access to clocksource=xen] * [https://phabricator.whonix.org/T397 prevent dom0 telling {{q_project_name_short}} VMs the time] ==== normal priority ==== * document [[Advanced_Security_Guide#Spoof_the_Initial_Virtual_Hardware_Clock_Offset|Spoof the Initial Virtual Hardware Clock Offset]] for [[Advanced_Security_Guide#Qubes|Qubes]] * [https://phabricator.whonix.org/T387 {{q_project_name_short}} {{project_name_gateway_short}} as ClockVM] === others === * [https://gitlab.torproject.org/legacy/trac/-/issues/6894 torproject.org #6894 answer network time requests] * [https://tails.boum.org/todo/robust_time_syncing/ Tails Todo: robust time syncing] * https://tails.boum.org/blueprint/robust_time_syncing/ * [https://tails.boum.org/todo/safer_tordate_parameters/ Tails Todo: safer tordate parameters (always use tordate)] * [https://tails.boum.org/todo/bridge_mode_vs_tordate_timeouts/ Tails Todo: bridge mode vs tordate timeouts] * [https://tails.boum.org/todo/when_htp_fails_the_user_should_be_prompted/ Tails Todo: when htp fails the user should be prompted] * [https://github.com/QubesOS/qubes-issues/issues/2342 Qubes: secure time synchronization] * [https://gitlab.torproject.org/legacy/trac/-/issues/16659 Linux TCP Initial Sequence Numbers may aid correlation] * [https://gitlab.torproject.org/legacy/trac/-/issues/8170 get independent from host clock time / insecure NTP] == Clock Correlation Attack == === Attack === Prerequisite knowledge: * {{project_name_gateway_short}} [Proxy]VMs and {{project_name_workstation_short}} [App]VM's system time cannot be obtained by watching traffic at ISP level. * This chapter is not about tracking a single VM across its different Tor exit relays. * The context is anonymity. The significance is deanonymization. * In anonymity we do not just care about correlations. We also care about estimations, anonymity set reduction, and partitioning users. This is already a success, because it may be combined with other guesses. No direct proof is required. From some countries, there are just a few 100 users or less. If there is already a lead by country, then combined with these time related issues, things begin to really matter. * clocksource 'xen' / 'kvmclock' does not prevent {{project_name_short}} from using sdwdate. * clocksource 'xen' / 'kvmclock' does not prevent each VM from having slightly different system time (used by all the applications), so no direct leaks here. * [host | dom0] host time and VM times are very, very similar. At most one second difference. Or less. In [host | dom0], see: 
date ; qvm-run --pass-io sys-net date
Attack: * 1) requires a) compromise a {{project_name_workstation_short}} VM and b) observing the ISP network the user is using * 2) read [host | dom0] time using clocksource 'xen' / 'kvmclock' or possibly the wall clock interface * 3) [host | dom0] time will be very similar to NetVM's time (the system where external network connections are made) * 4) correlate {{project_name_workstation_short}} VM with NetVM's time * 5) anonymity set reduction done Notes: No need to compromise multiple VMs. Only one VM, a {{project_name_workstation_short}} VM, needs to be compromised. NetVM does not have to be compromised. It leaks in most cases - hard to avoid all cases - any passive ISP level adversary watching traffic can read the client's local clock. It is leaked on many levels, see [[#Local Clock Leaks]]. Threat Model: * {{project_name_workstation_short}} AppVM gets compromised up to local root code execution. Then the attacker uses the local exploit, reads clocksource 'xen' / 'kvmclock'. === Defense === We need to make sure that all of {{project_name_gateway_short}}, {{project_name_workstation_short}}, and NetVM use slightly different time. Even if {{project_name_workstation_short}} would be compromised, and the attacker gets knowledge of the time of [host | dom0] and sniffs NetVM's time, it would hinder correlation. [host | dom0] and non-anonymous VMs' clocks should be as synchronized, correct and secure as they can be. But those should differ from the clocks within {{project_name_short}} VMs. We need completely isolated virtual time within {{project_name_short}} VMs. https://security.stackexchange.com/questions/106406/how-to-get-a-completely-isolated-virtual-time-using-xen https://lists.xen.org/archives/html/xen-users/2015-11/msg00114.html === wallclock ===
The other interface ("wallclock interface") would provide such time, though. And it is not configurable. But not sure if it is used anywhere in Linux by default (probably besides initial system time set).
Yes. Must be so. Otherwise with "ticks" alone the VM would have no chance to figure out the current time. And this is a problem, because we do not want the VM to know [host | dom0]'s time. We might be able to solve the wallclock [not pvclock] issue by [[Advanced_Security_Guide#Spoof_the_Initial_Virtual_Hardware_Clock_Offset|Spoofing the Initial Virtual Hardware Clock Offset]]. === Development === Rather than modifying [host | dom0]'s clock, we could perhaps spoof the initial virtual hardware clock offset. It is possible for KVM, as per: https://libvirt.org/formatdomain.html#time-keeping Something like this:
Reading clocksource xen as a [root] user is not easily possible. source: https://lists.xen.org/archives/html/xen-users/2015-08/msg00020.html Would probably require writing a kernel module. * [https://phabricator.whonix.org/T440 set random clock offset for {{q_project_name_short}} VMs using mgmt to prevent clock correlation attacks] * [https://phabricator.whonix.org/T389 make sure {{q_project_name_short}} has no access to clocksource=xen] * https://groups.google.com/g/qubes-devel/c/aN3IOv6JmKw === Sources === * https://groups.google.com/g/qubes-devel/c/aN3IOv6JmKw * Document with general information on various clock interfaces. ** Not very specific to KVM. ** PIT, RTC, APIC, HPET, Offboard Timers, TSC ** https://www.kernel.org/doc/Documentation/virtual/kvm/timekeeping.txt == TSC == Needs more research. Why we should avoid leaking TSC from the host to the VM. Leaking anything related to time from the host into the VM [or from VM to VM] risks cryptographic side channel attacks and should therefore be avoided. Search term:
time stamp counter tsc side channel Leads to:
https://blog.cr0.org/2009/05/time-stamp-counter-disabling-oddities.html TSC leaks may be similar to TCP sequence numbers. https://gitlab.torproject.org/legacy/trac/-/issues/16659#comment:10 == clocksource xen == https://github.com/QubesOS/qubes-issues/issues/1764#issuecomment-195619793 == Resources == * [https://web.archive.org/web/20170701134458/https://software.intel.com/en-us/blogs/2013/06/20/eliminate-the-dreaded-clocksource-is-unstable-message-switch-to-tsc-for-a-stable General information on various clock sources such as TSC, etc. by Intel] == Footnotes == = License = {{License_Amnesia|{{FULLPAGENAME}}}} {{Footer}} [[Category:Design]]