If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

This is a separate approach from Meep's excellent work on hab-tunes (we have discussed some common areas though). Currently it's definitely techies only I'm afraid (no actual coding but you'll need to know a bit of Linux, Networking, SSL... and have Amazon developer accounts). The pay-off is it's optimised for speed and security I guess.

PS - I'm not on the forums much, so if you want to get in touch best to do it via Github (or Twitter)

Hm, how is this more secure than what Meep is doing?
I mean... TLS and everything but this still requires you to open up your server machine to the internet and as security issues are this should at least involve staying up to date with known security issues in e.g. your TLS client on a daily basis because, you know, these big security issues that made the news in recent years were all about issues in security software like OpenSSL...

So if such an issue shows up again (or it's not yet fixed on your NAS) you can fall victim to port scan attacks with such a setup. Not too likely but possible, some such bugs have been around (and used!) for years.

I think the only thing being more secure is a solution where LMS only does outbound communication, that is: a plugin that connects to Alexa (or some intermediate service) and polls.

---
learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
at penguinlovesmusic.comNew: iPeng 9, the Universal App for iPhone, iPad and Apple Watch

Hm, how is this more secure than what Meep is doing?
I mean... TLS and everything but this still requires you to open up your server machine to the internet and as security issues are this should at least involve staying up to date with known security issues in e.g. your TLS client on a daily basis because, you know, these big security issues that made the news in recent years were all about issues in security software like OpenSSL...

So if such an issue shows up again (or it's not yet fixed on your NAS) you can fall victim to port scan attacks with such a setup. Not too likely but possible, some such bugs have been around (and used!) for years.

I think the only thing being more secure is a solution where LMS only does outbound communication, that is: a plugin that connects to Alexa (or some intermediate service) and polls.

Well, at the moment, this is more secure as the initial command from my skill to my plugin is over http. (thereafter, all transactions are pulled by the plugin over https). While I've done what I can to secure the plug-in (only a single command accepted , validating sender insofar as is possible, rate-limiting inbound connections, no direct LMS access, limited command set supported), it's still a vulnerability as there's an open port.

The next stage of development for me is to implement pseudo-polling by implementing MQTT. This will hopefully eliminate the requirement for an open port, though I have some concerns about latency. And of course this will only be as secure as mqtt over https can be.

Right now, nickb's solution is more secure and will always be faster than what I'm doing, at the expense of a somewhat complicated setup.

I take your point on the risks. Indeed, I've spent most of the last 2 months developing the base infrastructure and skill<->plugin communications to incorporate improved security measures in response to initial feedback here. I could have had a working skill in place at this stage but I think user protection is important so it's time well spent. However, I'll always approach this from the perspective that it's not banking software (!), it's audio playback and while people may have genuine concerns around security, at the end of they day they will be aware of the risks (because I'll tell them) and can choose to use it or not.

Hi Pippin. Great to open up this discussion. It's not intended as a replacement / comparison to Meep's... more that there are some (other) solutions out there which simply open up LMS directly (or use HTTP basic auth) which is obviously a bad idea.

I mean... TLS and everything but this still requires you to open up your server machine to the internet and as security issues are this should at least involve staying up to date with known security issues in e.g. your TLS client on a daily basis because, you know, these big security issues that made the news in recent years were all about issues in security software like OpenSSL...

I agree - patches are important, and yes for OpenSSL, as a key piece of internet infrastructure it's scary and definitely in the firing line & press often. To an extent that's why I'm advocating using any TLS TCP proxy most suited to your server (if you can get one working - I've only really tried stunnel) so you can choose.

So if such an issue shows up again (or it's not yet fixed on your NAS) you can fall victim to port scan attacks with such a setup. Not too likely but possible, some such bugs have been around (and used!) for years.

Sure. We can guarantee routers / anything in the DMZ are getting port-scanned anyway - the key is keeping those ports closed or secured plus a certain (debatable!) level of obscurity, e.g. maybe don't expose it on 443. The other key advice is to reduce the impact of a breach: here this is not an SSH login, and shares no authentication mechanism with the server OS - so the impact is limited to the LMS CLI (still bad though). For further security around that you can enable built-in user/pass auth on the LMS server - as it's DIY, it's up to the user to decide.

I think the only thing being more secure is a solution where LMS only does outbound communication, that is: a plugin that connects to Alexa (or some intermediate service) and polls.

For better or worse Alexa infra doesn't support incoming connections (nor do AWS Lambdas), so you'd definitely need an intermediate server. But traditional polling is probably not viable for a voice-prompted service (where you want milliseconds of latency): the polling would need to be too tight. With an intermediate service, a long-standing connection / websocket might work and might be good to explore some time, but the load (and cost) then goes up aggressively with the number of registered users.

But: you still need to trust this intermediate service to control your LMS... which is something I was uneasy about generally. Remember too - that server is open to the internet on some port(s), probably / hopefully uses TLS of some sort, and controls everyone's LMS instances.

The next stage of development for me is to implement pseudo-polling by implementing MQTT. This will hopefully eliminate the requirement for an open port, though I have some concerns about latency. And of course this will only be as secure as mqtt over https can be.

Hi Meep. Interesting. I've played with MQTT and seemed simple / good - let us know how it goes. Got a bit worried when starting to read this very detailed review (though biased I guess) pointed out so many flaws with MQTT in the general case.

Probably not so problematic for this/our type of usage I reckon. Note to self: maybe websockets is worth another look...

I agree - patches are important, and yes for OpenSSL, as a key piece of internet infrastructure it's scary and definitely in the firing line & press often. To an extent that's why I'm advocating using any TLS TCP proxy most suited to your server (if you can get one working - I've only really tried stunnel) so you can choose.

But that was exactly my point: if you do that, you have to understand pretty well what you are doing and I for one wouldn't. Don't know how the experience level of other users here is WRT platform security.

People tend to think "oh, it's encrypted, now it must be safe" but that's a fallacy. Encryption helps against a few obvious attacks, most notably reading username/password (bad since so many people re-use these) and against easy access to LMS (bad because it could wake you up in the night or destroy your configuration as you can see in the reports here on the site).

But on the other hand you run an encryption software that is usually a well-challenged high-value target in internet attacks. Any unfixed vulnerability in there potentially opens up access to your server machine and we are not talking about access to LMS at this point, we are talking about access to the OS. If things are really bad you are running your SSL/SSH client with root privileges. With a little bad luck these are things that can be exploited using port scans.
This is not totally uncommon and can never be completely prevented (look at the critical issue from Sep. '16 here, for an example: https://www.openssl.org/news/vulnerabilities.html). What you need to do to be safe against these things is to stay informed what's going on and patch your system to get new updates whenever bad things happen or even take it temporarily offline.

There is no such thing a "secure system", security is a process and a pretty complex one as well.

I'd actually feel better with Meep's self-made solution than with an SSL/SSH client library on my NAS which I don't know the patch status of for the simple reason that his client is a software that would require a very specialized attack while simply looking for vulnerabilities in encryption libraries is what half of the wannabe-hackers on the internet are doing all day.

Last edited by pippin; 2017-02-22 at 07:36.

---
learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
at penguinlovesmusic.comNew: iPeng 9, the Universal App for iPhone, iPad and Apple Watch

Hi Meep. Interesting. I've played with MQTT and seemed simple / good - let us know how it goes. Got a bit worried when starting to read this very detailed review (though biased I guess) pointed out so many flaws with MQTT in the general case.

Probably not so problematic for this/our type of usage I reckon. Note to self: maybe websockets is worth another look...

Super-interesting article and a fairly comprehensive teardown of MQTT!

I agree, however, that in the present use-case, a lot of those issues simply don't apply. I'm planning to utilise it to push a single message to a client which will then complete the transaction vie https requests to the server. Each user will have a discrete MQTT topic and will be authenticated on subscribe. Hopefully this will allow the elimination of open ports on the users LMS host server. Yay!

MQTT is nice and fine but why not just use websockets or something like that? Plenty of implementations readily available and simple to integrate.

---
learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
at penguinlovesmusic.comNew: iPeng 9, the Universal App for iPhone, iPad and Apple Watch

MQTT is nice and fine but why not just use websockets or something like that? Plenty of implementations readily available and simple to integrate.

Probably because I have some familiarity with MQTT and understand how I'd design a solution for the multi-user requirements. I'll have a look into websockets for sure and I think it would have the potential to have less latency.