MOX A - ntp servers

Software SW help
1

I have a newly installed MOX A and neither in Luci nor in Foris I can’t see the possibility to set ntp servers. Where and how can I change them?

image
image824×593 21.5 KB

1 Like
2

Change ntp server … why ? You are detecting inaccurate time ?

3

Does It really matter what the motivation is?

time being only via ssh

settings stored in /etc/config/system 
config timeserver 'ntp'
	list server '217.31.202.100'
	list server '195.113.144.201'
	list server '195.113.144.238'
	list server '2001:1488:ffff::100'
	list server 'ntp.nic.cz'
	list server '0.openwrt.pool.ntp.org'
	list server '1.openwrt.pool.ntp.org'
	list server '2.openwrt.pool.ntp.org'
	list server '3.openwrt.pool.ntp.org'
	option enabled '1'
	option enable_server '0'
3 Likes
4

Because I thought this was “free software” and I could change anything I needed. :slight_smile:

Almost every cheap router provides this option. That it can not be done through Luci or through Foris is a shame.

5

Thank you, I managed to change them to the servers I prefer.

6

Thank you from and answering my question. I am a old man. I hate to change things for no reason. Or otherwise - if it works, so don’t correct it … :slight_smile:

7

I understand. This phase has not yet happened to me. I still do not have everything set up as I wish. As soon as I get it, then I’ll use your strategy and do not touch it until it works. :wink:

3 Likes
8

LuCI → System → System

There, you are able to delete the NTP servers beside SSH, at least that is possible with Turris OS 4.0.3, now one year later.

I am not so happy with that list either:

  • The first and fourth IP addresses are ntp.nic.nz, actually. I guess, pure IPs where chosen not to run into an race condition with DNS-over-TLS (DoT); if you have chosen a DNS provider in Foris with ‘TLS’ in its name. That fourth IP address is an IPv6 and is for IPv6-only networks.
  • The second and third IP addresses are tik.cesnet.cz and tak.cesnet.cz actually. Consequently, those are backup servers.
  • I am really unhappy about that NTP pool addresses. Each domain (each number) gives four alternatives already. So those are 16 addresses actually. Therefore, I do not see a reason to specify the pool four times. Furthermore, only one number – 2 – is IPv6 enabled …

Consequently, please Turris team, consider to narrow down that list. Especially the two CESNET and three (0, 1 and 3) of that NTP pool should be of no help for anyone. I would even remove that ntp.nic.cz because 2.openwrt.pool.ntp.org provides the same. That would it narrow down to:

  1. 2001:1488:ffff::100 (give tooltip that it is AAAA of ntp.nic.cz)
  2. 217.31.202.100 (give tooltip that it is A of ntp.nic.cz)
  3. 2.openwrt.pool.ntp.org

I guess, this is much more convincing for those being data-privacy savvy. Finally, Turris OS could read the DHCP option and go for that IP already. Then, this whole wizard page is not needed, when DHCP worked.

9

Actually DNSSEC validation is even more sensitive to correct date+time than TLS. And that’s turned on by default, contrary to DoT.

10

That is not such a good idea. We need more than just one IP address (per version) there to ensure that we do not rely with router functionality on single server. Note that those addresses are there for years to come and when you reset to factory it might be years old. In those year servers can be moved, obsoleted and so on… do not put all eggs in single basket.

It is needed as DHCP can possibly be miss configured and so it should not be more than default. That means practically that timezone and NTP servers configuration still has to at least approved. That makes no difference I think so.

1 Like
11

vcuncat, the question is whether DNSSEC actually needs the correct start time. In other words: Does the system gain any added security if not-yet-valid is checked in DNSSEC?

Sure. And? Furthermore, a DHCP option exists for the timezone. It is up to you to present the user a double-check. Or whether he goes to the Time pane later while troubleshooting. I just outlined the possibilities this gives.

I posted my rationale why the list should be narrowed down. Furthermore, I extracted all the purposes, I was aware of. From that, I created a list and order which still fulfills all that purposes. If you have something to say, provide a rationale and/or purpose I missed, against my list.

12

When you experience not-yet-valid, your clock is typically way behind. That means you have no idea if what appears to you as not-yet-valid is actually long expired. As it is now, the standards for validation don’t allow tolerating not-yet-valid signatures, and so far I don’t see sufficient reason to disable that (and still call it validation), cetrainly not by default.

13

Way before, isn’t it? The question is if this is explicitly forced in the standard for sure, and then why. I am not current on the debate of this chicken-egg problem. If security is not usable, people do not use it. If checks do not give any added security, they should be questioned.

14

Yes, clock being “in the past”.

RFC 4035 is quite explicit about this (MUST is the strongest requirement). I’m not aware of this being unusable – the current Turris approach is to specify NTP servers directly through IP addresses; I can imagine alternatively resolving NTP names without validating DNSSEC, e.g. a script can use dig +cd +short example.org.

The interesting question here is how to better secure the time-synchronization protocol. I recently saw some proposal in IETF improving this (without changing the protocol itself IIRC), so hopefully that will get to practice soon if it hasn’t happened already. The protocol is still unavoidably vulnerable to attackers controlling the wire though, so there is certainly more room for improvement over the long term; it seems quite hard in principle.