3rd Party Local API - Beta Testers/Contributers Wanted

Information and support for EnvisaLink modules.

Moderators: EyezOnRich, GrandWizard

pounder
Posts: 71
Joined: Sat Oct 20, 2012 10:34 pm
Location: Niagara Region, Ontario Canada

Re: 3rd Party Local API - Beta Testers/Contributers Wanted

Post by pounder »

Can one of you please clarify why the aversion to ssl certificates ?

You can have your own CA up and running in a matter of a few minutes and the certificates are perfectly valid. Things like webmin even build their own for you.

Keep in mind with certificates there are two reasons to have them, encryption and trust. If you already trust yourself there is no reason to pay for one, since you can make your own.

We're not talking any heavy duty webserver here, <$100 routers are just fine - my current fav is the asus n16 for about $80.
Jon Pounder
donnyk
Posts: 30
Joined: Sat Dec 01, 2012 11:51 pm

Re: 3rd Party Local API - Beta Testers/Contributers Wanted

Post by donnyk »

pounder wrote:Can one of you please clarify why the aversion to ssl certificates ?

You can have your own CA up and running in a matter of a few minutes and the certificates are perfectly valid. Things like webmin even build their own for you.

Keep in mind with certificates there are two reasons to have them, encryption and trust. If you already trust yourself there is no reason to pay for one, since you can make your own.

We're not talking any heavy duty webserver here, <$100 routers are just fine - my current fav is the asus n16 for about $80.
Pounder,

I'm not quite sure what you are getting at. I certainly have nothing against ssl and I have in fact mentioned a couple of times now that some authentication + https was needed. If you take a look on github, its an active issue I created earlier this morning (before you made this post) and I've assigned myself to it. I said earlier in the thread this is still in a beta/testing phase and gave a specific warning to NOT forward any connections from the outside for this very reason. I've already started reading over the python SSL/TLS stuff and I'll be working on it this weekend when I get a chance. I will definitely be generating my own certificate and it will be part of the install process to generate your own. You'll have to accept it of course as it won't be centrally signed but there isnt much you can do about that.

All in all this is clearly still a work in progress. I'm doing this in my spare time and as a hobby for fun. If no one uses it but me that is fine with me. I'm not writing this for financial gain or anything of the sort. I do hope to make it something people will use in the short to near term however as I feel based on the requests a solid local api is really needed. It would of been ideal if the central API wasn't a huge hack to begin with and I would not of even bothered. But as it stands the information exposed by indexapi.php is poor at best.

I'm certainly open to input as all of this python is new territory for me.. as i've mentioned to you before i'm a long time php/c/c++ programmer but python is new for me. Implementing security on something that would be exposed to the internet is new to me as well, all my experience is on a private wan at work where security is important of course but not paramount as the lan is deemed secure. This is of course entirely different when you are exposing your alarm to the internet.

In regards to a comment you made in another thread about taking over the central monitoring aspect of the envisalink. Writing a server for that protocol would be interesting for sure but as I understand it if you wish to change the IP it points at you need to unlock for 2ds/3.
donnyk
Posts: 30
Joined: Sat Dec 01, 2012 11:51 pm

Re: 3rd Party Local API - Beta Testers/Contributers Wanted

Post by donnyk »

Latest commit now enables https (and removes http) using TLSv1, no authentication yet but that is coming soon.
mikep
Posts: 138
Joined: Wed May 30, 2012 1:49 pm
Contact:

Re: 3rd Party Local API - Beta Testers/Contributers Wanted

Post by mikep »

No aversion to SSL from me either. When you're using your own server and a commercial web browser it works really well, the only extra thing you need to do is protect against brute force password attacks.

When doing things programmatically it's more trouble - you need to have a set of instructions for installing SSL on the server side, and for generating and installing the certificates. On the client side you need extensions to catch and let the user verify that the certificate is valid, and then install it (so you don't have to prompt every time).

Generalized web servers with SSL are a perfect when you need to serve a lot of different types of data to a lot of clients on many devices. Good for banking, and Eyezon. But in the case of the TPI the data is limited and known and is stateful and real time - not ideal for web servers. I think it's better that the clients are tightly controlled - your phone like a key or peephole to your premises. If I need universal external access from a browser the Eyezon site looks good and very secure. My opinion anyway. Besides, look at the sales this year - PCs, windows and linux, and web browsers are dinosaurs outside of the datacenter - cloud computing and handhelds are here! And web apps on phones still suck ;).

Mike
DscServer for android/linux/windows: https://sites.google.com/site/mppsuite/dscserver
donnyk
Posts: 30
Joined: Sat Dec 01, 2012 11:51 pm

Re: 3rd Party Local API - Beta Testers/Contributers Wanted

Post by donnyk »

mikep wrote:No aversion to SSL from me either. When you're using your own server and a commercial web browser it works really well, the only extra thing you need to do is protect against brute force password attacks.

When doing things programmatically it's more trouble - you need to have a set of instructions for installing SSL on the server side, and for generating and installing the certificates. On the client side you need extensions to catch and let the user verify that the certificate is valid, and then install it (so you don't have to prompt every time).

Generalized web servers with SSL are a perfect when you need to serve a lot of different types of data to a lot of clients on many devices. Good for banking, and Eyezon. But in the case of the TPI the data is limited and known and is stateful and real time - not ideal for web servers. I think it's better that the clients are tightly controlled - your phone like a key or peephole to your premises. If I need universal external access from a browser the Eyezon site looks good and very secure. My opinion anyway. Besides, look at the sales this year - PCs, windows and linux, and web browsers are dinosaurs outside of the datacenter - cloud computing and handhelds are here! And web apps on phones still suck ;).

Mike
Mike for your alarm server did you proxy TPI or did you come up with another protocol?
mikep
Posts: 138
Joined: Wed May 30, 2012 1:49 pm
Contact:

Re: 3rd Party Local API - Beta Testers/Contributers Wanted

Post by mikep »

Pretty much a straight proxy. I do some caching for performance, and trim out unused zone and partition events (so set the right number of zones & partitions in the setup screen). I send envisalink the panel time and turn on time broadcast when I connect. I may be reporting a couple of unsolicitied IT100 type commands (Broadcast Labels and LEDStatus) to the clients but I don't think so - I'll have a look through the code later to double check. You can ignore them if I do.

Mike
DscServer for android/linux/windows: https://sites.google.com/site/mppsuite/dscserver
donnyk
Posts: 30
Joined: Sat Dec 01, 2012 11:51 pm

Re: 3rd Party Local API - Beta Testers/Contributers Wanted

Post by donnyk »

mikep wrote:Pretty much a straight proxy. I do some caching for performance, and trim out unused zone and partition events (so set the right number of zones & partitions in the setup screen). I send envisalink the panel time and turn on time broadcast when I connect. I may be reporting a couple of unsolicitied IT100 type commands (Broadcast Labels and LEDStatus) to the clients but I don't think so - I'll have a look through the code later to double check. You can ignore them if I do.

Mike
Interesting. One big piece still left for me (or anyone else as its open source) to work on is notifications. More specifically push notifications to specific apps such as pushover, notifymyandroid, etc.

The other big piece is some form of authentication that will make it safe to expose the device to the wan. Could do a username/password, or it could also be device keys. We can also restrict by ip as well. What did you do in dscserver for authentication?
mikep
Posts: 138
Joined: Wed May 30, 2012 1:49 pm
Contact:

Re: 3rd Party Local API - Beta Testers/Contributers Wanted

Post by mikep »

I use layers of security - public key encryption for data exchanges, the TPI password, and the DSC security PIN (never stored). I also require registration of each android client with the server so that only registered clients can gain access, and they can be unregistered from the server (say if the phone were lost).

Mike
DscServer for android/linux/windows: https://sites.google.com/site/mppsuite/dscserver
noone
Posts: 13
Joined: Sat Jun 14, 2014 10:05 am

Re: 3rd Party Local API - Beta Testers/Contributers Wanted

Post by noone »

Does the web interface on this work? I installed it on a Windows machine (I did NOT install Python OpenSSL), using the expired certificates that came with the package and i'm not able to figure out how to access the web interface. The logs say the application started up correctly. I tried to access https://localhost:8111 without success.

Donny, are you still around?

Any way you can offer a quick tutorial on how to run this?

Thanks again.
noone
Posts: 13
Joined: Sat Jun 14, 2014 10:05 am

Re: 3rd Party Local API - Beta Testers/Contributers Wanted

Post by noone »

It took some work, but I got it working. This is definitely something I can work from.

If anyone is looking for Python scripts, these are a good base to use as a reference.

Thanks go out to DonnyK and the other contributors for this work.
Post Reply