diff options
Diffstat (limited to 'mds/NTP.txt')
| -rw-r--r-- | mds/NTP.txt | 144 |
1 files changed, 137 insertions, 7 deletions
diff --git a/mds/NTP.txt b/mds/NTP.txt index 8060191..ebb7997 100644 --- a/mds/NTP.txt +++ b/mds/NTP.txt @@ -1,7 +1,7 @@ -== After NTP Comes NTS +== After NTP Comes NTS. After NTS comes sdwdate. Well for this one I will be talking a bit about NTP and NTS. Unlike the -DNS post there isnt much going on here. +DNS post there isn’t much going on here. NTP is plain-text, NTS uses TLS so if our requests are tampered with, we can know. There is the ``oooh, you cant see what I’m sending now'' but @@ -19,6 +19,9 @@ tampered with * REQ-003: It should not be known which time servers are being used upstream by the client +If you are wondering why any of this even matters you can have a look +https://www.whonix.org/wiki/Time_Attacks[here]. + Now talk about the problem. The protocol is fine. We are sending TCP with TLS here. That’s brilliant. We get all this: @@ -34,7 +37,7 @@ with TLS here. That’s brilliant. We get all this: * Performance: NTS must not significantly degrade the quality of the time transfer. The encryption and authentication used when actually transferring time should be lightweight. .... -exerpt from https://www.rfc-editor.org/rfc/rfc8915[RFC 8915] +Excerpt from https://www.rfc-editor.org/rfc/rfc8915[RFC 8915] If we find a client that lets us use a SOCKS5 proxy, then we can send our NTS requests over Tor and then call it a day. REQ-002 and REQ-003 @@ -51,7 +54,7 @@ SOCKS5 proxies. * for ntpd-rs look https://github.com/pendulum-project/ntpd-rs/discussions/1365[here] -Which menas our setup is not complete. +Which means our setup is not complete. === Implementation @@ -106,7 +109,7 @@ listen = "10.167.131.1:123" listen = "[::1]:123" ---- -[source,config] +[source,conf] ---- nts enable nts key /etc/letsencrypt/live/nts.dehein.org/privkey.pem @@ -169,15 +172,142 @@ volumes: vault: ---- +=== What comes after NTS + +Above we looked at NTP and NTS. We failed to find a client that supports +SOCKS5 but that’s a trivial matter. What is not trivial, however, is how +NTS and NTP work, and by that I mean you will still have to ask a server +to tell you the time. Doing so over Tor or other anonymizing networks +should be fine but we can choose to try out another method of doing +things. Enter `sdwdate` + +==== sdwdate + +It still has the same flaw as NTP/NTS as in we still have to trust a +server not to lie +https://www.kicksecure.com/wiki/Sdwdate#sdwdate_Source_Pools[please look +here]. Personally, It is a bit of a disappointment that the protocol +that’s supposed to be oh-so-much-shinier and newer than NTP has the same +flawed mechanism as NTP. Now granted having hardware that tells you the +time so that you can share that with everyone else is not something +trivial or readily-available but this only makes sdwdate desirable in +the absence of an NTS client that support SOCKS5 proxy. Once that is +done, the larger user pool of NTS/NTP will offer more protection against +the smaller userbase of sdwdate. sdwdate gives a table of comparison +between itself and NTP. Let’s take at look at that: + +Let’s take a look at `sdwdate`. It is a roller-coaster. And I do mean +that. So don’t make up your mind until the very end. There is a +comparison between NTP and sdwdate made +https://www.kicksecure.com/wiki/Sdwdate#Sdwdate_vs_NTP[here] by +kicksecure themselves. + +[cols=",,",options="header",] +|=== +|category |sdwdate |ntp +|written in memory-safe language |Yes |No +|distributed trust |Yes |No +|secure connection by default |Yes |No +|gradual clock adjustments |Yes |Yes +|daemon |Yes |Yes +|functional over tor |Yes |No +|tor not required |No |Yes +|client, time fetcher |Yes |Yes +|Server, time provider |No |Yes +|AppArmor profile |Yes |Yes +|systemd security hardening,seccomp |Yes |? +|drop-in config folder |Yes |No +|proxy support |Yes |No +|possible to secure by default on GNU/Linux distribution level |Yes |No +|secure |Yes |No +|optional GUI |Yes |No +|=== + +* memory-safety: I mean its good and all that sdwdate uses a memory-safe +language(python) but NTP is a protocol. Not sure how NTP is bound to a +single programming language. The one client we mentioned before uses +rust which guarantees memory safety. +* secure connection by default: NTS uses TLS v1.3 . Not sure why sdwdate +is being compared against NTP and not NTS. +* functional over Tor: again, NTS uses TCP which can pass through a +SOCKS5 proxy as is implemented by the current incarnation of Tor. Also, +not sure, but are we comparing against the NTP protocol or a specific +implementation? +* Tor not required: what if I want to use +https://github.com/PurpleI2P/i2pd[i2p] or +https://github.com/yggdrasil-network/yggdrasil-go[yggdrasil] to sync +time over? Why does it have to be Tor? +* apparmor profile: not sure why this is even included. You can write +one for NTP implementations. +* systemd security hardening, seccomp: same as above. You can do it for +NTP/NTS implementations as well. +* drop-in config folder: what’s a folder? Is that supposed to be a +directory? Second, what does that even mean? And third, who is writing +these? The only kind of people who make this sort of mistake are people +who use MS Windows more than Linux. This is official kicksecure +documentation. You have Windows users writing these for the ultra secure +and hardened ``Linux'', I’ll say it again, ``Linux'', distro? +* proxy support: again, NTS uses TCP so it supports SOCKS5 proxies as +well but for whatever reason we are comparing against NTP(though whether +we are comparing against the protocol or an implementation is something +left to be decided by the next generation of humans) +* possible to secure by default on GNU/Linux distribution level: whats +the GNU/Linux distribution level? What does this even mean? You can +secure it on the OS level? I mean it’s software so I would hope that it +would be possible to secure it on the software level. +* secure: what are the criteria? Secure against what? And again, why are +we comparing to NTP and not NTS? +* optional GUI: again not sure why we keep zig-zagging between comparing +implementations and the protocols. In conclusion, why is that table even +there? What purpose does it even serve? + +If we were going to base our judgement on the documentation provided on +kicksecure’s website, I am sorry to say that `sdwdate` does a very poor +job but fortunately that’s not all there is to it. + +Now let’s go take a look at the github README for the project: + +[source,txt] +---- +At randomized intervals, sdwdate connects to a variety of webservers and extracts the time stamps from http headers (RFC 2616)) +---- + +This is our first spark of brilliance. The second spark is when we +consider the practical meaning of only being able to use Tor v3 +addresses. Like a wise man once said: + +[source,txt] +---- +amateurs practice something until they can get it right. pros practice something until they can't get it wrong. +---- + +The result of using only Tor v3 addresses is that you cannot leak your +real IP address no matter what happens. You either have a working Tor +proxy in which case the IP address will be that of the exit node or none +at all. + +Now we know we definitely are dealing with a very promising solution. +`sdwdate' extracts the time stamp in the http header so we are not +asking a known NTP server about the time, we are just doing a normal +http request. + +=== DISCLAIMER + +Although unrelated, it is worth noting that the kicksecure docs are +pretty good even if you are not planning on using kicksecure. + === Links * https://www.rfc-editor.org/rfc/rfc8915[RFC 8915] * https://github.com/jauderho/nts-servers[Here] you can find a list of publicly available servers that support NTS +* https://github.com/Kicksecure/sdwdate[sdwdate’s github page] +* https://www.kicksecure.com/wiki/Sdwdate[sdwdate doc] +* https://www.rfc-editor.org/rfc/rfc2616[RFC 2616] -timestamp:1709418680 +timestamp:1713478033 -version:1.0.0 +version:1.1.0 https://blog.terminaldweller.com/rss/feed |