moOde and HTTPS

[TheOldPresbyope]

@Tim Curtis, et al.

A bit of a ramble here...

1. /var/www/util/gen-cert.sh is slightly incorrect in my opinion. I am far from being expert on X.509 certificates and their uses, but currently it creates an openssl configuration file including the X509v3 extension

Code:

[ req_ext ]
basicConstraints        = critical, CA:FALSE

I was unable to install the resulting certificate on either my iPad (iPadOS 17.3.1) or my Google Pixel 6a phone (Android 14). On the iPad the process silently failed. On the Pixel 6a I was getting the misleading message "Private key required to install..". (Approximately 98 percent of what I found searching for this message on the InterWeb™ was out of date, misleading, or false or some combination of the above. What a surprise )

AFAIK, the extension parameter should instead be CA:TRUE for generating our website certificate (as opposed to a user certificate).

Making this change to the script in a fresh moOde 8.3.8 install and then setting HTTPS mode on, I now can download and install the certificate on both mobile devices. The process was relatively easy on the iPad and somewhat more involved on the Pixel 6a.

2. On the iPad, browsers such as Safari, Chrome, and Opera observe the installed certificate; Firefox apparently does not.

ETA - FIrefox on the iPad does too now that the dust has settled. However, on the Pixel 6a, Chrome is happy but Firefox still believes the player is not secure. The only easy work-around I see with Firefox is to take the usual "damn the torpedos and full speed ahead" choice when the https: site is challenged.

3. The certificate encrypts 172.24.1.1 as an alternative name . This should be revisited when we move to Bookworm and the flexibility that NetworkManager provides.

ETA The certificate does not include the current IP address of the player as an alternative name. Given that most home installations employ dynamic addressing, this is reasonable. However, it means that using the IP address as the URL in a web browser leads to the usual warning about it being a security risk.

4. Players running in HTTPS mode can discover players running in HTTP mode (using m>players) but the opposite is not true. In my limited testing, players running in HTTPS mode can't discover one another.

5. Network access to a player's SMB and NFS shares is not affected by its running in HTTPS mode. 

6. Use of the REST API is affected. Here, for example, curl chokes when it tries to set the volume to 50 on a player running in HTTPS mode

Code:

xxx@T520:~$ curl https://pi3bpluslcd.local/command/?cmd=set_volume%2050
curl: (60) SSL certificate problem: self-signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
xxx@T520:~$

A heat-it-and-beat-it fix is simply to force curl to skip the verification step using the -k (or --insecure) option

Code:

xxx@T520:~$ curl -k https://pi3bpluslcd.local/command/?cmd=set_volume%2050
xx@T520:~$

There are more sophisticated solutions available if one wants actual verification---see the incredibly rich collection of curl options relating to certificates.

7. I haven't explored the situation with either Linux or MS Windows yet but it's on what passes for a ToDo list here.

Regards,
Kent

PS - I'll post suggested material for setup.txt setup_https.txt about iPadOS and Android, but as an issue on the github repo.