Jump to content

Can't Connect To Secure Port After Firmware Upgrade


shannong

Recommended Posts

Posted

I just upgraded the firmware on the M1XEP to v2.0.30. Now the ISY can't stay connected to the secure port.

 

It says it successfully connects and attempts to query zones and refresh the topology. This never completes. Then the ISY shows it disconnects and starts over again,

 

I have discovered that while the ISY is attempting to connect and query I also can't connect with ElkRP to the secure port and my phone app can't either. So whatever is occurring jams up the M1XEP.

 

While connected with ElkRP, I sent configuration to the M1XEP and rebooted it.

 

 

On a side note for the UDI guys, the Elk configuration page still says "SSL" rather than TLS.

 

 

Sat 04/04/2015 02:25:59 PM : [ELK         ] Disconnect SSL
Sat 04/04/2015 02:25:59 PM : [ELK         ] Connect SSL
Sat 04/04/2015 02:26:00 PM : [ELK         ] Connect SSL Successful
Sat 04/04/2015 02:27:08 PM : Elk Query All Failed, requesting retry
Sat 04/04/2015 02:27:21 PM : [ELK         ] Disconnect SSL
Sat 04/04/2015 02:27:21 PM : [ELK         ] Connect SSL
Sat 04/04/2015 02:27:27 PM : [ELK         ] Connect SSL Successful
Sat 04/04/2015 02:27:46 PM : Elk Query All
Sat 04/04/2015 02:28:31 PM : [ELK         ] Disconnect SSL
Sat 04/04/2015 02:28:31 PM : [ELK         ] Connect SSL
Sat 04/04/2015 02:28:40 PM : [ELK         ] Connect SSL Successful
Sat 04/04/2015 02:29:30 PM : Elk Query All Failed, requesting retry
Sat 04/04/2015 02:29:49 PM : [ELK         ] Disconnect SSL
Sat 04/04/2015 02:29:49 PM : [ELK         ] Connect SSL
Sat 04/04/2015 02:29:54 PM : [ELK         ] Connect SSL Successful
Posted

I sent this to ELK and they replied:

 

"If he's able to reconnect with RP have him Resend the M1XEP and allow the M1XEP to reboot. Once the reboot is complete power cycle the M1XEP and the ISY. "

 

 

Sorry for brevity - posted using mobile Tapatalk

Posted

I had already sent to the M1XEP and rebooted it. <post updated>

 

Rebooting the ISY seems futile. I did it anyways and the problem still persists.

 

Was the second reboot for the M1XEP supposed to be for the M1? Either way, I had rebooted it also.

Posted

Update on this issue.  I was able to recreate the issue on my own M1.  It appears we are having issues communicating with the M1 using the secure port, more than likely due to our enhanced security and depreciation of SSLv3.  We'll work with Elk to figure out a solution.

 

In the meantime I was able to connect to the M1 using the non-secure port only after I disabled the username/password in M1XEP Setup and unchecking SSL in the ISY Admin console.

 

  1. Open ELKRP2
  2. Click the M1XEP setup button in the lower right
  3. Go to the Passwords tab
  4. Check "Disable username/passwords"
  5. Connect to your M1 using RP2 and push changes to the controller
  6. Go to the ISY Admin console go to Configuration | Elk | Configuration
  7. Put the non-secure port number in the Port field (typically 2101)
  8. Uncheck SSL
  9. Save

The M1XEP will reboot and your ISY will connect successfully.

Posted

I don't think the M1XEP supports anything other than SSL3, at least not in my testing. When my Android device upgraded to 5.0 my 'myKeypad' app was not able to connect to the XEP anymore. I built a reverse proxy (using stunnel) to allow Android to connect with TLS but then it connected to the M1XEP with SSL3 and that got it working. It was a workaround for me as well for this issue.

 

Mike: I believe you are spot on. Not sure what you can do to fix it though - you need to convince Elk to support TLS and modern ciphers on the XEP.

Posted

I don't think the M1XEP supports anything other than SSL3, at least not in my testing. 

 

Prior to this upgrade of the M1XEP, the ISY was connecting to the Elk on the secure port. Recall that SSL had already been removed from the ISY and the ISY was still connecting to the Elk on the secure port prior to this upgrade. So it doesn't seem that the M1 only supports SSL and lacks support for TLS.

Posted

Hi shannong,

 

As per ELK, secure port communication requires and out of band user id/password (not part of any SSL/TLS specification) and we have never supported this.

 

With kind regards,

Michel

Posted

As it turns out, the M1 doesn't REQUIRE u/p for connecting to the secure port, but it CAN use it.

 

If the option for "Disable username/passwords" is enabled in the M1XEP setup, then the ISY can connect to the secure port.

 

Apparently what changed with this new version was the nag message when you open the setup that says you have no u/p configured for apps. So I configured a u/p and that started the problem with the ISY connecting.

 

The only other app that connects to my M1 is myKeypad on Android, and it doesn't require the use of a u/p either, though it supports it. I only make local connections on the LAN (or via VPN) to the M1 with only a few select IPs allowed to connect. The additional use of u/ p won't gain me much additional security vs what I lose by having the ISY connect non-secure. The ElkRP app doesn't use u/p to connect either and relies solely on the Access Code (PIN) to authenticate.

 

It's not worth it to me to setup stunnel to sit in between the M1 and ISY to proxy the SSL sessions considering there isn't much security gained with the addition of u/p authentication.

Posted

I believe two form authentication is always more robust than simply relying on a 4-6 digit code. Couple this with HTTPS its extremely hard for someone to access the security alarm system.

  • 8 months later...
Posted

What is the latest update on the Elk module and the compatibility with the username and password.  I've upgraded Elk to the latest software and now I started seeing Connect Disconnect traffic storm from ISY to M1EXP that also prevents the RP2 software from connecting. I have to turn off ISY and reboot M1EXP before RP2 can connect again.  I have temporarily disabled the username and password option in M1EXP but I need those settings for mobile apps and M1ToGo.

Posted

Hi oskarw,

 

ISY cannot support username/password at TLS layer because it's definitely and out of band mechanism and not specified by TLS. Do you have the same problem with the unsecure port?

 

With kind regards,
Michel​

Posted

Hi oskarw,

 

ISY cannot support username/password at TLS layer because it's definitely and out of band mechanism and not specified by TLS. Do you have the same problem with the unsecure port?

 

With kind regards,

Michel​

Isn't it basic auth wrapped in TLS, just like what the ISY offers? (Caveat, I haven't checked, so am likely completely wrong! This might just prompt me to check though...)

 

Edit: correcting myself. I just realized its not HTTP at all... So not what I thought.

Posted

 

 

Hi oskarw,

 

ISY cannot support username/password at TLS layer because it's definitely and out of band mechanism and not specified by TLS. Do you have the same problem with the unsecure port?

 

With kind regards,

Michel​

I don't think it's out of band, its just a part of the M1XEP protocol post establishing TLS, but on the same session. The M1XEP only uses the username/password on the secure port - it doesn't use it on the insecure port. I myself would like to use the secure port as well, but cannot due to this. I refuse to turn off usernames on the M1XEP because I access this externally as well - and want to use stronger security then just a PIN.

Posted

Hi MWareman,

 

How does this work on TCP?

 

With kind regards,

Not sure yet - I won't have a chance to dig into it until this weekend.

 

My thought is on the TLS port the TCP connection is made a 'STARTTLS' command issued. The TLS is negotiated to secure the socket. After that, the username and password sent in some format before the X1XEP then accepts serial commands over the socket.

 

Elk should be able to provide formal details though... but it should be possible to have the ISY send a username and password when using TLS to connect to the Elk. We just need to find the exact format.

Posted

I agree with MWareman.  Elk team should be able to provide protocol spec that can be incorporated into the Elk module.  That module is the biggest reason why I bought Elk M1 and ISY to complement each other, and now if we have to lower the security (unencrypted traffic or disabling username and password) I don't see these two products as complementary.

Posted

Thank you. We will ask. The last time we spoke with them, the username password had to be sent before Client Hello. Perhaps things have changed but, if not, we won't be able to support it.

 

With kind regards,

Michel

Posted

Thank you. We will ask. The last time we spoke with them, the username password had to be sent before Client Hello. Perhaps things have changed but, if not, we won't be able to support it.

 

With kind regards,

Michel

If this is true, it likely means the username (if not the username and password) are being sent before the STARTTLS, and before the communication channel is encrypted. Not good at all!

 

Please let us know what they say!

 

Michael.

  • 2 weeks later...
Posted

Can't we just all get along?. I agree that the reason to have the M1 and the Elk is that they work together. That isn't the case. The end used shouldn't have to be a brain surgeon to get them to work together. There should be a straight forward procedure that anyone can understand to have them work as advertised. Am I wrong about this?

Posted

marshc80,

 

We are. We shall make a change in the upcoming release. In short, ELK will send a username and password prompt after connected securely and we have to fill it in.

 

With kind regards,

Michel

 

Are you saying that Elk is updating the XEP firmware for this to happen, or is this strictly an ISY thing?

 

I'd really like to get my Elk firmware done and finished for the indefinite future and the lack of username/password functionality is the only thing in need of work as far as I am concerned.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...