Put them on non-default ports, then. This is “security through obscurity,” which some people take as grounds for immediate dismissal, but what they overlook is that obscurity + real security = better security. You can’t hit what you can’t see, and script kiddies tend not to bother making their attacks slower by trying every attack against every possible port, only against the likely ones.
HTTPS as being time sensitive in the sense that if, for any reason, a device has a bogus time and date, HTTPS cannot be used anymore.
That’s about as true as the claim that self-signed certificates are useless. The default configuration of web browsers will reject both, but the “yes, I’m really sure” option gets you past both problems.
Furthermore, you have to quantify your risks here. “Bad time” means…what?
NTP getting blocked resulting in minutes of error only causes a problem here if the certificate is minutes from expiring, in which case why didn’t you renew it sooner? A typical pattern is that a cert has a 3-month lifetime from minting time, but you renew it every month or two, so you’d have to have NTP more than a month off for this to be the reason you can’t get logged into the management interface.
Furthermore, it’s the client’s time that matters here, assuming the time was set properly at certificate minting time. If the MT gear loses time sync after that, it shouldn’t matter because it’s the server in this case, and you almost certainly aren’t using client-side certificates. Since it’s the client evaluating the validity of the certificate, if it’s got the right time, that’s all that matters.
To my knowledge, SSH still works if time and date is bogus.
I believe you’re right, and there’s a lot of power you can get out of doing things that way versus HTTPS. For instance, there’s port-forwarding via OpenSSH’s -L and -R flags, which would let you do WebFig over SSH. Or, SOCKS via OpenSSH’s -D flag, with much the same effect.
I think it’s fair to consider SSH a type of VPN protocol for this reason. Not a fully-general one, but useful within a limited scope.
On that note, you should consider setting up a VPN rather than do either SSH or HTTPS. I don’t mean to arm-twist you, but if you haven’t seriously evaluated your options — particularly under RouterOS 7.1 with its new easy-to-configure VPN options, WireGuard and ZeroTier — then I think you’re missing some serious potential value.
I can easily imagine reasons for NTP failures
Don’t merely imagine NTP failures: count on them! If you’ve never had an NTP-synchronized device be dozens of seconds out because an NTP pool went down or a firewall change started blocking NTP packets, you either haven’t been paying attention or you haven’t been doing networking very long.
On that note, it’s worth considering making one of your MT devices a LAN NTP server. Which is more likely: the Apple, Microsoft, CentOS, Ubuntu…whatever NTP pools all stay up collectively to keep all your LAN clients synced, or that some of them lose access to the MT switch and it’s single Internet time source goes down? And if that latter does happen, isn’t it likely to cause less harm if the LAN clients are wrong by the same amount than if they’re all going off into the Land of Wrong independently?
If you’re depending on your MT hardware for LAN DHCP service, you should feel reasonably comfortably relying on them for NTP as well.
do RouterOS devices have some hardware that prevent date to be set at 1/1/1970 ?
It would be a matter of software, not hardware.
The primary defense is good configuration. Have the MT box use a stable, broad, nearby, DNS-based NTP pool (e.g. us.pool.ntp.org for equipment in the US) rather than a single upstream server. That way, as long as DNS and your upstream link keep working, NTP will keep working.
After that, distributing NTP internally from the same source (the MT box) will keep everyone on the same notion of “now.”
Would you suggest using some other tools (Wireguard, OVPN, …) to be safe in such situations ?
WireGuard is based on a pre-shared key which need never change, so there is no associated timestamp. It’s closer to SSH-with-keys than to TLS in operation.
OpenVPN is “VPN over HTTPS” so it brings all of the worries you’re bringing up here. It’s also inherently slow, so the only reason to use it is for compatibility with existing OpenVPN infrastructure. (Old firewalls, commercial VPN services, etc.)
I think you don’t depend on DNS
DNS failures most definitely can cause TLS to fail. The X.509 certificates underlying TLS (and thus HTTPS) are making a declaration about a given domain name, so if the DNS is wrong, the client (e.g. a web browser) will flag the problem if it’s paying attention.
Another common TLS failure is protocol mismatch. For this reason, pretty much every HTTPS software that hasn’t been updated in the last 5-10 years will no longer talk to current TLS implementations, because they can no longer agree on a common ciphersuite.
This same problem can also occur with SSH, but I’d put a wider compatibility window on it. The last major break was SSH v1 versus v2, but I do believe there are old SSH v2 servers that will no longer talk to modern SSH v2 clients for lack of a common ciphersuite.
VPN protocols are a mixed bag. TLS-based ones have the same problem as HTTPS, whereas WireGuard probably hasn’t had that problem at all yet, being too young.