eKeypad ISY over the Internet

[apostolakisl]

Actually - it was the Elk only supporting SSLv3 - and SSLv3 had a major vulnerability discovered.

 

So, UDI did the responsible thing and removed SSLv3 from ISY at that time.

 

This combination 'broke' secure communication with Elk.

 

A couple of months later, Microsoft release Windows 10 which also removed SSLv3. This meant Windows users also could not connect to Elk with the secure port - something you must do to use ElkRP. This caused massive issues for installers that it forced Elk to add additional ciphers, but they have done so in a way that is not compatible with ISY.

 

So, Michel is correct. The Elk code has not changed. The need to conform to standards sits with Elk unfortunately and the root cause sits with the massive vulnerability in SSLv3.

 

Very nice summary of the issue.

 

There is also this:

 

http://www.setechautomation.com/v/docs/STEG100EFW_Install_User_Guide.pdf

 

I don't know a lot about it, except at least there is an alternative.

 

EDIT:  Never mind.  It looks like Setech Automation no longer is in the business of selling this firmware.

 

It would be nice to see ISY support the secure port, but not critical.  As mentioned, you can still use the secure port with authentication for all of your non-LAN stuff (assuming ISY is not a non-LAN device).  That is how I do it.

[Michel Kohanim]

Hello all,

 

Just reviewed the response from ELK:

 

 

IF NO USERNAMES ARE IN THE XEP

Following successful SSL/TLS negotiation, the XEP just goes straight into the ASCII Protocol command mode. No prompting, no usernames required.

 

 

Is anyone using username/password in ELK? If not, then it should work based on the above. There's really no need for lectures and accusations. All I need to know is yes/no and whether or not anyone's works without username/password.

 

With kind regards,

Michel

[apostolakisl]

Hello all,

 

Just reviewed the response from ELK:

 

 

IF NO USERNAMES ARE IN THE XEP

Following successful SSL/TLS negotiation, the XEP just goes straight into the ASCII Protocol command mode. No prompting, no usernames required.

 

 

Is anyone using username/password in ELK? If not, then it should work based on the above. There's really no need for lectures and accusations. All I need to know is yes/no and whether or not anyone's works without username/password.

 

With kind regards,

Michel

 

I'm confused about what you are saying.

 

 

Do you mean to set ISY to use the secure port of Elk, but leave the Elk XEP user/pass fields blank and see if that works?

 

I currently have ISY set to the non-secure Elk port and I do have a user/pass setup on the xep for accessing Elk directy remotely (not via ISY).  This does work.

[Michel Kohanim]

Hi apostolakisl,

 

Yes, precisely please.

 

With kind regards,

Michel

[apostolakisl]

Hi apostolakisl,

 

Yes, precisely please.

 

With kind regards,

Michel

 

At one point a long time ago I had it that way and it worked.  But then I wanted to port forward to Elk and I couldn't leave it without a password when it was open to the whole world.

 

Are you looking to simply know if it still works this way.  You aren't suggesting I leave my Elk without a password are you?

[Michel Kohanim]

Hi apostolakisl,

 

I am NOT at all recommending that you should use this configuration forever. Since the one we have works, my goals are twofold:

1. Make sure that we can verify this works with others as well

2. Put to rest the insinuations that we broke something (ISY never supported username/password for ELK)

 

We do have plans on supporting username/password in subsequent releases.

 

Thank you.

 

With kind regards,

Michel

[MWareman]

Also worth noting - you can leave the username/password on the Elk enabled and port forward the secure port.

 

On ISY simply configure the non-secure port. It will be able to connect without needing the username or password, since Elk does not ask for it on the non-secure port.

 

Just don't port forward the non-secure port!

[DennisC]

I arm and disarm my Elk via the ISY REST API (using a custom Tasker scene that prompts for the disarm code). Externally, my Elk is not exposed at all.

A few weeks ago I looked at doing this but I didn't see anything in the API that allowed a prompt for the disarm code. I didn't want to create a Tasker scene pre-programmed with the user code. I should also add I have no experience with REST API's, so I might have missed it.

 

Would you be able to elaborate?

 

Thanks,

 

Dennis

[Scottmichaelj]

Hi apostolakisl,

 

I am NOT at all recommending that you should use this configuration forever. Since the one we have works, my goals are twofold:

1. Make sure that we can verify this works with others as well

2. Put to rest the insinuations that we broke something (ISY never supported username/password for ELK)

 

We do have plans on supporting username/password in subsequent releases.

 

Thank you.

 

With kind regards,

Michel

No one's insinuating anything, you were the one that said that you broke it.

[apostolakisl]

Hi apostolakisl,

 

I am NOT at all recommending that you should use this configuration forever. Since the one we have works, my goals are twofold:

1. Make sure that we can verify this works with others as well

2. Put to rest the insinuations that we broke something (ISY never supported username/password for ELK)

 

We do have plans on supporting username/password in subsequent releases.

 

Thank you.

 

With kind regards,

Michel

 

So, yes, it still connects if I disable username/password on Elk and set the ISY to the secure port (2601) and uncheck the SSL box.

[MWareman]

A few weeks ago I looked at doing this but I didn't see anything in the API that allowed a prompt for the disarm code. I didn't want to create a Tasker scene pre-programmed with the user code. I should also add I have no experience with REST API's, so I might have missed it.

 

Would you be able to elaborate?

 

Thanks,

 

Dennis

The API itself is:

 

https://username:password@myisy.dyndns.com/rest/area/1/cmd/disarm?code=1234

 

I have Tasker prompt for the code with a custom scene, then pass the value into the API call. It's a pretty advanced call though.... If I get a chance I'll try and add it to the Tasker page on the Wiki...

 

This is what the scene looks like:

 

This is on my Nexus 6P - it's very high resolution.  I've posted the xml scene definition here: https://justpaste.it/elkdisarmscene. You *might* be able to import this and adjust the element sizing on the screen.

 

There is a hidden text element called 'txtPIN' - that starts out blank. Each button press adds the number to the string already in txtPIN.

 

Then, on clicking ''Disarm", I use the value of txtPIN in the API call - looking for the response code of 200 from ISY to indicate the disarm was successful. I also close the Tasker scene on 'Disarm' or 'Cancel'. I then have an Android widget that opens the Tasker scene..

 

I get the current value of the (hidden) text box with the 'Test Element' action - to read the value into a variable "%entered_pin".

I then call the URL with /rest/elk/area/1/cmd/disarm?code=%entered_pin.

 

This results in a solution without stored Elk user codes...

 

It relies on the 'Network Awareness' and 'Base Task Definitions' for my wiki page: http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:Networking:Tasker

 

Michael.

[Scottmichaelj]

-The default SSL port for the Elk M1XEP is 2601. I am not abled to connect to the M1XEP via the ISY Elk module with firmware 4.3.26 using port 2601, with SSL check or not. It was previously working on earlier firmware.

 

-If I turn off username and password and put in the default nonsecure port of 2101 in the Elk M1XEP and ISY module (without port forwarding) my ISY can connect fine.

 

-So as far as I can tell SSL does not work any longer with the newest firmware and my alarm system is not secure regardless of port forwarding or not. The only thing possibly securing things is my simple 4 digit access code which is not strong.

[MWareman]

-The default SSL port for the Elk M1XEP is 2601. I am not abled to connect to the M1XEP via the ISY Elk module with firmware 4.3.26 using port 2601, with SSL check or not. It was previously working on earlier firmware.

 

-If I turn off username and password and put in the default nonsecure port of 2101 in the Elk M1XEP and ISY module (without port forwarding) my ISY can connect fine.

 

-So as far as I can tell SSL does not work any longer with the newest firmware and my alarm system is not secure regardless of port forwarding or not. The only thing possibly securing things is my simple 4 digit access code which is not strong.

When not using SSL, you must use port 2101 to connect. Non-SSL has never worked to port 2601.

 

You don't need to turn off username and password auth to connect on the non-ssl port 2101 without a username and password. M1EXP only asks for a username and password on port 2601 over SSL.

 

If your internal network is not secure, then there are additional challenges that need addressing.... Saying that this configuration is not secure carries a fair bit of FUD - but it does depend on not exposing 2101 to the outside world, and having a secure core network.

 

Summary:

Only port-forwarded 2601 to the M1XEP. Don't port forward 2101. Leave username/password auth on Elk M1XEP enabled. Configure the ISY to connect on 2101. Configure ekeypad to connect to port 2601 with username and password. Profit.

[DennisC]

The API itself is:

 

https://username:password@myisy.dyndns.com/rest/area/1/cmd/disarm?code=1234

 

I have Tasker prompt for the code with a custom scene, then pass the value into the API call. It's a pretty advanced call though.... If I get a chance I'll try and add it to the Tasker page on the Wiki...

 

This is what the scene looks like:

ElkDisarm.png

 

This is on my Nexus 6P - it's very high resolution.  I've posted the xml scene definition here: https://justpaste.it/elkdisarmscene. You *might* be able to import this and adjust the element sizing on the screen.

 

There is a hidden text element called 'txtPIN' - that starts out blank. Each button press adds the number to the string already in txtPIN.

 

Then, on clicking ''Disarm", I use the value of txtPIN in the API call - looking for the response code of 200 from ISY to indicate the disarm was successful. I also close the Tasker scene on 'Disarm' or 'Cancel'. I then have an Android widget that opens the Tasker scene..

 

I get the current value of the (hidden) text box with the 'Test Element' action - to read the value into a variable "%entered_pin".

I then call the URL with /rest/elk/area/1/cmd/disarm?code=%entered_pin.

 

This results in a solution without stored Elk user codes...

 

It relies on the 'Network Awareness' and 'Base Task Definitions' for my wiki page: http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:Networking:Tasker

 

Michael.

Michael,

 

Thank you for supplying this information. This is exactly what I am looking to do. I'm going to play with this over the weekend (hopefully). I had previously figured out all of the arming types and two methods of disarming. One doesn't utilize a passcode and the second embeds the passcode and I didn't want to do either. I have these working in both a browser and Tasker, but I didn't realize the passcode could be passed thru a variable.

 

I have done a little with pop ups in Tasker and driving a task from a widget so maybe I will get lucky. This is really my first attempt at doing something with REST, so it should be interesting......

 

Regards,

 

Dennis

[Michel Kohanim]

Hello all,

 

Thanks so very much for the feedback. Now that we know most can connect from ISY to ELK on the secure port (without username/password), it's much easier to include username/password into the mix.

 

 

With kind regards,

Michel

[apostolakisl]

Actually, I checked again.  The ISY says it connected and it shows zones status and all, but it doesn't work.  I couldn't arm/disarm and if zones changed nothing showed up.  It also prevented me from connecting with Elk RP.  When I checked the ssl box, it disconnected.

[Michel Kohanim]

Hi apostolakisl,

 

Can you please send your error log to support@universal-devices.com?

 

With kind regards,

Michel

[Scottmichaelj]

Actually, I checked again.  The ISY says it connected and it shows zones status and all, but it doesn't work.  I couldn't arm/disarm and if zones changed nothing showed up.  It also prevented me from connecting with Elk RP.  When I checked the ssl box, it disconnected.

I have the same issue and reported my findings above. Error log sent.

[Scottmichaelj]

Hi apostolakisl,

 

Can you please send your error log to support@universal-devices.com?

 

With kind regards,

Michel

Michel, after our back and forth emails for this issue via my support ticket, has Chris had time to look into this as you said he would? Its been a while.

[Michel Kohanim]

Hi Scott,

 

Yes: M1XEP only supports TLS1.0 and does not auto negotiate. From what I understood, ELK is going to have an updated version of the firmware for their stack by the end of April.

 

With kind regards,

Michel