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.

[Tim Curtis]

@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. 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. Similarly, on the Pixel 6a, Chrome is happy but Firefox isn't.

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.

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 about iPadOS and Android, but as an issue on the github repo.

Good stuff.

I'll read thoroughly tomorrow. There will be another Bullseye release this month to fix some minor bugs and make a few updates so perfect timing :-)

[TheOldPresbyope]

@Tim Curtis 

Arrgh. 

No sooner had I posted than I thought to examine the certificate associated with moodeaudio.org. Opening it in Firefox, I see it is marked "Certificate Authority   No" which means my understanding of this situation is still incomplete. 

My point #1 must be revisited. What I did "works but...."

Sigh.

Regards,
Kent

[TheOldPresbyope]

Once more into the breach, dear friends.

The crux of the matter seems to be that OSes such as Android and iPadOS (likely iOS as well) won't trust a self-signed certificate which can't be traced back to a root Certificate Authority even if I tell them to.

By setting CA:TRUE, I am creating a certificate which they will install as a root certificate if I tell them to.

Here's a precedent I found in online IBM documentation: https://www.ibm.com/docs/es/mpf/8.0.0?to...nvironment


Clearly, this practice is acceptable only for servers running in a home network not accessible from the Internet.

Regards,
Kent

[Tim Curtis]

Interesting. Prolly need to determine whether there are any downsides to CA:TRUE. I'll see what happens on my Mac.

[Tim Curtis]

This article might help explain potential issues to CA:TRUE
https://stackoverflow.com/questions/3699...rtificates

[TheOldPresbyope]

This article might help explain potential issues to CA:TRUE
https://stackoverflow.com/questions/3699...rtificates

I (think I) get that but it feels like a "can't live with it; can't live without it" situation, at least with respect to mobile devices.   The operative words seem to be "if the private key is widely known...." Busily trying to become more knowledgeable.

Meanwhile, I'm amending/adding other, less important points in my first post.

Regards,
Kent

[Tim Curtis]

This article might help explain potential issues to CA:TRUE
https://stackoverflow.com/questions/3699...rtificates

I (think I) get that but it feels like a "can't live with it; can't live without it" situation, at least with respect to mobile devices.   The operative words seem to be "if the private key is widely known...." Busily trying to become more knowledgeable.

Meanwhile, I'm amending/adding other, less important points in my first post.

Regards,
Kent

In our case the private key is stored in 
/etc/ssl/private/

[ubergoober]

Since the Moode player is not a certificate authority, it should not pretend to be.  It should have an identity certificate signed by a known and trusted CA.  Anybody operating strictly within their own private home network should not care.  
If you are going to the trouble of exposing it to the internet, then there isn't any reason you could not use an ACME client script to get a free cert from LetsEncrypt.  If you don't want your player exposed full time, you can tell your router that the ip address of the player is the DMZ host allowing full access while you generate or renew your cert.  
The Letsencrypt CA cert is already included in windows, linux, ios and android.  Wrapping a script around the acme client should allow you to place the ID cert in the correct place and use it for the REST API.




I

[TheOldPresbyope]

Since the Moode player is not a certificate authority, it should not pretend to be.  It should have an identity certificate signed by a known and trusted CA.  Anybody operating strictly within their own private home network should not care.  

If you are going to the trouble of exposing it to the internet, then there isn't any reason you could not use an ACME client script to get a free cert from LetsEncrypt.  If you don't want your player exposed full time, you can tell your router that the ip address of the player is the DMZ host allowing full access while you generate or renew your cert.  
The Letsencrypt CA cert is already included in windows, linux, ios and android.  Wrapping a script around the acme client should allow you to place the ID cert in the correct place and use it for the REST API.

Interesting argument.

It seems to me that a "private home network" is exactly the point here. AIUI, the motivation for developing the experimental HTTPS mode is to deal with the trend in web browsers to make it increasingly cumbersome to access a HTTP server, even though it is operating within a private home network.

I can't speak for @Tim Curtis but personally I don't believe a moOde player should be "exposed" to the internet except from behind a home router with full NAT in play and no port forwarding. 

As for Let's Encrypt I have no experience with it or the ACME client script (I haven't spun up a public-facing server in a over a decade and have had no need for their free service). Without experimenting, I can't comment on the practicality of this proposal in a moOde player and a home environment.

Regards,
Kent