Admin Console over HTTPS Unusable (Super Slow)

[mykroft77]

I have setup an SSL certificate within my ISY to try and secure access to the admin console and API and what I am seeing is that accessing the admin console is painfully slow.   It took several minutes to install the JNLP, downloading it over the local LAN.   I'm at 5+ minutes waiting for the UI to finish loading so I can even use it and it appears to be hung but I suspect it's just taking a really long time for each request to the ISY as every now and then it shows some progressing in loading.  In the bottom left corner in the status bar is says "System Busy".   Surely this isn't working right...

 

What would be causing it to be so slow over HTTPS?   Connecting over HTTP works fine and loads instantly.

[larryllix]

What speed and number of cores is your computer you are running the java based admin console on?

 

Mine takes about 5-6 minutes to load on a single core 2.2 GHz CPU. The java rendering icons grinds it to a standstill almost.

 

Try the nonsecure http port access for ISY. You are on a LAN behind your router firewall anyway.

[Michel Kohanim]

mykroft77,

 

If you are trying to download the whole Admin Console every time, of course it's going to take a long time especially if you are using 2048 bit cert. The total download for that is about 15MB. What you need to do instead is:

1. https://wiki.universal-devices.com/index.php?title=Main_Page#Installing_the_Admin_Console_Icon_on_Your_Desktop ... install the Admin Console on your desktop

2. In ISY Finder, click on the Add button and enter the https address of ISY

 

This way, all communications to/from ISY are https.

 

With kind regards,

Michel

[mykroft77]

What speed and number of cores is your computer you are running the java based admin console on?

 

Mine takes about 5-6 minutes to load on a single core 2.2 GHz CPU. The java rendering icons grinds it to a standstill almost.

 

Try the nonsecure http port access for ISY. You are on a LAN behind your router firewall anyway.

 

My computer is not the issue, it's a 4.2Ghz Quad Core processor, I have a very capable machine as I am a software developer and use it extensively for development purposes.   And if it's taking you 5-6 minutes to load in even your CPU, which is still decent, then it's not a very efficient process.  We're not loading up Photoshop or some video editing platform that uses gigabytes of resources here (and even THAT loads faster on my machine)... just a simple UI interface to a hardware device.

 

I can certainly use the HTTP port, but I am trying to setup a single point of access for my ISY for both inside and outside my home network and this will be exposed to the internet so I want to use SSL all the time, if I can.

 

 

 

If you are trying to download the whole Admin Console every time, of course it's going to take a long time especially if you are using 2048 bit cert. The total download for that is about 15MB. What you need to do instead is:

 

 

Well no I'm not trying to download the Admin console every time, I just cleared out my Java apps/cache so that I would get a fresh copy against the new HTTPS URL since I had just setup my SSL cert in ISY Dashboard.   The difference was staggering in the time it took to download, and then it took close to 20 minutes to get the UI to FULLY load and be usable.   That pretty much makes it useless for me.   And yes, as I replied above I can certainly use HTTP on my LAN since it's local anyway, but if it's going to take THIS long over my gigabit local LAN, it won't get any better over the internet from outside.

 

I've worked with SSL certs before, it should never take a "long time"  (in my case, it was minutes) to download a mere 15MB even with a 2048 bit SSL cert. 

 

What I am learning is that the hardware on the ISY has no accelerated encryption engine so it's doing it all on the main CPU, which is probably underpowered for performing this task.   To me this suggests that having HTTPS\SSL as a feature on this product is not even a viable use case.

 

One thing I did find out, was that Java wasn't completely trusting my SSL certificate for some reason.  I have a Comodo multi-domain cert I setup with the ISY and I guess it didn't quite like the intermediate CA's in the chain, so I was able to install those intermediate certs in the Java settings as trusted and that made a big difference in the load times.   It's still SLOW, but more usable... but not like it should be.

 

Thank you all for your replies so far... has anyone gotten this to work efficiently or does everyone just give up and use HTTP?   (Or bite the bullet and walk away from the console while it "loads"?)

[larryllix]

It's not so much the download speed, which is somewhat slow also, but only a single background task for ISY while it still performs REST and event triggered tasks, and shared the Ethernet port, maybe not too bad.

 

IMHO it is the slow  java package on your computer drawing every box, icon, and avatar first. This is apparent on the later firmware versions as the admin console boot now displays what it is grinding on. My faster machine doesn't take 1/4 of the time but it is still  a painful wait.

 

I don't use the admin console remotely as I cannot see any proofs of my efforts and admin console java just goes away frequently as java decides you don't need it for some reason. The quest is on to get UDI to switch over the HTML5 but they have been busy with Zwave which surprised their work load with so many varying (maybe obsolete) devices.

 

You should see my Palm Pilot load it!

[asbril]

It's not so much the download speed, which is somewhat slow also, but only a single background task for ISY while it still performs REST and event triggered tasks, and shared the Ethernet port, maybe not too bad.

 

IMHO it is the slow  java package on your computer drawing every box, icon, and avatar first. This is apparent on the later firmware versions as the admin console boot now displays what it is grinding on. My faster machine doesn't take 1/4 of the time but it is still  a painful wait.

 

I don't use the admin console remotely as I cannot see any proofs of my efforts and admin console java just goes away frequently as java decides you don't need it for some reason. The quest is on to get UDI to switch over the HTML5 but they have been busy with Zwave which surprised their work load with so many varying (maybe obsolete) devices.

 

You should see my Palm Pilot load it!

And your Commodore 64 ?

[Goose66]

It's not so much the download speed, which is somewhat slow also, but only a single background task for ISY while it still performs REST and event triggered tasks, and shared the Ethernet port, maybe not too bad.

 

IMHO it is the slow  java package on your computer drawing every box, icon, and avatar first. This is apparent on the later firmware versions as the admin console boot now displays what it is grinding on. My faster machine doesn't take 1/4 of the time but it is still  a painful wait.

 

I don't use the admin console remotely as I cannot see any proofs of my efforts and admin console java just goes away frequently as java decides you don't need it for some reason. The quest is on to get UDI to switch over the HTML5 but they have been busy with Zwave which surprised their work load with so many varying (maybe obsolete) devices.

 

You should see my Palm Pilot load it!

 

That doesn't really explain why it would be so much slower over https, though. My machine is not that fast (core i5-2500K @ 3.60 GHz) and it has no problem running the Admin Console in Java.

[MWareman]

When establishing an SSL connection, it’s the server (ISY) that has the computationally intensive task of calculating the session setup crypto.

 

In commercial sites, many system use hardware assisted process for speed (at work, I use F5s...).

 

The ISY, on the other hand, has a CPU less powerful than an Arduino (ish - it does not take much to keep up with Insteon and Zwave serial communication speed) - and no crypto processor. That calculation is going to take quite a while.

 

Re-do your certificate at 1024 bits and you will see a 4 time improvement in speed (assuming your current cert is 2048bits).

[Goose66]

If security of remote access is the issue, might I suggest a VPN into your LAN, and then simple http access to the ISY from the Admin Console. Alternatively, use RDP or Go2MyPC or equivalent to access a PC on your LAN and run the Admin Console there.

[larryllix]

That doesn't really explain why it would be so much slower over https, though. My machine is not that fast (core i5-2500K @ 3.60 GHz) and it has no problem running the Admin Console in Java.

See post #3 & #8

 

Mine has no problem running the admin console either. It is the creation of all the symbols, avatars and icon in java.

[jgreco]

On 2/6/2018 at 11:47 AM, mykroft77 said:

I can certainly use the HTTP port, but I am trying to setup a single point of access for my ISY for both inside and outside my home network and this will be exposed to the internet so I want to use SSL all the time, if I can.

I've worked with SSL certs before, it should never take a "long time"  (in my case, it was minutes) to download a mere 15MB even with a 2048 bit SSL cert. 

What I am learning is that the hardware on the ISY has no accelerated encryption engine so it's doing it all on the main CPU, which is probably underpowered for performing this task.   To me this suggests that having HTTPS\SSL as a feature on this product is not even a viable use case.

Thank you all for your replies so far... has anyone gotten this to work efficiently or does everyone just give up and use HTTP?   (Or bite the bullet and walk away from the console while it "loads"?)

My recollection is that the ISY994i was released around 2013.

SSL has undergone some radical changes in the last five years, with the deprecation of older crypto, driven by the harsh realities of bugs and flaws in older crypto, and the realization by browser developers that they could either be complicit in allowing poor security, or take a leadership role.  For the most part, they've stepped up and have been killing off insecure protocols, rogue certificate authorities, and solving other issues.  Whether or not we'd prefer for this to be the case, those of us working in the industry are dealing with the prospect of 4096 bit certificates in the near future, or in some cases, actively deploying them now.

Many small embedded controllers that are fine for non-SSL duties, or were merely slow with 1024-or-less-bit certificates become virtually unusable with the substantially higher crypto load demanded by 2048 bit certificates, and, yes, I can tell you that the ISY is pretty darn slow.   Measuring only the speed of connections, I get a minimum 4.6 seconds to connect with a 2048 bit certificate, and an average of 5.9 seconds.  This has nothing to do with the speed of the client, and is strictly a test of the ISY platform's crypto capabilities.

We do network infrastructure engineering here and have seen this across all sorts of embedded processors, including network switches, UPS gear, and all sorts of other gear with marginal CPU's that were believed to be fine for the task when they were designed.

By way of comparison, placing an HAProxy based load balancer in front to decode 4096 bit HTTPS and proxy it to the ISY as pure HTTP results in 0.05 second connect times, using a simple 256MB single CPU VM on a hypervisor.  This also speeds up the interactions with the ISY, although not by as much as I'd prefer.

It is completely possible to solve the problem this way for the long term.  This method provides a fast SSL layer that is virtually indistinguishable from HTTP performance.  However, it does require having some other device present to act as a proxy.  I've used a virtual machine here as it is conveniently and cheaply available, but one could do the same trick with a Raspberry Pi (newer == better).  It is an unhappy answer in that there's a second thing to worry about and manage, but it answers the question of whether or not there's a way to do HTTPS quickly.

[giesen]

My recollection is that the ISY994i was released around 2013.
SSL has undergone some radical changes in the last five years, with the deprecation of older crypto, driven by the harsh realities of bugs and flaws in older crypto, and the realization by browser developers that they could either be complicit in allowing poor security, or take a leadership role.  For the most part, they've stepped up and have been killing off insecure protocols, rogue certificate authorities, and solving other issues.  Whether or not we'd prefer for this to be the case, those of us working in the industry are dealing with the prospect of 4096 bit certificates in the near future, or in some cases, actively deploying them now.
Many small embedded controllers that are fine for non-SSL duties, or were merely slow with 1024-or-less-bit certificates become virtually unusable with the substantially higher crypto load demanded by 2048 bit certificates, and, yes, I can tell you that the ISY is pretty darn slow.   Measuring only the speed of connections, I get a minimum 4.6 seconds to connect with a 2048 bit certificate, and an average of 5.9 seconds.  This has nothing to do with the speed of the client, and is strictly a test of the ISY platform's crypto capabilities.
We do network infrastructure engineering here and have seen this across all sorts of embedded processors, including network switches, UPS gear, and all sorts of other gear with marginal CPU's that were believed to be fine for the task when they were designed.
By way of comparison, placing an HAProxy based load balancer in front to decode 4096 bit HTTPS and proxy it to the ISY as pure HTTP results in 0.05 second connect times, using a simple 256MB single CPU VM on a hypervisor.  This also speeds up the interactions with the ISY, although not by as much as I'd prefer.
It is completely possible to solve the problem this way for the long term.  This method provides a fast SSL layer that is virtually indistinguishable from HTTP performance.  However, it does require having some other device present to act as a proxy.  I've used a virtual machine here as it is conveniently and cheaply available, but one could do the same trick with a Raspberry Pi (newer == better).  It is an unhappy answer in that there's a second thing to worry about and manage, but it answers the question of whether or not there's a way to do HTTPS quickly.

The problem with an HTTPS proxy is that it breaks the subscription portion of the API

Sent from my SM-N9500 using Tapatalk

[MWareman]

I posted somewhere how to setup Apache to reverse proxy ISY retaining support for the websocket subscription used by Agave.

Unfortunately, I’ve not found a way to reverse proxy the SOAP subscription needed by Mobilinc or the Admin portal.

[skunkiechris]

Just wondering if anyone ever figured out a way to reverse proxy the SOAP subscription.  I set up an Apache reverse SSL proxy to offload TLS as it's basically unusable remotely before realizing this limitation.  The proxy works fantastic and speeds it up to non-SSL speeds, but obviously fails at "Starting subscription..."

[MWareman]

I haven’t. Mobile, I use Agave which uses a websocket subscription - and this can be proxied.

Otherwise, I use ISY Portal - and when remote I connect the Admin Console via that.

Michael.

[skunkiechris]

8 hours ago, MWareman said:

Otherwise, I use ISY Portal - and when remote I connect the Admin Console via that.
 

Ha, I never even realized that was an option.  Definitely more usable than direct https remoting in, for whatever reason. Thanks!!