OBI Local Device Management over HTTPS

[dbdoshi]

I can access my OBI device configuration using private IP (say, 192.168.1.6) internally fine (mainly to see call logs). I do use the OBITalk portal to configure it though, but it could be handy in an emergency.

I can access my OBI internal webpage from WAN side by doing a port forward (some external port to port 80) on my router. But, I would like to use HTTPS for this. I really don't want to send my credentials and other info over HTTP. Is there any way to activate HTTPS access to my OBI? The port does not matter as I will be port forwarding.

Currently, I VPN into my network from WAN and then go over HTTP. But, if straight HTTPS access is possible, I don't have to depend on the VPN.

[drgeoff]

https is not available on OBi devices.

[dbdoshi]

https is not available on OBi devices.

Ok, thank you for the info. This then begs another question. Currently, OBiTalk is over HTTPS, so that's all good. But, I am wondering how OBI secures the communication between their servers and a local OBI device when configuration changes need to be pushed to the local device. I would like to know what kind of architecture they have implemented (I don't really care about the authentication part). I have skimmed through the device admin guide and I couldn't find anything related to my Q, I missed it probably. Disclosing a pretty detailed implementation on how OBI is securing this communication would not be revealing proprietary business secrets, I hope so!

Can someone shed some light on this? Thanks.

EDIT: Not looking for the nitty-gritty of actual implementaion, just a little explanation of the overall architecture in place.

[restamp]

I am also interested in the OBiTalk protocol, although I believe it is proprietary and unpublished.  (And, unfortunately, the term "OBiTalk" is unclear in that it refers to both the obitalk.com configuration interface with the device as well as the protocol for making device-to-device voice calls.)  In any event, although the common channel signaling (call set-up protocol) is likely encrypted, and the configuration interface almost definitely so, it is not clear to me that the voice channel itself is encrypted.  Encryption of voice UDP packets comes at the expense of additional latency, so it is definitely not something that is to be had for free.

But, to revisit your original question for a moment:  If you have a server on your local LAN that you can access via ssh from the outside world, you can use ssh to set up a secure remote virtual port to your OBi.  From a Linux box, you would type something like:

Code Select Expand

ssh -p xxx -L 8080:192.168.1.200:80 userid@your_home_IP_address
where the 'xxx' and the last argument are replaced by whatever is appropriate for the hole you've punched in your firewall for this purpose.  The "8080:192.168.1.200:80" (where 192.168.1.200 is the IP address assigned to your OBi on your local LAN) equates to telling the ssh client "once you've established a connection to the far end, create a local port 8080 which is forwarded (via the encrypted channel) to IP 192.168.1.200 port 80 on the other side of the connection".  You can then simply launch a browser on the device you are using and point it to "localhost:8080" to access your OBi device remotely.  I believe this works with Putty under Windows as well, although it's been quite a while since I've played with either Putty or Windows.

Hope this helps.

[dbdoshi]

Thanks for the heads-up on SSH, I had forgotten about the tunneling part of it. I have SSH enabled on my router, and I use Putty for running shell commands on my router. But yes, that is definitely another option W/O native HTTPS support.

[Lavarock7]

Although not a cure, you could set the port for Obi admin to some odd (non port 80) port number and access it that way. It doesn't stop prying eyes of packets, but it would be difficult for someone to guess your admin port at least.