{{Header}}
{{#seo:
|description=Time Related Security Issues and Solutions
|image=Clock-359985640.jpg
}}
{{time_mininav}}
[[File:Clock-359985640.jpg|thumb]]
{{intro|
Time Related Security Issues and Solutions
}}
= Time Attacks =

Insecure time synchronization and the leaking of time data exposes the user to a subset of [[Advanced_Deanonymization_Attacks|advanced deanonymization attacks]]. The attack vectors and possible mitigations are described below.

== Attack Vectors ==

'''Table:''' ''Time Attack Vectors''

{| class="wikitable"
|-
! scope="col"| '''Attack Vector'''
! scope="col"| '''Description'''
|-
! scope="row"| Application-level Traffic
| Unlike privacy software developed by The Tor Project, Internet-facing applications can leak clock information in their traffic; for example, JavaScript in browsers and timestamps in emails.
|-
! scope="row"| Denial of Service
| The UDP-based NTP protocol can be abused to cause much larger replies than normal, causing systems to be overwhelmed. These are known as amplification attacks. <ref>See [https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-using-it.html Don't update NTP - stop using it] and [https://netpatterns.blogspot.com/2016/01/the-rising-sophistication-of-network.html The Rising Sophistication of Network Scanning].</ref>
|-
! scope="row"| Locating Onion Services
| Timers can leak CPU data. Under some circumstances, related activity data can lead to deanonymization of an onion service: <ref>
* [https://murdoch.is/papers/ccs06hotornot.pdf Hot or Not: Revealing Hidden Services by their Clock Skew]
* [https://web.archive.org/web/20220515221639/http://caia.swin.edu.au/talks/CAIA-TALK-080728A.pdf An improved clock-skew measurement technique for revealing onion 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://netpatterns.blogspot.com/2016/01/the-rising-sophistication-of-network.html The Rising Sophistication of Network Scanning]
</ref>
|-
! scope="row"| Remote Code Execution
| NTP is a buggy and ancient protocol. Flaws in NTP clients can be remotely exploited to allow an adversary control over the system. The unencrypted and unauthenticated nature of NTP makes this attack trivial for network adversaries of any size. <ref>https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-using-it.html</ref> <ref>https://www.cvedetails.com/vulnerability-list/vendor_id-2153/NTP.html</ref>
|-
! scope="row"| Remote Device Fingerprinting
| Clock leaks arising from either software on the host or application-level protocols on {{project_name_workstation_long}} (<code>{{project_name_workstation_vm}}</code>) allow a passive adversary to easily link anonymous and non-anonymous traffic to the same machine. Active clock skew attacks can be trivially mounted to deanonymize users. <ref>See https://catalog.caida.org/details/paper/2005_fingerprinting and Tor Browser upstream bug #3059 for the kind of application-level leaks that can happen: [https://gitlab.torproject.org/legacy/trac/-/issues/3059 Find some way to deal with time-based fingerprints].</ref>
|-
! scope="row"| Replay Attacks
| Replaying an older time allows an adversary to: <ref>
This is possible because cryptographic verification depends on an accurate system clock. For example, a clock set to two years in the past will accept certificates or updates which have already expired or been revoked.</ref>
* Feed an old Tor consensus. <ref>https://tails.boum.org/contribute/design/Time_syncing/</ref>
* Provide updates and (https) certificates which are old, outdated, or have known vulnerabilities.
|}

== Clock Leak Vectors ==

Certain protocol properties leak clock information.

'''Table:''' ''Clock Leak Vectors'' <ref>https://web.archive.org/web/20220324134410/http://caia.swin.edu.au/talks/CAIA-TALK-080728A.pdf</ref>

{| class="wikitable"
|-
! scope="col"| '''Leak Vector'''
! scope="col"| '''Description'''
|-
! scope="row"| ICMP Timestamps
| Leak host time in query replies. <ref>https://web.archive.org/web/20120626055435/http://www.networksorcery.com/enp/protocol/icmp/msg13.htm</ref>
|-
! scope="row"| NTP Clients
| Leak host time <ref>https://gitlab.torproject.org/legacy/trac/-/issues/16659#comment:13</ref> and expose the system to every attack outlined above.
|-
! scope="row"| TCP Initial Sequence Numbers (ISNs)
| Even when timers do not fully leak the host's clock, they can allow side-channel attacks because sensitive information about a system's CPU activity is leaked. <ref>
https://gitlab.torproject.org/legacy/trac/-/issues/16659#comment:10
</ref> This information is leaked in any traffic sent over clearnet. It can therefore be linked to maliciously induced load patterns on an onion site, resulting in deanonymization. <ref>
https://gitlab.torproject.org/legacy/trac/-/issues/16659
</ref>
|-
! scope="row"| TCP Timestamps
| Included in every TCP packet, these leak system information down to the millisecond, as well as system uptime. They also permit fingerprinting of devices behind a router. <ref>https://web.archive.org/web/20170201160732/https://mailman.boum.org/pipermail/tails-dev/2013-December/004520.html</ref>
|}

= Mitigations =

It is practically possible to block all of the clock leak vectors in the preceding section. Users running onion services or those who require very high-level security are strongly recommended to apply the measures below.

== GNU/Linux Host ==
{{Box|text=
<div class="toccolours mw-collapsible mw-collapsed">
'''1.''' Uninstall any NTP clients and disable systemd's timdatectl NTP synchronization feature. <ref>
https://www.freedesktop.org/software/systemd/man/timedatectl.html
</ref>
<div class="mw-collapsible-content">
* {{Kicksecure}} users note: No changes required because {{Kicksecure}} does this by default.
* Other operating systems: These follwing steps are useful for better security.

{{CodeSelect|code=
sudo timedatectl set-ntp 0
}}

or

{{CodeSelect|code=
sudo systemctl disable systemd-timesyncd.service
}}
</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
'''2.''' Disable TCP timestamps via kernel sysctl.

This boolean disables both IPv4 and IPv6 TCP timestamps since they are controlled by the same sysctl option.
<div class="mw-collapsible-content">
({{Kicksecure}} does this by default.)

The following line must be added to {{Code2|/etc/sysctl.conf}} or {{Code2|/etc/sysctl.d/tcp_timestamps.conf}}

{{CodeSelect|code=
net.ipv4.tcp_timestamps = 0
}}

To make this change, run.

{{CodeSelect|code=
echo "net.ipv4.tcp_timestamps = 0" {{!}} sudo tee /etc/sysctl.d/tcp_timestamps.conf
}}

To apply the sysctl settings without rebooting, run. Either command A or B.

* A) {{CodeSelect|code=
sudo sysctl --system
}}
* B) {{CodeSelect|code=
sudo systemctl restart procps
}}

Check the setting was applied correctly.

{{CodeSelect|code=
sudo sysctl --all {{!}} grep net.ipv4.tcp_timestamps
}}
</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
'''3.''' Block incoming ICMP messages and any other incoming traffic with iptables or any of its frontends, such as ufw. <ref>
https://www.digitalocean.com/community/tutorials/how-to-setup-a-firewall-with-ufw-on-an-ubuntu-and-debian-cloud-server
</ref>
<div class="mw-collapsible-content">
{{CodeSelect|code=
sudo apt install ufw
}}
{{CodeSelect|code=
sudo ufw enable
}}
{{CodeSelect|code=
sudo ufw default deny incoming
}}

To check the status of ufw, run.

{{CodeSelect|code=
sudo ufw status
}}
</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
'''4.''' TCP Initial Sequence Numbers mitigation.
<div class="mw-collapsible-content">
({{Kicksecure}} does this by default.)

An artificially induced CPU-load temperature influences the timer crystal and skews its frequency. TCP ISNs are a permanent feature and are necessary from a security standpoint to prevent arbitrary TCP connection hijacking by non-global network adversaries. <ref>
https://web.archive.org/web/20230327143145/https://blog.patternsinthevoid.net/cve-2016-5696-and-its-effects-on-tor.html
</ref> See the following reference about removing the timer output function from Linux's TCP ISN code. <ref>
[https://web.archive.org/web/20180626110552/http://sec.cs.ucl.ac.uk/users/smurdoch/talks/eurobsdcon07hotornot.pdf - slide 9]
</ref> [https://forums.whonix.org/t/tcp-isn-cpu-information-leak-protection-tirdad/8552 TCP ISN CPU Information Leak Protection - tirdad]
</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
'''5.''' Application-level mitigation.
<div class="mw-collapsible-content">
For application-level leak mitigation, avoid sending any clearnet traffic. Without clock information leaking from the host, network adversaries do not have non-anonymous timestamp sources to match this data with, even if software on {{project_name_workstation_short}} (<code>{{project_name_workstation_vm}}</code>) misbehaves.
</div>
</div>
}}

{{anchor|#mitigations}}

== {{project_name_long}} Solutions and Limitations ==

{{project_name_short}} has implemented [[sdwdate]] as a secure time synchronization mechanism to replace NTP. <ref>https://github.com/{{project_name_short}}/sdwdate</ref> sdwdate-gui <ref>https://github.com/{{project_name_short}}/sdwdate-gui</ref> is the GUI front-end. sdwdate was written with safety in mind and to avoid the many security pitfalls in NTP. Furthermore, NTP is UDP-based and cannot work over Tor, and onion services must have an accurate clock to be reachable.

sdwdate fetches its time exclusively from reputable sources -- whistle-blowing and privacy-friendly onion sites -- that are very likely to be hosted on different hardware. sdwdate also benefits from the security of Tor's end-to-end encryption.

sdwdate can only protect against passive timestamp linkage of data leaking from both the host and {{project_name_workstation_short}} (<code>{{project_name_workstation_vm}}</code>). It cannot defend against a skilled adversary that is able to compromise {{project_name_workstation_short}} (<code>{{project_name_workstation_vm}}</code>). Via a [[Dev/TimeSync#Clock_Correlation_Attack|clock correlation attack]], the adversary would discover the host clock when the VM is rebooted, and then link the time readings with any host clock leaks. The only way to prevent this and similar attacks is to stop the leaks in the first place.

In the unlikely event that [[Sdwdate|sdwdate]] fails to properly randomize the system clock, it is possible to manually set a random value, see: [[Boot_Clock_Randomization#Manual_Boot_Clock_Randomization|Manual Boot Clock Randomization]].

TCP ISN CPU Information Leak Protection using [https://github.com/Kicksecure/tirdad tirdad] <ref>
https://bitguard.wordpress.com/2019/09/03/an-analysis-of-tcp-secure-sn-generation-in-linux-and-its-privacy-issues/
</ref>. --> https://forums.whonix.org/t/tcp-isn-cpu-information-leak-protection-tirdad/8552

= See Also =
* Forum discussion: [https://forums.whonix.org/t/time-attacks-wiki-page/1260 Time Attacks wiki page].
* Developer page: [[Dev/TimeSync]].

= Footnotes =
{{reflist|close=1}}
{{Footer}}
[[Category:Documentation]]