Some ISP abuses their abilities and intercept DNS traffic. This can be abused in several ways like: DNS based censorship, unauthorized data recording or even altering web server. Last one especially effective with NTP spoofing since user will get cert errors on all websites and will probably just ignore them, thinking it is problem on his end.
So I recommend to enable DoH by default or DoT if DoH impossible. I think Cloudflare one will be good as default. It used even in Mozilla Firefox by default.
Also, router should block connections to 53 and 80 (add optional, non default toggle) to increase security even more. It can be called "force encryption globally" which can be combined with toggle that forces HTTPS for admin panel now.
DoH/DoT support is already available in the current firmware, allowing users to enable these features as needed.
Meanwhile, enabling NTS and DoT/DoH support without fallback by default might be a bad idea.
This is because:
NTS depends on DoT/DoH for DNS resolution.
DoT/DoH depends on NTS for accurate time synchronization.
If a travel router has been powered off for an extended period, its system time will be inaccurate at startup. As a result, DoT/DoH may fail due to SSL/TLS certificate validation, and NTS will also fail because DNS resolution is not yet available.
But DoH/DoT would not function in that scenario.
How would NTS resolve a server domain such as time.cloudflare.com?
Additionally, if NTS bypasses certificate validation under certain conditions, how does it ensure the initial time it obtains is trusted?
We have not reviewed the implementation in detail, but we have previously encountered issues when using NTP configured only with domain names alongside DoH/DoT.
If our understanding is incorrect, please feel free to clarify.
If NTS and DoH/DoT do not have such limitations, we are open to further discussion with the product team. At this stage, however, we need to clearly define the requirements and determine the best implementation approach.
Oh man, you don’t code for a living do you? Hardcode an IP address? You understand that having the correct time is critical for tls wrapped comms, right? Spend a bit more time learning about how all of this works before you throw around words like nonsense, please.
dnsmasq/or other as main server i.e dnsproxy2
|
\/
if dnsmasq/dnsproxy booted, start doh or whatever forwarder on different port and then validation is long time possible.
It needs to be used and intended as a stub, then there is no issue I think?, why would it need to start the opposite priority?
If connection issues this can be easily be done by making some sanity logic via netifd events or hotplug.d, so the stub gets an restart if needed.
So if it disables RTC, it creates more risk. You lose the ability to validate certificate expiration and you can also lose the ability to detect a compromised certificate. Time is critical to encryption. Starting to see the chicken or egg situation you are creating here?
Again, if you are a network person, you really should understand why you don’t want to hardcode an IP address - regardless whether you do it in code or via a hosts file. Kind of part of the reason DNS exists, right?
I am pretty sure I am not going to change your mind, and that is ok. Guess we will have to see what GL does with your suggestion. Thanks for trying to make things more secure - it is what we need - but we cannot shoot ourselves in the foot here.
You have no control over those hardcoded ip, if they gonna change ownership, you will soon or later have problems again.
In my opinion, although I just skimmed through the topic, I think using it as a stub with event listeners doing sanity work will always be the better approach because it runs after the necessary parent programs are started, or a complete replacement of dhcp, which for reasons i'd still think it isn't a good decision because you will build away from the standards and defaults from OpenWrt.
I mean, for doh too... most what you find are stubs like dnsproxy (DoH) or stubby for DoT, dnsmasq doesn't have any doh support natively, unbound does.
It is a bypass from the process. But what if, because you are enforcing NTS, if you don’t already have time. Then it bypasses that security control. What are you not getting about a chicken and an egg scenario? That is why that configuration items exsts - to bypass the control.
Your workaround is garbage at scale. It works for you, but it is not something any manufacturer should do.
NTS starts first: No DoH/DoT service is available, the server domain name cannot be resolved, time cannot be synchronized. It waits for DoH/DoT to start, but without accurate time available, it cannot establish an SSL/TLS connection, and still cannot provide resolution service.
DoH/DoT starts first: No accurate time is available, so it cannot provide resolution service. It waits for NTS to start, but still cannot resolve the server domain name to synchronize the time.
Either way, we must have one of them fall back to an unencrypted method.
We might need to refer to the implementation of existing DoH/DoT clients to establish a kind of bootstrap mechanism.
Alternatively, we may require a NTS service providers to offer a long-term stable IP address to decouple from DNS, similar to what some DoH servers do (e.g., https://1.1.1.1/dns-query).
Regardless, let's discuss this with the product team to see if we have a solid solution for offering a more secure out-of-the-box solution in the future.
