Windows 10 issues with ELK

DELInstallations said:
I can't fault Elk with this completely. Yes W10 has been beta for a while, but in the same breath, how many pieces of hardware have you run across that won't work on W10....I've got a pile of them. W10 literally just dropped and the major's out there are staying away for at least the first quarter while MS and others work on the bugs and what has been found so far. Unfortunately, until the final was made public, it's all conjecture to put a compatibility together.
 
There is the option to use the developer section in W10 to run a VM of an earlier version. I want to say there was a few good links out there with how-to's.
 
How the changes affect the XEP and M1 is a different question, as the hardware could use a little update itself. Been out for over 10 years.
 
This is not a hardware driver problem though, it's just dropping support for an insecure SSL/TLS version and insecure certificates. The major browsers all did it at least a year ago. Elk just didn't have the presence of mind to see the writing on the wall. And I'll see if I can find it, but I'm sure at some point Microsoft made an announcement that they were dropping support. The various SSL/TLS vulnerabilities have received plenty of media attention so there's no excuse for them not to know.
 
I couldn't agree more that the M1XEP needs a hardware update, as clearly Elk is struggling to squeeze in features (they dropped the Virtual Keypad in order to be able to find enough room to add M1Cloud support). There is a third party module out there http://www.setechautomation.com/category-s/1817.htm that is supposedly 2-3 times faster than the M1XEP and claims it uses a 1024 bit RSA key. I'm not sure if it will still suffer from the same issues, but from what I recall you lose IP monitoring and M1Cloud support.
 
Maybe if we get a a new M1XEP we'll finally get IPv6 support (hah!)
 
I'll agree to disagree here.
 
I'd say if anything, it's more prudent for an alarm manufacturer to wait for the software to come out and then address the specifics after the code is finalized and initial bugs are ironed out. I'll point out that at the time Win7 was coming out and gaining traction, I was working for Notifier (Honeywell fire alarm) and they didn't have a permanent fix and items addressed until a quarter after Win7 dropped to the public. It was also at least 5 years before they moved and migrated their OEM workstation OS off XP. This was a company that had 4 major fire alarm manufacturers under the same roof.
 
That said, I am more thankful that they didn't rush to market with a half baked solution. I'd rather they start engineering the M2 or M1G+ at this point. IPV6 isn't a deal killer, but the hardware not being able to do what a contemporary panel at half the cost can do...and have full UL listings is.Elk needs to get out of their bringing the Ness products over here and start working on the real solutions needed or wanted by the core market.
 
DELInstallations said:
I'll agree to disagree here.
 
I'd say if anything, it's more prudent for an alarm manufacturer to wait for the software to come out and then address the specifics after the code is finalized and initial bugs are ironed out. I'll point out that at the time Win7 was coming out and gaining traction, I was working for Notifier (Honeywell fire alarm) and they didn't have a permanent fix and items addressed until a quarter after Win7 dropped to the public. It was also at least 5 years before they moved and migrated their OEM workstation OS off XP. This was a company that had 4 major fire alarm manufacturers under the same roof.
 
That said, I am more thankful that they didn't rush to market with a half baked solution. I'd rather they start engineering the M2 or M1G+ at this point. IPV6 isn't a deal killer, but the hardware not being able to do what a contemporary panel at half the cost can do...and have full UL listings is.Elk needs to get out of their bringing the Ness products over here and start working on the real solutions needed or wanted by the core market.
 
 
Not trying to be obstinate, the issue is not that Windows 10 broke compatibility with the M1XEP, it's that the M1XEP is insecure. The problem exists with or without Windows 10. It has nothing to do with "waiting until the bugs are ironed out," Microsoft announced they'd discontinue support for insecure protocols. The implementation doesn't matter (it's not like Microsoft is modifying or creating some API), they are just doing what many browser vendors have already been doing for a long time. The broken connectivity is only a symptom of the insecure protocols they're using. The version of SSL/TLS it is using has known vulnerabilities (that have been actively exploited). 512 bit RSA keys haven't been considered secure for a very long time. While it *might* have been forgivable in a LAN-only or limited single panel per residential Internet connection environment (although I don't truly believe that), the problem should have been corrected long ago, and certainly before they launched M1Cloud. You see, if anyone was ever able to MITM in front of their M1 cloud server (which is not as hard as you think), they could intercept and control *every* M1Cloud user's panel. Ever heard of POODLE? Just want to reiterate this is not a Windows problem, it's a security problem. From a security company.
 
As far as IPv6 goes, I agree it's not a necessity for an alarm panel *today*; but as you might be aware the IPv4 free pool has been exhausted, given the longevity of the current M1XEP (and presumed longevity of the next one), and the emergence of the IoT (which I presume Elk wants to be a part of, at least in some fashion) it will be required soon, so best to bake it in today so it's fully baked when it truly is required.
 
For your reference: http://azure.microsoft.com/blog/2014/10/29/protecting-against-the-ssl-3-0-vulnerability/
 
I'll still agree to disagree in the totality of the argument here.
 
@ Geisen, yes, all of that is true, however it's also true that this will be a larger issue. If you can't update them, then support via W10 is not possible. This holds true across the board with boatloads of hardware in the world. From a basic NIC all the way up to a BAS system device costing tens of thousands of dollars. Keep in mind, the M1 and XEP are already a teenager and in the IT world, that is a very long time compared to security changes. In my industry, I don't know if you're aware of the sheer volume of devices that connect in a building's BAS via TCP/IP (excluding legacy pre-IP devices)

You can't fault MS for closing a security vulnerability, however the inability to support legacy devices (and allow them to fail and be replaced with newer that only support the new protocol) should be what is the key issue here. I can still boot a PC using BIOS and a floppy drive as a choice but I have no support for earlier non-upgradable hardware other than running a VM to an earlier version of windows, and hopefully what I need hardware-wise is available virtualized or a yank and replace. It's going to be a huge issue moving forward for anything that is running it's own private network and the servers/pc's change and the OS can't be rolled back or available (or driver issues).
 
I'd look at this as a problem with both MS (as there should be some easily usable legacy support) and Elk/other manufacturers. The M1 is not the panel/platform that is going to exist moving forward to address those issues; It simply does not have the memory or hardware capability and it's already long in the tooth, not necessarily from a software standpoint, but from the sheer hardware and capabilities (UL listings for newer FA hardware,no multiple 2 wire fire zones, no addressable fire support, rules storage space, power capabilities onboard, limited KAM options, limited siren action based on ZT-I don't need a flood to set off a siren....etc). IoT may happen, may not. That's a whole different discussion and what it may or may not support..
 
I updated my XEP firmware using the link above and then updated my system to Windows 10.  So far RP operating under Windows 10 seems to be able to connect to my M1 via the XEP.
 
I think in this case Windows 10 probably took too aggressive a stand for security superiority – even though Microsoft has been sending smoke signal for over three years  that 512,768 RSA will be blocked (http://blogs.technet.com/b/pki/archive/2012/06/12/rsa-keys-under-1024-bits-are-blocked.aspx) .  I am curious now if the six second connection RTT delay will increase if the latest firmware changed the keysize to 1024. I suspect the M1XEP is a very small embedded CPU, so the key exchange overhead cannot possibly be good for RTT.
 
Has anyone here tried the ST-EG100-EFW firmware for the XEP or the SETECH ST-EG100-E board?  Expect for the price these sound good. They seem to address many of the missing features of the XEP.  Interesting that the ST-EG100-EFW is firmware to run on the ELK XEP hardware.  The same hardware that ELK claims can't insert variables into email notifications. SETECH seems to have implemented it.  And they implemented an HTTPs based Remote keypad (not java).  Why hasn't Elk implemented these features or bought out SETECH's version?
 
Has anyone tried these products?
 
crossbar said:
Has anyone here tried the ST-EG100-EFW firmware for the XEP or the SETECH ST-EG100-E board?  Expect for the price these sound good. They seem to address many of the missing features of the XEP.  Interesting that the ST-EG100-EFW is firmware to run on the ELK XEP hardware.  The same hardware that ELK claims can't insert variables into email notifications. SETECH seems to have implemented it.  And they implemented an HTTPs based Remote keypad (not java).  Why hasn't Elk implemented these features or bought out SETECH's version?
 
Has anyone tried these products?
 
That is pretty interesting.  I wonder if you load this firmware onto the xep if that is a one way process?
 
It is pretty rare to see a third party write firmware like this.  
 
I also wonder if there are any issues linking my isy 994 with this firmware.
 
Edit:
Just sent an email to them asking.
 
Their manual outlines the procedure to go back to the Elk firmware.  Which also makes me wonder if you could use their firmware loader to roll back to a pre V2 Elk firmware.  I do wonder why you would not be able to go back to pre V2 firmware with Elk.  There should be no reason you can't load older firmware onto a device (unless the loader does not support it).  Or unless ELK just doesn't want people to do it.
 
Support emailed me back to say what you said, that you can go back.  He did not specify if it had to be the same version or if you could go to older versions.  He also said it works fine with isy.
 
The 3rd party vendor software loses the TCP/IP monitoring and audio support. I'm pinging them for more information, but there has to be more to it.

The way it appears to me is that their firmware doesn't touch the bootloader, it overlays the firmware on the base M1 boot and runs that way, or it blows out the OEM FW. To me, the smoking gun is the loss of certain items, which would point to items are left in memory or there's only so much memory available, or both. Then again, their price point is higher than a XEP in itself.
 
Notice XEP V1.xx no longer compatible with Windows 10 and ***Windows 7 (with updates)***.
 
So now this is an issue with Windows 7 as well.  With the latest updates to Windows 7 you can no longer connect the the pre V2 XEP.  I had to rollback my Win7 to the last restore point before the updates and update my XEP to 2.0.42.  Upgrade went ok.  Reverted to a static IP that is NOT the default but would not respond to that IP (used the find function found it but could not connect).  I could ping the device but not connect to it on that IP.  Did the JP2 power cycle configuration to get it set back to DHCP like it was and then all was good.
 
V2.0.42 Broke email.  Now only works if you actually use the user authentication (so even if you are using your own mail server on the same network you still need to set up a user for the XEP to authenticate to send mail).  We'll see if anything else is broke.
 
After the XEP update and the Win 7 Updates again, I can again connect to the XEP so looks like we should be good for a little while longer with XEP V2 (Until the next update that bring to light another out of date function of the XEP).
 
"Thing" THANKS for posting this. I spent about three hours last night rebooting M1XEP, M1+M1XEP, Turning Off Virus Protection, Going to Elk support site, Update lastest ElkRP, and nothing worked. I was just getting ready to trying a use a wife company laptop and spend even more time.
 
I suspected that a Windows update caused this problem because I connect three weeks ago. A packet capture revealed that the ElkRP disconnected after receiving TLS ServerDone message. M12Go gave a “Cannot authenticate..” Elk should really provide a more accurate message than, “Connection error: Could not connection. Possible reasons: The port is not forwarded through the router…” ElkRP can connect, but there’s an SSL problem. The message should give the correct reason.
 
Elk M1XEP needs to implement TLS 1.2 or stop using the WinInet API. In addition, Elk should install a real certificate – not self-signed. Elk gets away with using self-signed certificate because they control the client software. But they claim that M1XEP is an open platform. This is going to be next blocking problem in my opinion.
 
I am quite shocked that Elk support site doesn’t have a high priority message that a good percentage of customers cannot connect their M1XEP’s. This sucks, if you don’t have a restore point, you have to find an old Win7 version. I guess I could see if Microsoft has issue a recent patch or technote to restore old behavior.
 
I double checked to see if there is some TLS specific issue with ElkXEPv2 (maybe my M1XEP firmware become corrupted). I have the next to last v2 firmware (not latest with Windows10 support). I have been using the v2 firmware for quite some time without any problems.
 

 

openssl s_client –tls1 –connect 10.1.1.1:2601
CONNECTED(00000100)
---
Certificate chain
 0 s:/C=US/ST=NC/L=Hildebran/O=Elk/OU=Engineering/CN=M1XEP
 i:/C=US/ST=NC/L=Hildebran/O=Elk/OU=Engineering/CN=M1XEP
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIChTCCAi+gAwIBAgIJAOvnnQvavL4ZMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJOQzESMBAGA1UEBxMJSGlsZGVicmFuMQwwCgYDVQQK
EwNFbGsxFDASBgNVBAsTC0VuZ2luZWVyaW5nMQ4wDAYDVQQDEwVNMVhFUDAeFw0x
NDA0MjIyMDQ4MDJaFw0yNzEyMzAyMDQ4MDJaMGIxCzAJBgNVBAYTAlVTMQswCQYD
VQQIEwJOQzESMBAGA1UEBxMJSGlsZGVicmFuMQwwCgYDVQQKEwNFbGsxFDASBgNV
BAsTC0VuZ2luZWVyaW5nMQ4wDAYDVQQDEwVNMVhFUDBcMA0GCSqGSIb3DQEBAQUA
A0sAMEgCQQDS59/zVQiF6stPRF2L9MmODUc0U+UHnSVenNMqRe1e4vqd40xU94pT
4Tcs+1zCtT6QwFeQVyNDyd43urhBchNvAgMBAAGjgccwgcQwHQYDVR0OBBYEFJpE
H5xBX7Z8McHI9/+x8oVD2uE5MIGUBgNVHSMEgYwwgYmAFJpEH5xBX7Z8McHI9/+x
8oVD2uE5oWakZDBiMQswCQYDVQQGEwJVUzELMAkGA1UECBMCTkMxEjAQBgNVBAcT
CUhpbGRlYnJhbjEMMAoGA1UEChMDRWxrMRQwEgYDVQQLEwtFbmdpbmVlcmluZzEO
MAwGA1UEAxMFTTFYRVCCCQDr550L2ry+GTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3
DQEBBQUAA0EAYInnUJmlwNax5Y9Roz03amMr14cx129MGAaL4xRzZ9DeeQk8o2lf
p9Tka4YKurslTND451boSH1AbOg5ig8CRw==
-----END CERTIFICATE-----
subject=/C=US/ST=NC/L=Hildebran/O=Elk/OU=Engineering/CN=M1XEP
issuer=/C=US/ST=NC/L=Hildebran/O=Elk/OU=Engineering/CN=M1XEP
---
No client certificate CA names sent
---
SSL handshake has read 806 bytes and written 362 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 512 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 1C7F5B473C65F781492130D6C41B55BC95C3AEB8201BFEF1947909CF9E28AAAA
    Session-ID-ctx:
    Master-Key: EA86485EAA9BDB083F2CDD6342D4155989B58DA0902D16969CCB87FE0E82746925C455A0C53AED06274F5FE0400B66B8
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1474701093
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
---


Username: xxxxx
Password: *******
Elk-M1XEP: Login successful.
 
 
 
Back
Top