jasonl99 Posted December 30, 2012 Posted December 30, 2012 I've been trying to get network resources working with pushover https://pushover.net/api. I have a key and all, but nothing works. The result in the error log is this: Sun 2012/12/30 01:46:42 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 2 Sun 2012/12/30 03:03:15 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 2 Sun 2012/12/30 03:06:41 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 2 Sun 2012/12/30 03:06:59 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 2 Sun 2012/12/30 03:07:35 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 2 Sun 2012/12/30 03:14:12 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 2 Sun 2012/12/30 03:16:20 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 2 Sun 2012/12/30 03:16:47 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 2 Sun 2012/12/30 03:19:52 PM System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 2 The PUT I am trying to run looks like this (my api key and user key have been changed) POST /1/messages.json HTTP/1.1 Host: api.pushover.net:443 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Content-Length: 133 User-Agent: Mozilla/4.0 token=XXXXXXXXXXX&user=xxxxxxxxxxx&title=test&priority=1&message=test+message I have timeout set for 2000 ms (and have tried 15000 just to see). What is -170001 error, and please, could you post a list of these errors somewhere?
Brian H Posted December 30, 2012 Posted December 30, 2012 http://wiki.universal-devices.com/index ... r_Messages
jasonl99 Posted December 30, 2012 Author Posted December 30, 2012 Thanks for that link Brian. If it's time out, that's really strange becuase it happens within 1/2 a second (even when I have the timeout set to 15 seconds -- 15000 ms). I have also used the firefox plug in Resource Test and the post data above works fine, so it has to be something commuication-related.
jasonl99 Posted December 31, 2012 Author Posted December 31, 2012 On a hunch, I just switched it from http (and port 443) to http (and port 80) even though the pushover API says it must be sent securely. Well, apparently not because it worked fine. So there must be something happening with the ISY's use of ssl. I'd still like to get it to work securely, though. Any ideas?
Michel Kohanim Posted December 31, 2012 Posted December 31, 2012 Hello jasonl99, If you are on 99, please check the type of cipher suites that pushover requires as it might exclude the current capabilities of 99. 994 PRO series have enhanced security features (http://www.universal-devices.com/docs/I ... 0Guide.pdf ) and thus a much higher likelihood of success. All this said, you have to figure out what pushover uses. With kind regards, Michel
bsobel Posted January 14, 2013 Posted January 14, 2013 This ever get resolved? I'm using pushover via email but was going to change to direct API and saw your post. Bill
bsobel Posted January 15, 2013 Posted January 15, 2013 Ok its not you, its a bug in the network module. The network module does not support the cipher suite the site uses (and quite a few sites use) and simply won't work with pushover.net unless UDI offers a fix.
Michel Kohanim Posted January 15, 2013 Posted January 15, 2013 bsobel, This is NO bug: http://www.universal-devices.com/docs/I ... 0Guide.pdf With kind regards, Michel
bsobel Posted January 20, 2013 Posted January 20, 2013 On a hunch, I just switched it from http (and port 443) to http (and port 80) even though the pushover API says it must be sent securely. Well, apparently not because it worked fine. So there must be something happening with the ISY's use of ssl. I'd still like to get it to work securely, though. Any ideas? So I have been working on this with Michel and I can't yet explain what we are seeing. A rule created on my system can not send a notification (it appears to connect but the ISY reports a connection error since the remote host closes the connection right after sending a 406). On an ISY test system Michael let me try it sends fine, the rule appears identical so I'm trying to find another setting that may somehow be effecting this. In the meantime you can use pushover.sobel.info on port 80, use the same settings for the body and path (/1/messages.json). This of course trusts your id in the clear (and that my server will relay it) but if you are ok with that you are welcome to use it until we work out the SSL issue directly. Bill
MWareman Posted February 20, 2013 Posted February 20, 2013 More info for everyone. One resource that works, prowl. On a Ubuntu host, I have tested the SSL suite compatability: echo -n | openssl s_client -connect api.prowlapp.com:443 -cipher RC4-MD5 CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/serialNumber=JuOmlkd8/PwBVhskrT8v-p/w5eCFiUy9/OU=GT53872656/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.prowlapp.com i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA 1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIFMDCCBBigAwIBAgIDCeLOMA0GCSqGSIb3DQEBBQUAMDwxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEUMBIGA1UEAxMLUmFwaWRTU0wgQ0Ew HhcNMTMwMTAxMTkyNDMwWhcNMTYwMzA0MDY0NTE2WjCBvTEpMCcGA1UEBRMgSnVP bWxrZDgvUHdCVmhza3JUOHYtcC93NWVDRmlVeTkxEzARBgNVBAsTCkdUNTM4NzI2 NTYxMTAvBgNVBAsTKFNlZSB3d3cucmFwaWRzc2wuY29tL3Jlc291cmNlcy9jcHMg KGMpMTMxLzAtBgNVBAsTJkRvbWFpbiBDb250cm9sIFZhbGlkYXRlZCAtIFJhcGlk U1NMKFIpMRcwFQYDVQQDDA4qLnByb3dsYXBwLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALM3AYr21gqMbIFV6/+w+MZEypZu8V4kUsO/+vhdje8Y Yy7kGp8DiO/6MnqPaToR+Fdwk348J3JRnXPHHkUuZROr11EfNUCGQsTwGZQ+0wM2 Ra3x678cTeQxTmEzkzJ7QM5sBCE2TwU90yEB6FMS1k8ny3hRJpFglPrPRyRa9RoL /XQCl4dNjoVpz4TuVagwZgOOBx6We8tnseW5sbIG6iuDuqjDzYqGdSuUwiD1hleM BsN3HJHRg2gV8AWdul9bbk2KN1xGogNDDTtlTjKpmJUoo1lSLYePFw/tqmNXKNIj cN2+0+YFkDwV6w50nyVJYtr/KiGQk5sacLB8dAe4/o8CAwEAAaOCAbcwggGzMB8G A1UdIwQYMBaAFGtpPWoYQkrdjwJlOf01JIZ4kRYwMA4GA1UdDwEB/wQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwJwYDVR0RBCAwHoIOKi5wcm93 bGFwcC5jb22CDHByb3dsYXBwLmNvbTBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v cmFwaWRzc2wtY3JsLmdlb3RydXN0LmNvbS9jcmxzL3JhcGlkc3NsLmNybDAdBgNV HQ4EFgQU3M32nHXaGsj+FKSbcKrhWsv2HWYwDAYDVR0TAQH/BAIwADB4BggrBgEF BQcBAQRsMGowLQYIKwYBBQUHMAGGIWh0dHA6Ly9yYXBpZHNzbC1vY3NwLmdlb3Ry dXN0LmNvbTA5BggrBgEFBQcwAoYtaHR0cDovL3JhcGlkc3NsLWFpYS5nZW90cnVz dC5jb20vcmFwaWRzc2wuY3J0MEwGA1UdIARFMEMwQQYKYIZIAYb4RQEHNjAzMDEG CCsGAQUFBwIBFiVodHRwOi8vd3d3Lmdlb3RydXN0LmNvbS9yZXNvdXJjZXMvY3Bz MA0GCSqGSIb3DQEBBQUAA4IBAQCQk+iIq1U307L8CdplvL0qCAu5SJGL8FxGccFw OyfRTMCYSUZeM8zsU3eVMBqvWuxoY/Sp1GSz4SD7PyUKE0H2xTeydY7dNd0Msd6i HXY+FJOARjFX8gVVZ82uPSCMT9drb/BMAcF/xMlGECXg2ak+PIbK04PntXmn83HB XWGAMkaREt7q+d7qe35pQ06zO2Fg590pGhnzkbOh2IwZRbYNBn8Z+MB3U4roF4lP E4PuBU7npiHy8E38IJTq79S2puynkhorcC/GPP3iqHcA9+MCSfgdcJQGLTJLehF9 /eF7B8yS+W4Uk14n/4lZ9f3Vb7YQvQL6iPy/ih5U4Axx+DHI -----END CERTIFICATE----- subject=/serialNumber=JuOmlkd8/PwBVhskrT8v-p/w5eCFiUy9/OU=GT53872656/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.prowlapp.com issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA --- No client certificate CA names sent --- SSL handshake has read 3382 bytes and written 383 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: 4BF4093A657111AFD6BB9E8FE6639E9AAFA00823067C1D6EDFD9BB3DCD346B5B Session-ID-ctx: Master-Key: DDF7201B3D6CC192168076675B68B8B1A33126EBCC9916124BAF8452FB08FBA8FBD5050F579177DCFABC5CB6BB1DDC5D Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Compression: 1 (zlib compression) Start Time: 1361379765 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- DONE Success - and explains why the ISY can connect to it. For pushover, the following happens: echo -n | openssl s_client -connect api.pushover.net:443 -cipher RC4-MD5 CONNECTED(00000003) 3073435848:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 64 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- note the handshake failure. This means the cipher suite is NOT supported - and since this is the only cipher suite supported by the ISY (non PRO) - then you simply CANNOT communicate with the host. I tested with: echo -n | openssl s_client -connect api.pushover.net:443 -cipher AES128-SHA and it was successful. So - so can do SSL with either PRO or standard ISYs to Prowl - but to do SSL to Pushover you must have a PRO version ISY. It was not working for me even with the PRO. That was because I had the SSL client set to 'Low' in the dashboard ('Network' / 'HTTPS Client Settings'). I changed that to 'Medium' and from SSL3 to TLS 1.2 - and my issue with pushover.net went away. To me - advertising generic support for the network module to connect to remote SSL sites is a little disingenuous given that it's something of a crapshoot as to what remote servers you can connect to. People seem to buy the network module expecting to connect to any SSL API. I certainly did. It was only after I purchased PRO (due to batch support) that I realized that all my SSL issues went away. Limiting server side SSL in the standard version to me is fine (I, personally, would still pay for the PRO if I wanted stronger SSL on the ISY itself) - but all cipher suites should be available across both versions from a client perspective. Just my opinion. I hope this info helps at least someone else. Bottom line, to work with pushover - you must have the PRO version of the ISY. It's not a bug - it's a 'feature'. Michael.
bsobel Posted February 21, 2013 Posted February 21, 2013 Michael, I went through the same discovery process with this issue. I wound up writing an smtp proxy on my raspberry pi that connects to the pushoverapi directly if the email is sent to the Pushover email alias. This way I could simply use the ISY email configuration (and substitutions) instead of coding a bunch of network resources. In UDI's defense they literally ran out of firmware space on the 99s so couldn't get the required cipher suites on the box. This seemed to be the final nail in the issue, not their willingness to put the feature in. Cheers, Bill
MWareman Posted February 21, 2013 Posted February 21, 2013 In UDI's defense they literally ran out of firmware space on the 99s so couldn't get the required cipher suites on the box. This seemed to be the final nail in the issue, not their willingness to put the feature in. Upgrading to 'PRO' adds the cipher suites as well. That's just a license addition - no additional firmware 'space' is added with the PRO upgrade. I doubt very much firmware space is the underlying reason.
Michel Kohanim Posted February 21, 2013 Posted February 21, 2013 bsobel, thank you. You are 100% correct. MWaverman, I am not sure what you are suggesting: that all Cipher suites should be included in Network Module? Please note: 1. There are customers who want neither so why should they pay for either/all? 2. There are customers who never use Networking module but need the strong cipher suites (Commercial OpenADR) so why should they pay for Networking module? 3. There are customers (actually the majority) who use Networking module solely for communications with LAN devices and do not even know what high security means. So, why should they pay for strong security features? 4. And there are customers (like you) who need both The bottom line is that we are trying to lower the burden on those who do not need ALL the features ALL the time. With kind regards, Michel
MWareman Posted February 21, 2013 Posted February 21, 2013 1. There are customers who want neither so why should they pay for either/all? Perfectly acceptable. 2. There are customers who never use Networking module but need the strong cipher suites (Commercial OpenADR) so why should they pay for Networking module? Again - perfectly acceptable. 3. There are customers (actually the majority) who use Networking module solely for communications with LAN devices and do not even know what high security means. So, why should they pay for strong security features? This is me - and the answer is 'Because I need to be able to connect TO the most possible remote HTTPS services to actually USE the networking module. I, as ythe customer, don't have control over the cipher suites those servers need. To restrict the cipher suites the HTTPS client can connect to simply means it cannot connect to most HTTPS destinations. That the situation people are finding themselves in with Pushover. 4. And there are customers (like you) who need both I 'needed' PRO for the batch functionality. I didn't think I needed it to un-cripple the Networking module. Your advertising for the networking module does not make that clear. To be - there are two possible 'solutions'. 1) Bundle the PRO upgrade with the Networking module. Don't allow the purchase of the 'Networking Module' on non-PRO units. 2) Allow the Networking module to access strong crypto without PRO - just restrict strong crypto for the HTTPS server running on the ISY. I guess there is a 3) as well - you should warn purchasers of the networking module that they cannot connect to HTTPS at all if the HTTPS resource requires strong crypto unless you also buy the PRO upgrade. Michael.
Michel Kohanim Posted February 21, 2013 Posted February 21, 2013 3. There are customers (actually the majority) who use Networking module solely for communications with LAN devices and do not even know what high security means. So, why should they pay for strong security features? This is me - and the answer is 'Because I need to be able to connect TO the most possible remote HTTPS services to actually USE the networking module. I, as ythe customer, don't have control over the cipher suites those servers need. To restrict the cipher suites the HTTPS client can connect to simply means it cannot connect to most HTTPS destinations. That the situation people are finding themselves in with Pushover. I do not think you read #3 thoroughly as it does not characterize you. i.e. LAN only. I 'needed' PRO for the batch functionality. I didn't think I needed it to un-cripple the Networking module. Your advertising for the networking module does not make that clear. Agreed. We shall make it more clear. To be - there are two possible 'solutions'. 1) Bundle the PRO upgrade with the Networking module. Don't allow the purchase of the 'Networking Module' on non-PRO units. Not at all. See #3 above: those who use it to communicate to LAN devices internally 2) Allow the Networking module to access strong crypto without PRO - just restrict strong crypto for the HTTPS server running on the ISY. Same as above. Penalizing those who do not need high security because all they do is communications with their gadgets on the LAN I guess there is a 3) as well - you should warn purchasers of the networking module that they cannot connect to HTTPS at all if the HTTPS resource requires strong crypto unless you also buy the PRO upgrade. Yes, good idea. With kind regards, Michel
MWareman Posted February 21, 2013 Posted February 21, 2013 I contend still that stating that the networking module supports HTTPS without qualifying that its crippled without PRO is what is confusing. I would rather you remove that entirely or outright state that for functional HTTPS support you need to also have PRO. Maybe even disable HTTPS support altogether from the Networking module unless installed on a PRO unit. The error you get when connecting to a URL that wants a stronger crypto than the standard unit can do is extremely confusing. It's currently logging a timeout. It should log a crypto failure. To me - that's the bug here - is logging an irrelevant error and not logging the real issue. Saying now that use of HTTPS in the networking module is intended just for LAN use is a very 'odd' position to take given the usage examples provided on the wiki and other places. Very odd indeed and not something I can really wrap my head around. Nothing in the Network Module documents implies that it's intended for LAN use only - that's just a limitation that I (for one) and many others (given the feedback I got to the wiki article I wrote about notification via NMA and Prowl) perceived. If fact quite the opposite. Why would you implement timeouts on the networking module connecting to URLs that go up to many seconds long - if not for the intent to access resources over latent networks (ie: outside of the LAN). Frankly - why even implement DNS in the networking module - since if all devices are inside the LAN that shouldn't be necessary. Web services on the LAN should have fixed IPs or DHCP reservations, no need to add complexity with DNS on the LAN. How many people run split-dns on their home networks? Many design decisions within the ISY product itself and the networking module in particular seem to make the opposite statement - is was intended to work to access resources on the LAN and the WAN. Anyway, I've said my piece now. Really - you can choose to license however you see fit. For my personal needs - I needed the PRO upgrade and the networking module. I am sure you get frustrated though troubleshooting issues like this - where people continue to purchase the networking module and only when they try to use it to call public REST APIs on most cloud providers find out they also need PRO as well due to the crypto limitation.
Michel Kohanim Posted February 21, 2013 Posted February 21, 2013 Hi Michael, I do not dispute that we need to be more clear with https/networking. If you pour through the forum, there has been only 3 instances of HTTPS issues reported with Networking Module. And, we have NO issues reported to us directly that has not been reported on the forum. Based on the number of modules we sell, 3 is not even 0.01%. Even 100 is an extremely low rate. So, I hope that you can eventually wrap your head around the fact that 99% of Network Module users only do things on the LAN. Apart from updating our documentation and advertisement, the licensing shall remain as is because, otherwise, we will be penalizing those who do not need to pay for additional security. As always, thanks so very much for your feedback. With kind regards, Michel
MWareman Posted February 21, 2013 Posted February 21, 2013 I do not dispute that we need to be more clear with https/networking. If you pour through the forum, there has been only 3 instances of HTTPS issues reported with Networking Module. And, we have NO issues reported to us directly that has not been reported on the forum. Based on the number of modules we sell, 3 is not even 0.01%. Even 100 is an extremely low rate. So, I hope that you can eventually wrap your head around the fact that 99% of Network Module users only do things on the LAN. Apart from updating our documentation and advertisement, the licensing shall remain as is because, otherwise, we will be penalizing those who do not need to pay for additional security. As always, thanks so very much for your feedback. All sounds entirely reasonable to me. Thanks for clarifying that the documentation and advertisement will be corrected to be in line with the experience. I will say I would have added at least one more - had I not 'accidentally' discovered that PRO fixes the 'limitation'. At that point in time, I had spent several hours troubleshooting and finally setup a local HTTP-to-HTTPS proxy to work around it, thinking the SSL client in the ISY was just broken. I never got round to actually reporting this as a 'problem' because I was going to dig in and troubleshoot further before reporting it, and I had a workaround that was working for me. I still do submit that logging this as a 'timeout' in the event logs is hiding the issue. It should be logged as a 'Crypto Failure' - "I tried to connect but the server offered no crypto that I could agree to". Perhaps this can go in 4.x? Best regards, Michael.
Michel Kohanim Posted February 22, 2013 Posted February 22, 2013 Hi Michael, Thank you for your comments and suggestions and I agree with you. With kind regards, Michel
Recommended Posts