Jump to content

How To: Enable Internet Access


Michel Kohanim

Recommended Posts

Interesting thing though, I noticed in mobilinc that since switching to HTTPS it takes 2 3 seconds longer to connect then using http port, is this normal ?behavior?

Yes. HTTPS is SSL, and it takes serious computation to establish a connection.
Link to comment
  • 1 month later...

When I try to use the IP address listed under: Internet access, I get this message:

Your connection is not private. Attackers might be trying to steal your information. NET::Err_Cert_authority_invalid

 

This concerning - what do I have set up wrong?

 

I went to load a certificate, but dialog box opens asking where to load it from???

 

Port 443 is forwarded in router and Mobilinc works OK

 

Thanks,

John

Link to comment

When I try to use the IP address listed under: Internet access, I get this message:

Your connection is not private. Attackers might be trying to steal your information. NET::Err_Cert_authority_invalid

 

This concerning - what do I have set up wrong?

 

I went to load a certificate, but dialog box opens asking where to load it from???

 

Port 443 is forwarded in router and Mobilinc works OK

 

Thanks,

John

This is expected from your browser. Most browsers these days have those big splash pages indicating that the certificate isn't quite right for some reason. With some browsers you can "add a permanent exception" like in Firefox. In some other browsers like chrome you will have to add that certificate into the trusted certs section which is annoying itself.

 

And of course that cert will only help you when you're using that same IP address. For example, always using it from inside your network. If you go to use your public IP address with port forwarding then you will get that same message and will need to add another permanent exception. And that will only hold as long as your public IP address doesn't change.

 

Sent from my Moto X using tapatalk

Link to comment

I don't bother with all that nonsense. In Chrome I just hit advanced and click ignore the warning each time.

 

I know I am no going to hack into my own equipment and if I did, I wouldn't cause any damage anyway.

Problem with this is a malicious person could proxy your connection with their own self-signed certificate and still intercept your connection without you being any the wiser...

 

You should add the self signed cert as a trusted root cert on your client - that should prevent the warning on that machine, and protect you from man in the middle issues.

Link to comment

Problem with this is a malicious person could proxy your connection with their own self-signed certificate and still intercept your connection without you being any the wiser...

 

You should add the self signed cert as a trusted root cert on your client - that should prevent the warning on that machine, and protect you from man in the middle issues.

People keep tooting this stuff with security but I see many holes in it, at this point.

 

This person has to sit in wait of me to  randomly sign into my ISY, intercept and decode  packets between my remote device and ISY, using their own certificate? How would they get a certificate into my ISY to transmit? If they can do it at the receiving end how would me having a certificate at my receiving end make it secure?

 

I can't say I understand all this stuff well but it always sounds like something imagined. It has to be more complex than what I just scenarioed (word?)

Link to comment

In the simplest case, if there's an accessible outdoor outlet, then it's easy to probe your entire Insteon network. It's only a bit more difficult if you have dual-band devices. But there's always the gain over cost. So why would someone probe your home? Or why wouldn't they?

Link to comment

Problem with this is a malicious person could proxy your connection with their own self-signed certificate and still intercept your connection without you being any the wiser...

 

You should add the self signed cert as a trusted root cert on your client - that should prevent the warning on that machine, and protect you from man in the middle issues.

How do I add the self signed cert?

Link to comment

I have been through this before and spent a few nights on it. I need actual  instructions not descriptions of some elements involved and acronyms. Most of this document is non-instructional for implementation on ISY and means nothing to me. Even the first link has an error  built in

 

I guess this is why I have never bothered with this nonsense to access my ISY.

Link to comment

People keep tooting this stuff with security but I see many holes in it, at this point.

 

This person has to sit in wait of me to randomly sign into my ISY, intercept and decode packets between my remote device and ISY, using their own certificate? How would they get a certificate into my ISY to transmit? If they can do it at the receiving end how would me having a certificate at my receiving end make it secure?

 

I can't say I understand all this stuff well but it always sounds like something imagined. It has to be more complex than what I just scenarioed (word?)

Larry,

 

I do pen testing professionally. Our mobile apps all do cert pinning as a requirement. Our VPN clients look for certificates issued by a CA that we control key issuance from. I have now come across two ISPs that I have caught doing SSL interception due to our strict checking of certificates by our clients - one of them a major national ISP! This threat is, unfortunately, very real.

 

Here is how this attack works... Bad guy does not need your cert. It's self signed. Turns out any self signed cert is fine - and the attacker can just generate their own. How would you know the difference? Do you know your ISY certs hash value to compare on the warning page?

 

Normally, browser makes TCP connection to ISY. ISY sends its cert (public key) which is not able to be verified by the client because it's not trusted. You click past, client generates secret and encrypts it with the public key then sends it to the ISY. Communication continues using the secret for encryption. Secure - as long as nobody intercepted your initial TCP connection.

 

Client => ISY

 

Hack is bad guy intercepts your TCP connection (before the encryption is established) and proxies it to the final destination (ISY). ISY sends its public key to the intermediary, which generates its own private key with public exponent. The intermediary sends its newly generated cert (public key) to your client. Client still cannot verify the cert, but will generate a secret anyway (because you clicked to OK the transaction) and send it to the intermediary. The Intermediary also generates its own secret, and sends it to ISY. Now, you have two 'encrypted' sessions, one between client and intermediary and another between intermediary and ISY - with the intermediary having clear text access to your 'encrypted' session.

 

Client => Hacker => ISY

 

I know this works, because I've done it (in my lab!). This attack works on many public WiFi networks, from other connected clients. There are tools to spoof the MAC address of the default gateway to individual remote clients (on the same subnet). This causes the target client to send all internet bound traffic to you - all you have to do is forward it on to the correct MAC address.

 

The only mitigator is to use a certificate on your ISY that is trusted by your client. That way if an intermediary performs this attack you will see an untrusted cert warning.

 

If you run a 'public' or open WiFi network - turning on strict isolation also mitigates the attack - but it breaks peer-to-peer WiFi device communication (which affects things like upnp, file shares, Chromecast, Apple TVs etc...). The local attack depends on two WiFi clients being able to directly communicate with each other. Of course - ISPs can easily intercept this stuff and insert their own.... As I mentioned already - I have caught a couple already.

 

Michael.

Link to comment

I do pen testing professionally. Our mobile apps all do cert pinning as a requirement. Our VPN clients look for certificates issued by a CA that we control key issuance from. I have now come across two ISPs that I have caught doing SSL interception due to our strict checking of certificates by our clients - one of them a major national ISP! This threat is, unfortunately, very real.

 

 

Thanks for the insight and I can understand that it's easily done for those who have the skills but for the average citizen regarding ISY anyway I think the question is why?  As larry said.. turn off and on his TV?  Seems to me anyone who has the skills to hack into my network can earn a more substantial income than running away with anything I have in my home.

 

 

Jon...

Link to comment

How about turning off your alarm (if Elk integrated), open your garage door (if so integrated) and unlock your door (if so integrated) - all things many of us can do via our ISY.

 

I have my ISY tell me via Pushover whenever events like these occur - just in case. Maybe my security background just has me paranoid though... :)

Link to comment

@MWareman,

 

Thanks for all of the knowledge that you impart to this community.  I have learned quite a bit from your posts and really appreciate that education.

 

-Xathros

Link to comment
  • 5 months later...
Sorry for reviving this thread, but I have reached a dead end here.

 

I forwarded port 50,000 over both TCP and UDP.

I changed the port settings under "https" in the admin console.

Updated my isy99i firmware to the latest version 3.3.10

 

When I try to connect to my isy using mobilinc or iRule, I can't establish a connection.

Interestingly, when I open a chrome browser and enter:   Https://external.ip.here:50000

 

The below error appears. 

ERR_SSL_OR_CIPHER_MISMATCH

 

post-8128-0-41513100-1469497170_thumb.png

 

 

When I enter a different port that is not forwarded, I get a more traditional error "site can't be reached"

When I enter "Https://external.ip.here:50000"into safari, I get similar error saying that it can't establish a secure connection.

 

I'm at a loss here. 
Any help is greatly appreciated.

Link to comment

What is the client device? Could it be that it's new enough that it does not support SSL3 (most Android devices, all IOS devices, and Windows versions post Vista), but your ISY99i is old enough to only support SSL3?

 

It might be time to upgrade to a 994i.

Link to comment

Thanks for the responses.

Entering "http" in lieu of "https" doesn't work either.

 

In terms of my client, I am using iOS for the iRule and Mobilinc apps; and my computer is a mac.

 

It sounds like all my clients do not support SSL3, and it looks like the latest firmware release for SSL4 does not work on the isy99.

I am really disappointed that universal devices will not support legacy isy99i devices with the latest SSL. 

 

I shouldn't have to shell out $200 for a 994i.

 

Does universal devices offer some kind of rebate when upgrading from a 99i?

Link to comment

The upgrade is less than $100.... Look on the sales page for the upgrade offer. There are also refrubs available there.

 

When they announced this they told everyone that it wasn't a choice to not support the 99i, the firmware simply dosnt fit in the limited space available. This is reiterated on firmware updates, even today years later.

Link to comment

Archived

This topic is now archived and is closed to further replies.


  • Recently Browsing

    • No registered users viewing this page.
  • Who's Online (See full list)

    • There are no registered users currently online
  • Forum Statistics

    • Total Topics
      36.9k
    • Total Posts
      370.2k
×
×
  • Create New...