TLS support (also in CLI utils)

[calestyo]

Hey.

First of all,... reaaaally nice project, thanks a lot for your efforts :-)

Second, from https://fritzconnection.readthedocs.io/en/1.14.0/sources/getting_started.html#tls-encryption:

Since the router uses a self-signed certificate, currently certificate-verification is disabled.

1. Would it be possible to add support for proper verification, i.e., if enabled, using the system certificate store per default, but also allowing to specify a CA-cert file/path manually?
   
   Yes, most people will use it via WiFi, but WPA (including WPA3) isn't really the most secure thing in the world.
   And yes, certs are per default self-signed, but one can upload proper ones (like from a self signed CA) or one could simply directly use that self signed cert and store that somehow locally and use it for verification.

2. And also to export that via the CLI tool?
   
   Like via adding a --tls-verify option (or better, a --no-tls-verify-option and let it have the verification done per default)?
   
   And by some --tls-ca-pathname option or so (which if not given, defaults to system certs)?

3. Perhaps consider whether TLS should be default and people have to explicitly disable it and/or use some no_verify option to use TLS but don't check the cert? Again, simply for security reasons.

Thanks,
Chris.

[kbr]

The library is used by a lot of home automation installations with users probably not knowing anything about TLS (and may be other users too). So I don't want to introduce changes, that require actions. But making encryption default or adding an option for other certificates with the corresponding verification could be an idea.

[calestyo]

But making encryption default

You mean in the CLI tools then?

[calestyo]

What just came to my mind and what one could think about (though perhaps this should then go better into it's own issue) is additionally to proper verification, offering a TOFU (trust on first use) mode.

Like the first time the lib connects to a given fritzbox (not sure how to identify them, perhaps simply by IP and/or BSSID or something like that?), it would fetch the cert it uses (which would then of course not really be authenticated/trustworthy) store it and henceforth expect that certificate (unless it expires; there also taking the expiry times from that very first fetch).

That would be at least somewhat more secure than not doing TLS at all, respectively just trusting every time the current certificate.