Implementing encrypted connections

HTTP/Websocket code already supports TLS, but CLI options for it are disabled for now. A good way to implement end-to-end encryption (immune to man-in-the-middle attacks) would be:

- An administrator provides a TLS cert, TLS key and a PSK (password to join the swarm) to master node. The cert needs to be verifiable by the peer nodes (eg. domain-specific cert from Letsencrypt, a company-wide cert etc).
- Administrator tells the PSK to users who need to connect the swarm.
- Peer nodes generate their own (self signed) cert and key upon startup -- for p2p connections.
- When a peer connects to master, master's HTTP/Websocket endpoint requires the PSK as a HTTP password (using "basic auth").
- Peer sends the fingerprint of its own p2p cert to the master.
- When master sends a download proposal to one of the peers, it includes cert fingerprint it got from the uploading peer. Downloading peer then uses certificate pinning to verify uploading peer's identity when connecting over HTTPS.

This would provide secure file distribution to a trusted subset of LAN users, and also secure transfers over the Internet without a VPN, while requiring only one user-generated cert (Websocket endpoint cert on master - which could also be a general HTTPS cert for the site).

No files, tests, or entry points are named. Start by locating the disabled CLI TLS options and the existing HTTP/Websocket code, then determine how certificate, PSK, authentication, and pinning decisions fit the peer-to-peer flow. Done requires an agreed design and end-to-end encrypted connections that verify peer identities.

Written by the indexing model from the issue text.