Hi
On Linux (Ubuntu) I had just installed Chrony and entered server time.cloudflare.com nts to /etc/chrony/chrony.conf
This forces system to ask time via NTS (TLS) so nobody can intercept or spoof it.
The main question:
How can I do something similar on my GL.iNet GL-MT3000 (firmware 4.8.2 OP24)
While waiting for something new to be enabled on your router, you could always just point your router to your local NTS server using NTP and get on down the road.
I don't have local server. And no ability to get some. Because I have only 2 laptops and phone.
I think it is better that Gl.iNet will make this official. For example Chrony is tiny. If they don't want to use chrony - ntsproxy or ntpsec should do the trick. But they must be built into firmware.
If you afraid of getting one fail point with cloud-based time here is more NTS providers:
time.cloudflare.com
ptbtime1.ptb.de
nts.netnod.se
Can you escalate this to RD?
I don’t have my MT3000 out, but they do have chrony-nts available for the flint3 in the repo. Should be easy enough to add yourself. It is under Applications, Plug-Ins. You will need to configure via CLI as there is not a LuCi package for it in the repo. Apologies if this package is not in the MT3000 repo.
BTW, I am not a gl-inet employee just for clarification. Just a user like you.
Hello,
The MT3000 warehouse already has the plug-in chrony-nts.
chrony-ntsopkg update && opkg install chrony-nts
uci set chrony.@pool[0].hostname='time.cloudflare.com'
uci set chrony.@pool[0].iburst='1'
uci set chrony.@pool[0].nts='1'
uci set chrony.@nts[0]=nts
uci set chrony.@nts[0].systemcerts='yes'
uci commit chrony
sysntpd, and enable and start chronyd/etc/init.d/sysntpd stop
/etc/init.d/sysntpd disable
/etc/init.d/chronyd enable
/etc/init.d/chronyd restart
chronyd service is runningroot@GL-MT3000:~# ps | grep chrony
3466 chrony 11560 S /usr/sbin/chronyd -n
3693 root 1244 S grep chrony
root@GL-MT3000:~# chronyc tracking
Reference ID : A29FC801 (time.cloudflare.com)
Stratum : 4
Ref time (UTC) : Tue Oct 28 02:18:31 2025
System time : 0.000367018 seconds fast of NTP time
Last offset : -0.000024226 seconds
RMS offset : 0.003804589 seconds
Frequency : 248.701 ppm slow
Residual freq : +0.076 ppm
Skew : 13.510 ppm
Root delay : 0.145475194 seconds
Root dispersion : 0.003369628 seconds
Update interval : 128.4 seconds
Leap status : Normal
For feature request, I will collect this request first, but we still need to evaluate it.
Do I need to change anything in LuCi? Because now it points to regular NTP
Thanks!
But this seems to be very logical, since in sketchy open networks (where for example Beryl designed to work) it can be any type of attack.
I think they should support either NTS or time via DNS. Since it is indeed trivial to spoof NTP.
Better use this config from Graphene OS for chrony
I agree with OP. Since Gl is for security oriented people, this should be implemented
Not required. Because in the command provided above, the sysntpd (NTP) has been disabled
As i read it is bad idea to have only one server
So some servers can be taken from here
I wrote [SCRIPT] [Help needed] NTS setup
Welcome anyone who wants to help with testing and debugging
It looks legit, but I still wanna get staff opinion if this is safe to run. I don't want to brick router. But many thanks!
It is indeed legit. But I tested my script only on OP24.
I also tested it on op24 firmware, and it is reliable.
I think other firmwares can run safely as long as they can install chrony-nts and disable the system pre-installed sysntpd.
We are evaluating replacing NTP with NTS, which comes pre-installed on the system.
@bruce This would be a great update as chrony is solid, and chrony-nts supports standard ntp connections as well.
Thank you for your feedback!
Regular NTP is generally useless. It is like using HTTP instead of HTTPS. C'mon it is 2025.
I personally had situations (i was traveling), when ISP intercepted NTP when it detected DoT to prevent user from bypassing DNS based blocking.
GL team should force NTS by default. I don't think even other options should be.
Actually, even plain DNS is bad. Because, once more, there are some ISPs who abuse their power and record/intercept such connections. By the way, I will open separate request for encrypted DNS by default.
Callign NTP useless indicated a very myopic view of the world. Lots of us support larger networks as part of our day job. NTP is still the. most ubiquitous protocol in use for syncing time. DNS is the same way. Once you get into enterprises, and even more so OT environments, newer protocols are often not supported.
I understand your sentiment, but the world is much larger than your view suggests.
I am managing two AMD EPYC servers. They are located physically in my house. So...
Mostly, my servers used for my personal website, email and Tor nodes
And this is extremely bad. Because for example my ISP after looking through traffic, tried to kill my web-tunnel moat by spoofing NTP.
So, luckily, I am Linux user (both servers and desktop) so installing Crony wasn't hard.
But my main idea of post is that using unencrypted protocols will (it is a matter of time when exactly) cause you trouble. At least you will need to blindly trust your ISP not to poison or MITM anything.
Moreover, back to routers. Crappy networks uses DNS MITM (and some MITM port 80 and NTP) to enforce Captive Login to make it "unbypassable" (won't help, i even have script against such network tricks). Another situation is hotel/ship/college crappy network filters that uses same tricks to block even unknown VPN IP.
Generally it will be excellent if everything will be routed through TLS. It will make life for censors and attackers much harder.
I am saying that based on my experience
Not everyone who uses GL is using them just at home. But even for home users, if they set a default as you suggest and things don’t work quite right - users will be calling GL support for help. However, if they simply use commonly supported protocols, especially like legacy DNS rather than introducing another point of failure with another provide, it can head off headaches for all involved. If your ISP needs you to use their DNS for account registration (cable modem providers often do this) using one of their internal dns servers, and it fails because of a non-standard default setting on equipment, who will they call? Making it available for people like you to change to secure is the right answer, but setting all of these defaults would be a mistake imo. This is why I said your view on this seemed limited. You are only looking at it from a technical end-user PoV only.