Add MTLS-support

[benbender]

I'm in possession of two Edifier MS50a. Their "smart"-capabilities are driven by an arylic A97-chip and the http-interface uses MTLS for authentication. It uses the same default client-certificate as the Yamaha-Soundbars and presumably many more devices as it seems to be the default certificate of some sort from the vendor-sdk.

This needed client-certificate was extracted off of an app by @osk2 and implemented for those Yamaha-Soundbars .

I did a proof of concept-patch to this component to see if I could get my speakers working with the client-cert. And it did work indeed. The POC is here.

I suspect that several (closed) issues (f.e. #125) where the api of devices was not reachable, but in fact also secured by those TLS-client-certificates, could also be fixed by this POC. In my opinion it would be a nice addition to make this component compatible with even more devices out there!

I also encountered #85 again as my device doesn't support the getStatus-cmd, but only getStatusEx. As the component expects a JSON-response and only catches http-errors, the error is uncatched as it occurs in while decoding the (non-)json-response.

I'm not very familiar with either python or the home-assistant internals, so I would love to see the final implemention done by someone more knowledgable than me.

What do you think? And btw: thanks for the work for the community!

Addendum

If devices are "secured" with the mtls-cert can simply be checked with curl:

curl https://(ip):443/httpapi.asp?command=getStatusEx|jq

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.

curl --insecure --cert-type pem --cert Downloads/client.pem https://(ip):443/httpapi.asp?command=getStatusEx|jq

{
  "language": "Ger_de",
  "ssid": "EDIFIER MS50A 4F40",
  "hideSSID": "0",
  "firmware": "Linkplay.4.6.430230",
  "build": "release",
  "project": "EDIFIER MS50A",
  "priv_prj": "EDIFIER MS50A",
  "Release": "20220923",
  "FW_Release_version": "",
  "group": "0",
  "wmrm_version": "4.2",
  "expired": "0",
  "internet": "1",
  …
}

[nagyrobi]

Nice. Unfortunately I don't have such devices myself to test.

I have another issue with this, not sure how legal would be to use, distribute and support this with a reverse engineered key.

If you'd like to add support, I'd say fork this repo and make a separate version with these features. I'm starting to lose interest slowly anyway...

[benbender]

I don't think there is too much to worry about in terms of legal risks as no (financial) harm is done to anyone. But I can totally understand your standpoint and don't want to push you in any direction.

And tbh, I'm not really interested in maintaining yet another fork because I feel like there are already too many and it's becoming quite confusing for endusers. Especially if none of them is well maintained…

That said, would it be ok if I would provide a PR which introduces one additional config-option that allows the user to provide the path to the client-certificate and handles the rest internally? If that would be merged, it at least would provide an escape-hatch in the most common codebase for users facing the mtls-problem with their devices…