Notify My Android fails to connect via HTTPS

[bleepblorp]

Hello,

I recently discovered Notify My Android and have been reading posts on the forum that suggests people have successfully been using this with ISY and presumably with HTTPS.

 

If I configure the resource for HTTP and port 80 I can the test notification is received, but not HTTPS. The resource is configured as follows:

 

Specifically, after I press the Test button an Error pops up saying Request Failed and the Resource Response says N/A. Looking in the Event Viewer I find an entry that says the following:

Net-Resource: Failed connecting to http://www.notifymyandroid.com

 

From another thread related to Prowl there was a suggestion to uncheck Verify HTTPS Server in the Network settings of the Dashboard. I have looked into this and it is not checked.

 

Does anyone have a suggestion?

[MWareman]

Do you have an ISY Pro?

[bleepblorp]

Do you have an ISY Pro?

 

I do have an ISY Pro. It is running the latest firmware release, 4.0.5.

[MWareman]

Wanted to make sure. The non-pro units do not support the cipher types needed for the strong crypto needed for accessing SSL sites.

 

Personally, I had NMA going before I upgraded to pro. To enforce SSL, I have a SSL forward proxy running on an internal server - so the ISY does plain HTTP and the SSL is done by the proxy. This has been reliable for me, so have not needed to change it.

 

The only suggestion I have (other than having pro) is to make sure cert checking is disabled in the dashboard. You say you have done that already though.

[MWareman]

I'll follow up - I changed one of my rules to go direct to https://www.notifymyandoid.com (instead of via my proxy), and I am getting "Error Request Failed" on a dialog when I test, and "N/A" in the response window.

 

Strange thing is, the error happens almost immediately, despite having a 4000ms timeout in my settings.

 

I wanted to make sure that www.notifymyandroid.com allows the cipher types that ISY is limited to. I used a quick script to fire every cipher type supported by OpenSSL at their server - and not one combination was rejected. There is no way the cipher type is not supported in my opinion - even the 56 bit ones (heck, they even accepted NULL-MD5).

 

So, back to the failure to connect. I pulled the error log and I see:

 

System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 56

 

(56 is my test rule trying to talk directly to NMA)

 

On the "Errors and Error Messages" wiki page, -170001 is not defined. Clearly, it's a new network module specific error - I am also getting this error from the "Portal-Dispatch" module.

 

I also have seen -170001 occasionally when trying to connect to a non-SSL resource on my LAN - it's wifi connected so can I assume this is a timeout error?

 

-140002 shows up - "HTTP_CLIENT_CONNECTION_TIMED_OUT". Not encouraging - especially since I have a 4000ms timeout on the network resource rule and the error is clearly being returned faster than 4 seconds.

 

Given that my SSL reverse proxy has no issue connecting, I think that this has to be an issue in the networking module on the ISY not observing the specified timeout that is configured with the resource.

 

..but I've been wrong before.

[Michel Kohanim]

Hi MWaverman,

 

170000 is debug/informational messages.

 

-256 means TLS negotiation failed.

-140002 means timeout.

 

So, it seems that negotiations is failing. Can you please let me know what are HTTPS Client settings for your ISY?

 

With kind regards,

Michel

[bleepblorp]

I appreciate you having taken a look at this, MWaverman. I'll take a look at setting up a proxy as well.

[MWareman]

Hi MWaverman,

 

170000 is debug/informational messages.

 

-256 means TLS negotiation failed.

-140002 means timeout.

 

So, it seems that negotiations is failing. Can you please let me know what are HTTPS Client settings for your ISY?

 

With kind regards,

Michel

 

According to the settings in the dashboard, I have 'SSL 3.0' selected, 'Low' and Verify is NOT checked.

 

I'm going to try the other TLS settings to see if they make a difference.

 

Michael.

[MWareman]

Update. In all of these tests, 'Verify' was off.

 

Changed SSL Client to 'TLS 1.0' 'Low'

Sun 2013/06/16 13:24:58 System -5 Start

Sun 2013/06/16 13:25:06 System -170001 [Network] Established

Sun 2013/06/16 13:26:17 System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 56

 

Changed SSL Client to 'TLS 1.1' 'Low'

Sun 2013/06/16 13:28:34 System -5 Start

Sun 2013/06/16 13:28:42 System -170001 [Network] Established

Sun 2013/06/16 13:29:41 System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 56

 

Changed SSL Client to 'TLS 1.2' 'Low'

Sun 2013/06/16 15:37:42 System -5 Start

Sun 2013/06/16 15:37:50 System -170001 [Network] Established

Sun 2013/06/16 15:39:06 System -170001 [TCP-Conn] -256/-140002, Net Module Rule: 56

 

Changed SSL Client back to 'TLS 1.2' 'High'

It worked!

 

Changed to 'SSL 3.0' 'High'

It worked!

 

Changed to 'SSL 3.0' 'Medium'

It worked!

 

It seems that having the strength set to 'Low' causes the failure. Not sure why - since thru openssl I can tell that www.notifymyandroid.com supports all the weak cipher suites (as well as the strong ones).

 

bleepblorp, try going into the dashboard (isy.universal-devices.com/99i/dashboard.jnlp) and setting:

 

'HTTPS Client Settings'

'Protocol' SSL 3.0

'Strength' Medium

'Verify' Off

 

This works for me to go direct.

 

Michael.

[bleepblorp]

It seems that having the strength set to 'Low' causes the failure. Not sure why - since thru openssl I can tell that http://www.notifymyandroid.com supports all the weak cipher suites (as well as the strong ones).

 

bleepblorp, try going into the dashboard (isy.universal-devices.com/99i/dashboard.jnlp) and setting:

 

'HTTPS Client Settings'

'Protocol' SSL 3.0

'Strength' Medium

'Verify' Off

 

This works for me to go direct.

 

This totally worked for me as well. Awesome! Thanks so much for finding the root of the issue and a solution, Michael. Much appreciation!

 

Best regards,

Bertram