Firmware upgrade to 4.2.30 broke secure port link with Elk - how to fix?

[Michel Kohanim]

Hi zorax2,

 

Please check your error log for communication errors to ELK. There's something amiss here!

 

With kind regards,

Michel

[zorax2]

Everything is now working properly consistently with no errors.  Thanks for the help!

[Scottmichaelj]

Hi cyberk,

 

4.2.30 disabled SSL ... ELK was still using SSL up until recently with their new firmware.

 

True: you cannot secure TLS with username/password as it's an out of band from TLS specs perspective.

 

With kind regards,

Michel

Michel- Any ETA to fix SSL with the Elk module and M1XEP? Been about 6 months without a fix.

[Michel Kohanim]

Hi Scott,

 

No.

 

With kind regards,

Michel

[Scottmichaelj]

Official statement regarding this issue has been released by ELK Products on 05/12/16

 

 

Q & A – RE: Elk/Universal Devices Connectivity

 

Question - Does the ELK-M1XEP Network card support encryption negotiation standards SSL 3.0 & TLS 1.0?

Answer - Yes, the M1XEP has supported SSL 3.0 & TLS 1.0 since it was first released.

 

Question - How secure is SSL 3.0?

Answer - A number of years ago SSL 3.0 was found to have vulnerabilities. The industry as a whole moved to TLS 1.0 as the replacement.

 

Question - How secure is TLS 1.0?

Answer - TLS 1.0 is quite secure and remains in wide spread use today. However there have been vulnerabilities uncovered in TLS 1. 0 which has prompted the industry to gradually move to the next generation encryption negotiated standards TLS 1.1 & TLS 1.2.

 

Question - Does the ELK-M1XEP Network card support TLS 1.1 or TLS 1.2?

Answer - Not at this time. The code libraries necessary to support TLS 1.1 & TLS 1.2 are not currently available for the network i nterface chip that Elk currently uses on the ELK-M1XEP.

 

Question - Did Universal Devices recently make Firmware changes to their ISY controller to utilize TLS 1.2?

Answer - Yes, in firmware upgrade 4.2.30 Universal Devices adopted TLS 1.2 as the default encryption negotiation method.

 

Question - Has there been any recent Firmware changes to the ELK-M1XEP?

Answer - Yes, in firmware upgrade 2.0.34 Elk lengthened the certificate key from 512 to 1024 bits to add support for Windows 10. W hile this should not have affected connections from the ISY, around this same time some connection issues were reported a nyway.

 

Elk Products and Universal Devices have been working together to investigate whether this single change has affected cyst em connectivity or whether there is another explanation.

 

Elk understands and fully accepts Universal Devices' decision to support TLS 1.2. Universal Devices also understands and accepts Elk’s decision to lengthen the certificate key. Neither of us wish to point fingers or find fault with the other. Both companies are working closely together to resolve this issue.

 

Until we are able to resolve this issue the only way for the ISY to connect with the M1XEP is through the non- secure for t (2101). As long as the ISY Controller and the ELK-M1XEP are both safely inside the customer premises LAN there should b e minimal or no risks.

[Scottmichaelj]

So there you have it. Not sure why ISY wouldn't give us more info. As for the statement "Until we are able to resolve this issue the only way for the ISY to connect with the M1XEP is through the non- secure for t (2101). As long as the ISY Controller and the ELK-M1XEP are both safely inside the customer premises LAN there should b e minimal or no risks." - This also assumes your not using Mobilinc with the Elk Plugin as then you have access from outside the network and therefore DOES indeed have greater risks of outside control of you security.

 

I personally have spoken with Brad Weeks and Amy Strickland at Elk Tech support regarding my concerns. This has been broken for quite some time and hopefully a fix will come sooner than later.

 

As an installer of ELK and ISY I am now looking for alternative systems that are secure and controllable from the outside. DSC security systems seems to be one option along with a Vera controller which also has better ZWave support at the moment.

 

EDIT: At the VERY least we should at least have the option for a username and password working over NONSecure port 2101. This way there is some protection. This has been an issue since October 2015 and we are just now in May getting a acknowledgment there is an issue. SMH

[MWareman]

As long as the ISY Controller and the ELK-M1XEP are both safely inside the customer premises LAN there should b e minimal or no risks." - This also assumes your not using Mobilinc with the Elk Plugin as then you have access from outside the network and therefore DOES indeed have greater risks of outside control of you security.

 

Mobilinc communicates with ISY over TLS, then ISY communicates with Elk plain text on 2101.

There is NO NEED to publish the Elk non-secure port externally, so the statement that the risk is increased by the use of the Mobilinc Elk module is, in fact, incorrect - as long as the LAN the ISY and Elk share is itself correctly firewalled.

 

My app also does it this way - TLS to ISY. Nothing insecure external.

[Scottmichaelj]

Mobilinc communicates with ISY over TLS, then ISY communicates with Elk plain text on 2101.

There is NO NEED to publish the Elk non-secure port externally, so the statement that the risk is increased by the use of the Mobilinc Elk module is, in fact, incorrect - as long as the LAN the ISY and Elk share is itself correctly firewalled.

 

My app also does it this way - TLS to ISY. Nothing insecure external.

Where can I confirm the connection from Moblinc is done via TLS?

 

My understanding is since your still opening up your network (regardless of Mobilinc) to the internet for external control, therefore you could be compromised.

[MWareman]

Where can I confirm the connection from Moblinc is done via TLS?

 

My understanding is since your still opening up your network (regardless of Mobilinc) to the internet for external control, therefore you could be compromised.

If you are only opening an SSL port - you can test the ciphers it supports. It's dependant on the 'Server' settings in the ISY Dashboard.

 

It's true that as soon as you open ANY port, you've increased the risk. Mitigate that with a strong username/password combo that you change regularly.

 

Adding Elk (on 2101) and the Mobilinc module does not change this risk at all.

[Scottmichaelj]

It's true that as soon as you open ANY port, you've increased the risk. Mitigate that with a strong username/password combo that you change regularly.

 

Adding Elk (on 2101) and the Mobilinc module does not change this risk at all.

Michael, the issue here is not specifically SSL but the fact there is no username/password from the XEP to the ISY. If there were this wouldn't be as big of a del to me. Or are you meaning username/password on the higher Mobilinc level?

 

I was trying to find your other posts about SSH to ELK to share with ELK and I couldn't find it any longer.

[MWareman]

There is a username/password required to access the ISY. Without that username/password, the REST endpoints on ISY to send commands to the Elk are inaccessible.

 

Mobile apps designed to work with the Elk module never need to talk directly to the Elk. Only the ISY. The ISY enforces the necessary authentication.

 

A separate username/password to access the Elk is entirely redundant and not required for a secure system, assuming your LAN is correctly firewalled.

[MWareman]

 

 

I was trying to find your other posts about SSH to ELK to share with ELK and I couldn't find it any longer.

I was using stunnel, not SSH. However, that broke when Elk started requiring the username/password since they implemented it in a way that breaks RFC compliant TLS clients (like stunnel and ISY).

[Scottmichaelj]

There is a username/password required to access the ISY. Without that username/password, the REST endpoints on ISY to send commands to the Elk are inaccessible.

 

Mobile apps designed to work with the Elk module never need to talk directly to the Elk. Only the ISY. The ISY enforces the necessary authentication.

 

A separate username/password to access the Elk is entirely redundant and not required for a secure system, assuming your LAN is correctly firewalled.

Understood. Your a security expert, Ill take your word on this.

 

So to be clear, if using Mobilinc to connect to the ISY (and using the Mobilinc Elk plugin) even though you don't have a SSL certificate on the ISY, because the username/password and connecting via TLS connection from Mobilinc to the ISY, this is secure enough and that there really is no additional need for the ISY to connect to the ELK via a secure port as well as with its own username/password?

[MWareman]

 

 

Understood. Your a security expert, Ill take your word on this.

 

So to be clear, if using Mobilinc to connect to the ISY (and using the Mobilinc Elk plugin) even though you don't have a SSL certificate on the ISY, because the username/password and connecting via TLS connection from Mobilinc to the ISY, this is secure enough and that there really is no additional need for the ISY to connect to the ELK via a secure port as well as with its own username/password?

You absolutely need a valid certificate from a publicly trusted CA (or an active Portal connection - either ISy Portal or Mobilinc) to have the secure remote connection. Otherwise, Mobilinc cannot do TLS (the cert is required). Without a valid certificate on ISY there is no TLS and you are at risk.

 

Self signed is insufficient (unless you install the self signed cert as a trusted root on your mobile devices - which I wouldn't recommend).

 

Related: the 'secure' connection to Elk is something of a misnomer as well. Yes - it's encrypted. However, it's based on a self signed key pair - so there is no reference authority for the initial phases of TLS negotiation. Essentially when a client connects there is no checking to see if its a bogus or changed certificate. This opens it up to MITM attacks.

 

The single most important item to secure remote access is a certificate installed onto ISY from a public CA. Or a Portal subscription.

[shannong]

Official statement regarding this issue has been released by ELK Products on 05/12/16

 

 

Q & A – RE: Elk/Universal Devices Connectivity

 

Question - Does the ELK-M1XEP Ne

 

Thanks for tracking this down and posting it.

[Scottmichaelj]

You absolutely need a valid certificate from a publicly trusted CA (or an active Portal connection - either ISy Portal or Mobilinc) to have the secure remote connection. Otherwise, Mobilinc cannot do TLS (the cert is required). Without a valid certificate on ISY there is no TLS and you are at risk.

 

Self signed is insufficient (unless you install the self signed cert as a trusted root on your mobile devices - which I wouldn't recommend).

 

Related: the 'secure' connection to Elk is something of a misnomer as well. Yes - it's encrypted. However, it's based on a self signed key pair - so there is no reference authority for the initial phases of TLS negotiation. Essentially when a client connects there is no checking to see if its a bogus or changed certificate. This opens it up to MITM attacks.

 

The single most important item to secure remote access is a certificate installed onto ISY from a public CA. Or a Portal subscription.

So Michael, this is my concern and maybe I am "just not getting it". What you now are saying and I understand that "self signed certs are insufficient". IIRC the ISY does not allow these any longer either. Then go on to say "so there is no reference authority for the initial phases of TLS negotiation. Essentially when a client connects there is no checking to see if its a bogus or changed certificate. This opens it up to MITM attacks" so then this means the ELK/ISY connection is not secure.

 

Finally you state to use a "Portal subscription" but you can't with Mobilinc outside their Mobilinc connect. Michel has said the ISY portal is not supported for use with Mobilinc and if you want to use Mobilinc and Alexa then your only option is the ISY portal. So that being said, at the end of the day it seems I am correct, the outside connection to the ISY via Mobilinc has security flaws and at the least we need a fix between the ISY and ELK. The only "TRUE" secure connection from Mobilinc to the ISY/ELK is via Mobilinc Connect portal. Anyone using anything else like EKeypad is also at risk.

 

It seems like you are trying to protect ISY for whatever reason here and not sure why. As I dig it seems to me I keep uncovering things.

[Michel Kohanim]

Scott,

 

I am not sure where you get your information from:

http://wiki.universal-devices.com/index.php?title=ISY_Portal_MobiLinc_Configuration

 

With kind regards,

Michel

[MWareman]

Scott,

 

I think we may be using different terms to describe some base concepts, and may be inferring incorrect conclusions from my statements.

 

To correct some errors:

 

Initially, Mobilinc could not connect thru ISY Portal. That is fixed now - so your reference to Michels statement is out of date now. The Mobilinc app works fine against the ISY Portal now.

 

Self signed certificates can provide security - ONLY if you import the same certificate as a root authority on your devices. However, because the same key is used for the SSL and the signature, it presents additional risk that is not present in CA issued certificates. Because running a private CA is beyond the ability of most, I offer the only practical alternatives as either Portal subscription OR a direct connection to ISY with a commercially purchased certificate installed.

 

When I use the term 'Portal Subscription' without the designation 'ISY' or 'Connect', I am being general - meaning either solution. Again, it's NOT correct that the Mobilinc app can only be used with Mobilinc Connect.

 

ISY does still allow self-signed certs. However, you can now get commercial certs very inexpensively - so there shouldn't be any need for this. ISY now supports intermediate certificates to enable these lower cost CAs and such a certificate provides very strong protection against MITM attacks. I also encourage UDI to support the LetsEncrypt API for certificates - so the friction in this can be further reduced.

 

You state that 'the outside connection to ISY via Mobilinc has security flaws'. I strongly disagree. However, as an ISY administrator you can, of course, configure it to be very insecure. However, that's your choice, not a flaw.

 

You say 'the only true secure connection from Mobilinc to the ISY/Elk is via the Mobilinc Connect portal'. Again, NOT true. The ISY Portal and a direct connection (no Portal) but with a commercially issued certificate correctly installed also provide strong security, and are viable alternatives.

 

ekeypad is a red herring. It talks to the Elk secure port directly. Even if ISY is talking to the non-secure port.

 

Finally, you appear to be binding the ISY <=> Elk communication to an issue of security between the Mobilinc App and the ISY. The two are completely separate issues and are unrelated to each other.

[Scottmichaelj]

Scott,

 

I am not sure where you get your information from:

http://wiki.universal-devices.com/index.php?title=ISY_Portal_MobiLinc_Configuration

 

With kind regards,

Michel

In response for the info on the ISY/Mobilinc/Portal, this must have changed and I was just not aware. I seem to remember this being an issue but due to the forum issues things are missing. So noted, but also noted is your rude response Michel. Just skip my posts and keep working on v5 and ZWave. You seem to like to "correct" me when I am wrong but pass over my other posts.

 

 

Scott,

 

I think we may be using different terms to describe some base concepts, and may be inferring incorrect conclusions from my statements.

 

To correct some errors:

 

Initially, Mobilinc could not connect thru ISY Portal. That is fixed now - so your reference to Michels statement is out of date now. The Mobilinc app works fine against the ISY Portal now. Understood and yes it appears this has changed. However please don't insinuate that the info WAS wrong. In the past the ISY portal was not working with Mobilinc.

 

Self signed certificates can provide security - ONLY if you import the same certificate as a root authority on your devices. However, because the same key is used for the SSL and the signature, it presents additional risk that is not present in CA issued certificates. Because running a private CA is beyond the ability of most, I offer the only practical alternatives as either Portal subscription OR a direct connection to ISY with a commercially purchased certificate installed. Not all devices are able to be rooted, therefore you are correct you should get authorized SSL certificate.

 

When I use the term 'Portal Subscription' without the designation 'ISY' or 'Connect', I am being general - meaning either solution. Again, it's NOT correct that the Mobilinc app can only be used with Mobilinc Connect. Again it was the case previously, not now, my info was correct but that has changed. Just want anyone reading this to be clear my info was not wrong.

 

ISY does still allow self-signed certs. However, you can now get commercial certs very inexpensively - so there shouldn't be any need for this. ISY now supports intermediate certificates to enable these lower cost CAs and such a certificate provides very strong protection against MITM attacks. I also encourage UDI to support the LetsEncrypt API for certificates - so the friction in this can be further reduced. I think ISY integration with LetsEncrypt would be a good idea as well, however LetsEncrypt expires every 30 days so some type of renewing notification and auto renewing would have to be in place to make this work well. Otherwise just to have something "free" but the hassle of renewing it every 30 days, most people would rather pay. Maybe it would be prudent for Michel to have UDI become a reseller of certs to be use on the ISY the same way QNap does for their NAS devices. This would also give UDI recurring business revenue stream.

 

You state that 'the outside connection to ISY via Mobilinc has security flaws'. I strongly disagree. However, as an ISY administrator you can, of course, configure it to be very insecure. However, that's your choice, not a flaw. I am not saying there are flaws. What I am saying is anytime you open the internet to your local network your taking risks. Nothing on the local network should be left completely open without at least a username and password. Which is currently happening right now with ELK and ISY module. You can't tell me you think this is ok being a security architect.

 

You say 'the only true secure connection from Mobilinc to the ISY/Elk is via the Mobilinc Connect portal'. Again, NOT true. The ISY Portal and a direct connection (no Portal) but with a commercially issued certificate correctly installed also provide strong security, and are viable alternatives. I am not saying this, I thought you were. You said that Mobilinc connected via TSL to the ISY was secure. Then you brought up the CA certs which I then was trying to say the same thing.

 

ekeypad is a red herring. It talks to the Elk secure port directly. Even if ISY is talking to the non-secure port. I can not comment on how the EKeypad app works as I don't use it or sell it. However based on what I have read people have concerns there too.

 

Finally, you appear to be binding the ISY <=> Elk communication to an issue of security between the Mobilinc App and the ISY. The two are completely separate issues and are unrelated to each other.  No, I completely understand how the ISY/ELK/Mobilinc connect and interact, which is the issue I am having. Not having a username/password on the ELK M1 is a concern, however at this time thats the only way it will work with the ISY ELK Module. Now the blame game comes into play who did what. Is it ISY fault? is it ELKs fault? You keep pointing to ELK, ELK says its ISY and they are not doing anything wrong. I honestly could careless who's fault it is, lets fix it! This has been a problem since October and just not being recognized? Still no fix? Again I will say at the VERY LEAST can't we get a username/password back on it?

 

 

My responses in red.

 

Regardless this is not going anywhere. I think people can see my point and read through the lines here and can see whats BS and valid points. At this point I will concede, hoping for a basic username and password fix.

[MWareman]

 

 

My responses in red.

 

Regardless this is not going anywhere. I think people can see my point and read through the lines here and can see whats BS and valid points. At this point I will concede, hoping for a basic username and password fix.

Unfortunately, color does not show up in Tapatalk. I agree though, let's move on. It's taken me many, many years of training and experience to get where I am with regards to security.

 

I also hope for a fix, but we have to await Elk fixing it. That's where the non-standard implementation exists. You appear to be asking for UDI to break their RFC compliant TLS stack to support the Elk. I cannot support such a change and would ask that instead you use your contact at Elk to get the M1XEP TLS stack modified to an RFC compliant state.