j0dan Posted May 27, 2011 Share Posted May 27, 2011 When using HTTPS with the network module, I only get "TCP client connection timed out" errors. Even connecting to sites that I know work. If I change it to HTTP, I at least get the error "TCP client read response failed", which is probably due to me trying HTTP on port 443. All HTTP methods work fine. Any ideas? The lack of logging (HINT HINT) means it's extremely difficult to troubleshoot. Link to comment
Michel Kohanim Posted May 27, 2011 Share Posted May 27, 2011 j0dan, The errors are those that are generated by the server. Timeout means that the server did not even respond within the timeout period that you can configure. Read response failed means 404/401. You should be able to see more information in the Event Viewer. With kind regards, Michel Link to comment
j0dan Posted July 28, 2011 Author Share Posted July 28, 2011 Hi Michel. I'm trying to solve this again. The network settings are correct. DNS works, and I often access it remotely, so that means the gateway is set correctly. Some hosts work, some don't. With https GET on port 443 /, here is what I get www.yahoo.com "TCP client resource moved [Net Module Rule: 12]" (this seems right) www.universal-devices.com "TCP client read response failed [Net Module Rule: 12]" 66.226.88.82 (http://www.universal-devices.com'>http://www.universal-devices.com) "TCP client read response failed [Net Module Rule: 12]" www.facebook.com "TCP client read response failed [Net Module Rule: 12]" www.unetworks.com "TCP client read response failed [Net Module Rule: 12]" 192.168.x.x works fine. A local web server with a self signed SSL cert. With http GET on port 80 / www.universal-devices.com "TCP client read response failed [Net Module Rule:12]" 66.226.88.82 (http://www.universal-devices.com) "TCP client request failed [Net Module Rule: 12:403]" This would be expected. www.yahoo.com "TCP client resource moved [Net Module Rule:12]" Expected. www.asdf.com works! www.unetworks.com works! The Event Viewer shows nothing except when I receive a timeout error. What I'd like to get working in the end is a notification system using http://www.notifo.com Link to comment
Michel Kohanim Posted July 29, 2011 Share Posted July 29, 2011 Hello j0dan, Here's the issue: The network module has a limited buffer size to process the contents of URLs. So, if you go to Universal Devices, the content length is larger than what we can store (for Network Modules) and thus the read/response error. As you have noted, this is not limited to HTTPS. You should see the same behavior for both HTTP/HTTPS. Furthermore, if you go to a URL that does not respond back with an HTTP response, then you are going to see the same error. The main question is whether or not calling the resource does actually do what it needs to do on the remote machine? With kind regards, Michel Link to comment
j0dan Posted July 30, 2011 Author Share Posted July 30, 2011 It's not processing the POST command properly. The result should only be a few lines of text, but since I can't understand the error messages I don't know what is wrong. I test using wget/curl and then enter those same values in the ISY. Link to comment
Michel Kohanim Posted July 31, 2011 Share Posted July 31, 2011 Hello j0dan, Can you copy and paste the contents of the body (Actual) that you are posting? With kind regards, Michel Link to comment
markens Posted October 16, 2011 Share Posted October 16, 2011 I am also seeing problems with https net resource calls, and this seems a good place to post some questions: ISY99 running 2.8.16. (Is this a problem? Is outbound network resource handling better in 3.x?) I have a bunch of http GET resources which work fine. My goal is to shift them over to use https to the same server prior to adding some additional resources. The SSL environment on the server is self-signed certificate, and it listens on a non-standard https port (say port 3000) instead of 443. For my test [A], I simply changed one of my net resources to use https instead of http, and changed port 80 to 3000. Saved new config and click Test. Get popup with error: TCP client connection timed out, net module rule 2. Status monitor says "Net-Resource: Failed connecting to ." Error log is error -140002 Rule 2. This is consistent no matter what timeout I set in the resource conf page. Changing back to http/80 works fine again. So another test : I created another resource to a different virtual host on the same server. Tried with http/80 and it worked fine. Changed to https/3000 and got the same timeout error as above although this time rule 6. What is rule 2? rule 6? Only difference between host configs is that the hostname specified in the self-signed cert is the same as the one called for test , and does not match for test [A]. So this implies there could be a cert validation issue. How strict is the ISY on validating server SSL certs, for both self-signed situations and those where the cert hostname doesn't match the called hostname? (Obviously this doesn't provide optimum security, but it serves my purpose and works fine in other environments). I tried calling other https resources such as google.com, and got the resource moved error as reported by j0dan. Please help me understand the environment in which https resources should work and what restrictions I need to be aware of. Thanks! --Mark Link to comment
Michel Kohanim Posted October 17, 2011 Share Posted October 17, 2011 Hi Mark, Comments below. With kind regards, Michel I am also seeing problems with https net resource calls, and this seems a good place to post some questions: ISY99 running 2.8.16. (Is this a problem? Is outbound network resource handling better in 3.x?) Yes, better but I do not think the problems you are having will be solved by 3.1.x I have a bunch of http GET resources which work fine. My goal is to shift them over to use https to the same server prior to adding some additional resources. The SSL environment on the server is self-signed certificate, and it listens on a non-standard https port (say port 3000) instead of 443. For my test [A], I simply changed one of my net resources to use https instead of http, and changed port 80 to 3000. Saved new config and click Test. Get popup with error: TCP client connection timed out, net module rule 2. Status monitor says "Net-Resource: Failed connecting to ." Error log is error -140002 Rule 2. This is consistent no matter what timeout I set in the resource conf page. Changing back to http/80 works fine again. So another test : I created another resource to a different virtual host on the same server. Tried with http/80 and it worked fine. Changed to https/3000 and got the same timeout error as above although this time rule 6. What is rule 2? rule 6? Rule id is the ID of the rule being activated. ID is the last field in the Network resource table. So, 2 is the entry with ID of 2 and 6 is the entry with ID of 6 Only difference between host configs is that the hostname specified in the self-signed cert is the same as the one called for test , and does not match for test [A]. So this implies there could be a cert validation issue. How strict is the ISY on validating server SSL certs, for both self-signed situations and those where the cert hostname doesn't match the called hostname? (Obviously this doesn't provide optimum security, but it serves my purpose and works fine in other environments). ISY does not validate certificate names except for specific instances such as interaction with a portal server I tried calling other https resources such as google.com, and got the resource moved error as reported by j0dan. That's the correct behavior since doing https://google.com is redirected (status code = 300/301) to another server. ISY does not follow redirects Please help me understand the environment in which https resources should work and what restrictions I need to be aware of. Thanks! The first question I have is what do you get if you use a browser and point to https://your.virtualserver.ip:3000 ? If that works, then we would have to figure out if your server is blocking connections from specific hosts. Apart from that, for https to work, all you need is a server which has a certificate and that listens to that specific port for https --Mark Link to comment
markens Posted October 17, 2011 Share Posted October 17, 2011 Hi Michel, Thanks for the clarifications. Yes, better but I do not think the problems you are having will be solved by 3.1.x OK, I'll stay with 2.8.16 until I'm ready to play with variables. Rule id is the ID of the rule being activated. ID is the last field in the Network resource table. So, 2 is the entry with ID of 2 and 6 is the entry with ID of 6 I'm so blind! Thanks. ISY does not validate certificate names except for specific instances such as interaction with a portal server Good to know. Just to make sure, this means that self-signed certs are ok as well? That's the correct behavior since doing https://google.com is redirected (status code = 300/301) to another server. ISY does not follow redirects Also good to know. The first question I have is what do you get if you use a browser and point to https://your.virtualserver.ip:3000 ? If that works, then we would have to figure out if your server is blocking connections from specific hosts. Apart from that, for https to work, all you need is a server which has a certificate and that listens to that specific port for https Well, it turns out things are a bit more complicated than that. Yes, browser is on same home network as ISY, and server sees requests from the same IP address. And both http/https requests work from the browser, and http from the ISY. Investigating ISY https request further: The server is seeing connection opening and traffic exchanged (SSL negotiation). Using ssldump, I now see what the problem is: The ISY is prepared to use exactly one SSL cipher suite: SSL_RSA_WITH_RC4_128_MD5. My server is prepared to accept many cipher suites, but not that one. Hence the SSL handshake fails. I will now research why my apache server is configured to exclude this cypher suite. Most likely I'll simply enable it and things will work fine. I'll report back with my findings in a few days. Thanks, --Mark Link to comment
markens Posted October 19, 2011 Share Posted October 19, 2011 Success. As I discovered and posted previously, the ISY is prepared to use exactly one SSL cipher suite: SSL_RSA_WITH_RC4_128_MD5. So any server it communicates with must allow this suite. In openssl (and apache) terminology, this is suite RC4-MD5. Most server configurations probably allow this by default, which is why the ISY https "timeout" problem is spotty. But ciphers using MD5 are considered undesirable at this point, and many security-conscious sites have disabled them. I forced RC4-MD5 to be accepted on my server, and the ISY is now happily talking to it. Yay! --Mark Link to comment
Michel Kohanim Posted October 19, 2011 Share Posted October 19, 2011 Hi Mark, Thanks so very much for the update and I am so very glad things are working. With kind regards, Michel Link to comment
bsobel Posted January 15, 2013 Share Posted January 15, 2013 Success. As I discovered and posted previously, the ISY is prepared to use exactly one SSL cipher suite: SSL_RSA_WITH_RC4_128_MD5. So any server it communicates with must allow this suite. In openssl (and apache) terminology, this is suite RC4-MD5. Most server configurations probably allow this by default, which is why the ISY https "timeout" problem is spotty. But ciphers using MD5 are considered undesirable at this point, and many security-conscious sites have disabled them. I forced RC4-MD5 to be accepted on my server, and the ISY is now happily talking to it. Yay! --Mark Michael, this is EXTREMELY limiting and what I would consider a major bug in the network module. As it stands most sites I want to connect to (and your other users do as well) will not work. Pushover.net simply will not work with MD5. They support: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH 256 bits (eq. 3072 bits RSA) 128 TLS_RSA_WITH_RC4_128_SHA (0x5) 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) 256 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) 168 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) 128 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128 Can you please please please support at least one commonly used cipher suite in the network module. As it stands the module simply can not reliably do SSL to the vast majority of the internet. Link to comment
Michel Kohanim Posted January 15, 2013 Share Posted January 15, 2013 bsobel, http://www.universal-devices.com/docs/I ... 0Guide.pdf With kind regards, Michel Link to comment
bsobel Posted January 15, 2013 Share Posted January 15, 2013 bsobel, http://www.universal-devices.com/docs/I ... 0Guide.pdf With kind regards, Michel "Network Resources allows the ISY to call other systems using HTTP/HTTPS/TCP/UDP/Multicast. Available HTTP/HTTPS commands include GET/POST/CONNECT/DELETE/HEAD/PUT/TRACE. POST and PUT allow the use of URL-ENCODED, RAW TEXT, and BINARY modes. Please see this page for some examples of devics you can control using this module: Network Resources (Examples & Downloads) You'll also find downloadable export files - save time and trouble by importing pre-configured Network Resources right into your ISY!" This is not true, a great number of HTTPS sites are not available. The documentation to linked to is for the 994 not the 99 (but I assume the 994 non pro applies) but this seems to be what you support on the unit acting as an SSL server. The network module (optional component which claims access to https resources) is what is being discussed. I'm unclear if the doc above is supposed to cover the network module as well. What is frustrating is the number of threads from folks trying to use HTTPS resources only to have to discover the network module does not match the description above. Bill Link to comment
Michel Kohanim Posted January 15, 2013 Share Posted January 15, 2013 Bill, What is untrue specifically? With kind regards, Michel Link to comment
bsobel Posted January 16, 2013 Share Posted January 16, 2013 Bill, What is untrue specifically? With kind regards, Michel As written there is no caveat that the number of HTTPS sites is greatly limited to those supporting a very old and often not used cipher. I think that needs to be called out on the Network module for 99i users. When I use a browser and it says it supports HTTPS, I expect to be able to connect to if not all then a great majority of HTTPS sites. That is not true in this case. You did relay to me that this is not ideal but there is a physical capability issue (not enough memory to support the additional ciphers). I accept that fully, but do think you should make this clearer for all. This thread, the Pushover.net thread and at least one other shows that at least 3 of your users (make me 4) were not aware of the limitation. That should tell you that field understanding of the limitation is not widespread. A post in the network section that (for example) tells people they can use https://www.ssllabs.com/ssltest/ to see if the site they can't connect to uses the supported cipher would be good and a direct 'you'll have to upgrade' to the 994 pro for the the other ciphers would at least prevent folks from spinning on the issue. For me, got my 3 upgrade units and the first is going in later today once I cross the border. Cheers, Bill Link to comment
Michel Kohanim Posted January 16, 2013 Share Posted January 16, 2013 Hi Bill, Thank you and agreed! With kind regards, Michel Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.