rccoleman Posted February 19, 2016 Posted February 19, 2016 That's what I did for a while, but it added to the already-long delay that occurs when authenticating with the Elk after launching eKeypad. Especially when I want to launch the app, arm the alarm, and immediately get out. It just becomes too much hassle for me.
apostolakisl Posted February 19, 2016 Posted February 19, 2016 That's what I did for a while, but it added to the already-long delay that occurs when authenticating with the Elk after launching eKeypad. Especially when I want to launch the app, arm the alarm, and immediately get out. It just becomes too much hassle for me. Hmm. I VPN from my office into my house and don't notice any additional lag. I'm doing vpn router to router on that. Are you hosting it on a dedicated vpn router?
rccoleman Posted February 19, 2016 Posted February 19, 2016 It's not the lag (or lack thereof) from the VPN itself, but the fact that I have to navigate through menus or find the app to start the VPN that takes time. I host OpenVPN on my Synology NAS because it was the easiest to configure and I can get to it from work, but it also requires me to connect using an OpenVPN app. It adds an extra step that makes me less likely to bother with it if I have other options (like walking to the panel). Rob
apostolakisl Posted February 19, 2016 Posted February 19, 2016 It's not the lag (or lack thereof) from the VPN itself, but the fact that I have to navigate through menus or find the app to start the VPN that takes time. I host OpenVPN on my Synology NAS because it was the easiest to configure and I can get to it from work, but it also requires me to connect using an OpenVPN app. It adds an extra step that makes me less likely to bother with it if I have other options (like walking to the panel). Rob OK, I see that. You might try getting a ddwrt capable router and run the native android (or I assume apple has the same) vpn client and have it auto connect. That way you will always be on vpn. The only downside is if your home internet connection has slow upload speed it will throttle your phone's effective download speed. I have 12 megs up at home which is about the same speed as my sprint download so it doesn't really change anything.
Scottmichaelj Posted February 20, 2016 Posted February 20, 2016 Hi Scott, I did answer the question in another post you made. If it does, then why do you need ISY? Why not just use RTI? With kind regards, Michel Why not just fix the SSL for the ELK module you sold me and broke? With kind regards, Scott
Michel Kohanim Posted February 21, 2016 Posted February 21, 2016 Hi Scott, We will fix it but do not have an ETA. In the meantime, please send your UUID to sales@universal-devices.com and I'll make sure you get a full refund. With kind regards, Michel
Scottmichaelj Posted February 21, 2016 Posted February 21, 2016 Hi Scott, We will fix it but do not have an ETA. In the meantime, please send your UUID to sales@universal-devices.com and I'll make sure you get a full refund. With kind regards, Michel I didnt ask nor do I want a refund but its nice you are offering for other customers who may. I still want the module, I just want SSL back. I already bought the plugin for Mobilinc so Im all in at the moment. Where is the fix on your "to do list"?
Michel Kohanim Posted February 21, 2016 Posted February 21, 2016 Hi Scott, I am not sure what "back" means. ELK firmware (in ISY) has not changed for over 3 years now. Based on our experiences with 5.0.x and all the missed deadlines, I cannot give any ETAs above and beyond saying that it has medium priority. With kind regards, Michel
jasont Posted February 21, 2016 Posted February 21, 2016 As someone new to ISY that's highly considering an ELK purchase later this year, I'm trying to learn as much as I can. What actually changed that prevents the ISY from accessing the ELK over a secure port?
apostolakisl Posted February 22, 2016 Posted February 22, 2016 Assuming your Elk and your ISY are on the same, private LAN, not sure that a secure port matters.
MWareman Posted February 22, 2016 Posted February 22, 2016 It was a change in the firmware of the M1XEP that broke the SSL connection from ISY. The M1EXP does SSL in a non-standard way now... I, like many, are now not using SSL for the connection between the ISY and Elk. The risk is low though - both devices are hard wired to my internal network. No external access at all to the Elk.
jasont Posted February 22, 2016 Posted February 22, 2016 Remote management is my concern. If the ISY is the only factor behind having to turn off the ELK's secure port, I was just curious why.
jasont Posted February 22, 2016 Posted February 22, 2016 No external access at all to the Elk.Are you able to manage everything on the ELK ok with no direct external access to it? If it was an ELK firmware update that made the ELK SSL behave in a non-standard way, are folks griping at ELK to fix it? From some tones in this thread, it seemed like UDI did something on the ISY that broke it.
Michel Kohanim Posted February 22, 2016 Posted February 22, 2016 Hi jasont, As mentioned before, we have not done anything to ELK code for the past 3 years. With kind regards, Michel
MWareman Posted February 22, 2016 Posted February 22, 2016 You do *not* have to disable the SSL port on the Elk. You just configure ISY to connect to the non-SSL port. Both can be active on the Elk at the same time. Just don't port forward the non-ssl port..
MWareman Posted February 22, 2016 Posted February 22, 2016 Are you able to manage everything on the ELK ok with no direct external access to it? If it was an ELK firmware update that made the ELK SSL behave in a non-standard way, are folks griping at ELK to fix it? From some tones in this thread, it seemed like UDI did something on the ISY that broke it. 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.
Scottmichaelj Posted February 22, 2016 Posted February 22, 2016 Hi jasont, As mentioned before, we have not done anything to ELK code for the past 3 years. With kind regards, Michel Love the verbiage Per your post here it was "Firmware" 4.2.30 that broke it not a change in the Elk module. Firmware upgrade to 4.2.30 broke secure port link with Elk - how to fix? http://forum.universal-devices.com/index.php?/topic/16529-Firmware-upgrade-to-4%2E2%2E30-broke-secure-port-link-with-Elk---how-to-fix%3F So then with port forwarding enabled on your router it exposes you to the internet. From there because the M1XEP has SSL turned off along with username and password anyone can then have open access to it and your alarm system. Thats why I find this a priority to fix or alternative solution like portal access like others suggested. If any device needs to talk to another device on your network it should all be done as securely as possible or at least with some basic protections like username and password.
MWareman Posted February 22, 2016 Posted February 22, 2016 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.
jasont Posted February 22, 2016 Posted February 22, 2016 You do *not* have to disable the SSL port on the Elk. You just configure ISY to connect to the non-SSL port. Both can be active on the Elk at the same time. Just don't port forward the non-ssl port.. So is the catch with this that you can't use a username or password on the ELK when connecting via TLS?
Scottmichaelj Posted February 22, 2016 Posted February 22, 2016 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. Thanks MWareman your absolutely right. Michel using a play on words was what I was pointing out. The ElK module was not touched, it was the FW. If he took time to explain this like you have things would be clearer. I do hope we do get a fix for this in v5.
rccoleman Posted February 22, 2016 Posted February 22, 2016 It sounds like it's in the M1XEP firmware, and the responsibility of Elk, not UDI.
Scottmichaelj Posted February 22, 2016 Posted February 22, 2016 It sounds like it's in the M1XEP firmware, and the responsibility of Elk, not UDI. Actually Elk has updated their firmware to support the changes and is in compliance. You can read up about it directly on their site on the M1XEP page. Its the UDI firmware that removed it and MWaremans excellent explanation describes why the changes. This was acknowledged by Michel in the thread I previously posted.
MWareman Posted February 22, 2016 Posted February 22, 2016 So is the catch with this that you can't use a username or password on the ELK when connecting via TLS?You can leave the username/password enabled on the M1XEP. It only applies to incoming secure connections. The ISY should be configured to connect to the non-secure port using a user code for authentication.
jasont Posted February 22, 2016 Posted February 22, 2016 You can leave the username/password enabled on the M1XEP. It only applies to incoming secure connections. The ISY should be configured to connect to the non-secure port using a user code for authentication. So if inside the house, the ISY connects over the non-secure port with a user code, and then if you wanted external access directly to the ELK, you can port forward the secure port (with a username/password), I guess I'm lost as to where the issue is. Doesn't sound like you'd ever have to expose the non-secure port to the Internet for direct access.
MWareman Posted February 22, 2016 Posted February 22, 2016 So if inside the house, the ISY connects over the non-secure port with a user code, and then if you wanted external access directly to the ELK, you can port forward the secure port (with a username/password), I guess I'm lost as to where the issue is. Doesn't sound like you'd ever have to expose the non-secure port to the Internet for direct access. All correct. As long as the ISY is on the same network as the M1XEP. It how most of us use this. I actually don't even port forward the M1XEP secure port. I've developed Tasker functions to perform the Elk operations I need via the ISY REST interface. No need to talk directly to the Elk.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.