Windows 10 issues with ELK

F

foxtail22

Member
Over the last two days, I upgraded 3 of my systems to Win 10.  While there were a few surprises, most of the issues were related to settings not being transferred from my prior Win 8.1 operating systems.  However, I have run into one issue that I have yet to figure out.  Since the upgrade, ELKRP and M1toGo will not connect to the ELK using the secure port.  ELKRP works using the non-secure port, but M1toGo just will not connect.
I get one of two errors.  One being "unable to authenticate an SSL connection".  The other being "unable to connect - likely cause is that the DNS is incorrect or the secure port is not forwarded in the router".
 
The secure port is forwarded and the DNS is correct.  My smartphone M1toGo app connects using the secure port just like it did before.  It is only the Win 10 systems with the ELKRP and M1toGo apps that will not work.  I have tried turning off the router firewall, and the Windows firewall, with no success.  They seems to be acting as if they cannot reach the DNS server on the outbound side.  
 
Does any one have any ideas what the issue might be?  Is this a setting that needs to be changes or are these programs not compatible with Win 10?
 
Perhaps Windows 10 has dropped support for whatever SSL/TLS version the Elk is using (which I'm sure is ancient)?
 
I have wondered about that.  They have dropped a few other things so the older SSL/TLS versions may also be on that list.  The upgrade did require a couple of drivers to be reinstalled and some of the 8.1 settings did not come over on the upgrade.  Other then the two ELK apps, everything else seems to work.  Since the new EDGE browser does not support Java or Active X, it does present a pull down which lets you open them in IE.  IE is not openly available but seems to act as a emulator for non-EDGE compatible apps. Win 10s backward compatibility may have limits when you get to the networking part of things which is where the ELKRP and M1toGo apps seem to be having compatibility issues.
 
I need to correct a statement I made above.  After flushing the settings in M1toGo and then closing and reopening the app and then configuring it to use the non secure port, it does connect with the ELK.  So it is doing the same thing as ELKRP is doing in that it will connect using the non secure port but will not connect using the secure port.  The fact that both apps are doing the same thing while my Smartphone M1toGo app works fine does point to Win 10 no longer supporting the SSL/TLS version used by ELK for secure port authentication.
 
This will require an update of these applications by ELK to move to a newer version of SSL.
 
I haven't loaded Win10 yet. But if it is SSL related, .NET apps seem to use the SCHannel libraries. I found this link which tells you how to change the ciphersuite's your client proposes and their order.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx

I just took a trace an my M1 selected TLS_RSA_WITH_AES_256_CBC_SHA so I would follow the above instructions and put that at the first of the list and see if that fixes it.
 
It looks like the M1XEP only supports SSL3/TLS1.0:
 
$ openssl s_client -ssl3 -connect X.X.X.X:2601
CONNECTED(00000003)
depth=0 C = US, ST = NC, L = Hildebran, O = Elk, OU = Engineering, CN = M1XEP
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = NC, L = Hildebran, O = Elk, OU = Engineering, CN = M1XEP
verify return:1
---
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 822 bytes and written 305 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 512 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : SSLv3
    Cipher    : AES256-SHA
    Session-ID: 88BD2DF1FBA870B888E3B750D3EAAB1FF840E3D2A3A4D33D444B8CB37E0B5F6E
    Session-ID-ctx:
    Master-Key: E74A983005C6BE324E0CF6C129CFB6673851AE152E2F3921A56312D8E9706C8B71833EB5D6D7096209FFD9AAE22A4961
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1438286469
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
---
 
 
 
 
$ openssl s_client -tls1 -connect X.X.X.X:2601
CONNECTED(00000003)
depth=0 C = US, ST = NC, L = Hildebran, O = Elk, OU = Engineering, CN = M1XEP
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = NC, L = Hildebran, O = Elk, OU = Engineering, CN = M1XEP
verify return:1
---
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 342 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 512 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 6C9E5577302B4A7FE4B0ACB799F36F01A5CA1DDBAC92D7173AF4E90D67608F05
    Session-ID-ctx:
    Master-Key: 999D2ABA6EE50B1B78F54ABA234CAFC94DFC4C725714BB97EDCF4413636AEC4FBABE6368F16E6F3AD55A0E803107A832
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1438286525
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
---
 
 
$ openssl s_client -tls1_1 -connect X.X.X.X:2601
CONNECTED(00000003)
2283136:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 14 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1438286594
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---


$ openssl s_client -tls1_2 -connect X.X.X.X:2601
CONNECTED(00000003)
2283136:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 14 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1438286602
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
 
The trace that Wuench took (TLS_RSA_WITH_AES_256_CBC_SHA) is TLS only and supports TLS 1.0, TLS 1.1, and TLS 1.2.  The version that includes SSL 3.0 is a different version then the one that Wuench got from his M1 trace.  It looks like Win 10 does not include this support.  All TLS versions are defaulted off in the Control Panel - Internet Options - ​Advanced section but turning them on does not seem to have any effect.  The directions on the web site reference are for Win 95 and do not work for Win 10.  So far, I have not been able to figure out how to get access to the Schannel table in Win 10.  Win 10 seems to make less detailed configuration items available to the user then prior systems.  The three access areas are Settings, Control Panel, and Computer Management.  There is a Developer Mode that may provide access but with only 2 days of Win 10, I am still learning a lot about how to get at things.
 
I have installed Win10 and it does not appear to be a ciphersuite issues. That ciphersuite is in the list of proposals by Win10. It looks like Win10 uses TLS1.2 and that is causing the issue. Only a small percentage of the internet/apps uses TLS1.2 so that is probably going to cause a lot of issues for apps that haven't upgraded yet. TLS 1.1 is more mainstream, TLS 1.0 is on it's way out. It may also be that ElkRP doesn't specify the TLS protocol to use and just assumes Windows will pick one that works, and Windows goes for the most secure one by default.

I tried editing the SChannel registry keys as described in the article below both enabling TLS 1.0/1.1 and disabling 1.2 but no joy...

https://technet.microsoft.com/en-us/library/Dn786418.aspx

I think Elk owes us an update ElkRP...
 
I was able to disable TLS 1.2 AND TLS 1.1 and get it to move through the SSL negotiation but then the M1XEP closes the connection and reboots. So there seems to be another issues as well on top of the TLS settings.

For now I think just using the non-secure port works until Elk can get this fixed.
 
SSL 3 support has already been dropped from all major browsers running latest OS’s. TLS 1.0 support will be next. Elk should update the XEP to TLS 1.2 (1.3 if standardization is completed in time). This type of compatibility problem will only get worse. Has anybody notified Elk Technical Support about the Window10 XEP compatibility?
 
Same issue here.  Unable to connect using the secure port.  I thought it was a problem with my XEP, but nope.  I can connect fine using the non-secure port (which doesn't thrill me to be using...)
 
Looks like Elk will issue an update on the 24th, the note on their site http://www.elkproducts.com/product-catalog/elk-m1xep-m1-ethernet-interface is claiming the issue is key length, not TLS version. I suspect it's both, and would explain why once wuench fixed TLS version fallback, he was still unable to connect. Note that the update will require a Windows 7 PC as it must connect over the secure port to perform the update.

It's a shame Elk didn't get out in front of this sooner, Windows 10 was in public beta for months and months.
 
Thanks. Just read their webiste. Yeah, pretty bad that they did not test W10. Not sure how it could have been missed. Maybe they are swamped with other things. Hopefully update of XEP goes smoothly and does not create other issues.
 
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.
 
You must log in or register to reply here.

Similar threads

C
Elk m1xep fails to get m1cloud id – connection required
Replies
0
Views
485
Cornfield
C
D
Omnipro network issues
2 3
Replies
31
Views
2K
electron
electron
F
ELK M1 - Can't connect from Outside of LAN using M1toGo or Elk RP2
2
Replies
20
Views
3K
flbbon4123
F
A
New homeowner/router Omni Pro II Reconnecting
Replies
5
Views
685
pete_c
pete_c
I
Network problems viewing IP cameras
Replies
7
Views
702
Ira
I
Back
Top