Sun Dec 01, 2024 10:10 pm
The code that processes the HTTP requests is the same one regardless whether the requests arrive via plaintext HTTP on port 80 or TLS-encrypted (HTTPS) on port 443. So apart from protection against eavesdropping on the path between the client and the Mikrotik, the security provided by HTTPS boils down to protection of the client credentials against MITM attacks - if the client does not trust the certificate presented by the server, it will not send its username and password.
However, an attacker will not care about the server certificate so they will be able to access the same files/services using HTTP and HTTPS, so if you permit access to the www-ssl service to access the management of the router from the whole internet, it is not any more any more secure against direct attacks than allowing access from the whole internet to the HTTP service.
If you plan to use the Let's Encrypt certificate maintained by RouterOS for some other service than www-ssl, e.g. for authentication of a VPN server, you can implement the stateful logic you have described above using firewall rules. There should be a recent topic providing the details here. In short, you usa a mangle/output rule to populate a dedicated address-list with the own WAN address of the router for about a minute whenever it sends the request to Let's encrypt, and you add a rule accepting incoming connections to TCP port 80 from WAN if the destination address matches that address-list:
/ip firewall address-list
add address=acme-v02.api.letsencrypt.org list=lets-encrypt
/ip firewall mangle
add action=add-src-to-address-list address-list=acme-client address-list-timeout=1m chain=postrouting dst-address-list=lets-encrypt src-address-type=local
/ip firewall filter
...
add action=accept chain=input dst-address-list=acme-client dst-port=80 protocol=tcp
...