At wit's end with pushover.net

[jasonl99]

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]

http://wiki.universal-devices.com/index ... r_Messages

[jasonl99]

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]

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]

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]

This ever get resolved? I'm using pushover via email but was going to change to direct API and saw your post.

 

Bill

[bsobel]

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]

bsobel,

 

This is NO bug:

http://www.universal-devices.com/docs/I ... 0Guide.pdf

 

With kind regards,

Michel

[bsobel]

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]

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]

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]

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]

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]

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]

 

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]

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]

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]

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]

Hi Michael,

 

Thank you for your comments and suggestions and I agree with you.

 

With kind regards,

Michel