Obihai is deleting unwanted topics
Ostracus:
From the OBi Device Provisioning Guide:
Quote
Auto Recovery Mode
The OBi device may enter into an auto recovery mode to address and remedy a failure of a firmware upgrade, such as power lost in the middle of the upgrading procedure etc. In this mode, the OBi device tries to get firmware from the last URL where the firmware was successfully downloaded until the firmware is downloaded or the device is powered off. If the firmware is downloaded, the OBi will install the firmware automatically and restart itself, and progressively return to normal mode. While the device keeps retrying, the firmware can be installed from device management pages as well.
VaHam:
Quote from: Ostracus on May 15, 2012, 09:40:41 am
From the OBi Device Provisioning Guide:
Quote
Auto Recovery Mode
The OBi device may enter into an auto recovery mode to address and remedy a failure of a firmware upgrade, such as power lost in the middle of the upgrading procedure etc. In this mode, the OBi device tries to get firmware from the last URL where the firmware was successfully downloaded until the firmware is downloaded or the device is powered off. If the firmware is downloaded, the OBi will install the firmware automatically and restart itself, and progressively return to normal mode. While the device keeps retrying, the firmware can be installed from device management pages as well.
I added the bold since it is this portion I would be worried about knowing how other devices behave under re-flash conditions. I don't really think this is a guarantee but I'd be happy to be corrected on that issue by OBIHai. :)
ProfTech:
If you look through the postings you will see at least 1 person that reported that he was running with ObiTalk -> Enabled -> UNchecked and auto firmware update disabled and they did not receive the update. So I think that particular question has been answered.
Modified: I re-read your post. I for one had Auto provisioning disabled but ObiTalk Enabled [checked] and yes I did receive the update but haven't been overly concerned about it. I have since unchecked ObiTalk since I don't really use it anyway. I need something more flexible and "Commercial".
RonR:
Quote from: VaHam on May 15, 2012, 09:17:35 am
I would be interested to hear if any folks who had the ObiTALK auto provisioning disabled but the ObiTALK service enabled received a push last week or not.
The first thing I set when I take a new OBi out of the box is:
System Management -> Auto Provisioning -> Auto Firmware Update -> Method : Disabled
System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
I also change the Admin password from 'admin' to a private password known only to me.
The OBiTALK Service was always enabled as it had not been disclosed that by leaving it enbled, the above settings are negated.
With these settings, I have had the firmware in OBi's updated on numerous occasions (sometimes at inopertune times).
As I've previously stated, access to the OBi's contents is also open with the above settings as evidenced by the following response I received to a question I asked via email:
"We just checked your OBi's configuration 200 123 456
SP2's X_InboundCallRoute has {('asterisk'):}, ..."
stevea:
I don't dismiss security concerns at all, however they need to be considered in terms of realistic exploits..
I've tracked network traffic from power-up through the the **5nnnn via wireshark.
The Obi110 requests addresses for 'prov.obitalk.com' and 'root.pnn.obitalk.com' (I have provisioning enabled). This DNS resolution appears to happen only at Obihai powerup. Also ntp servers and google server names are resolved by DNS. So yes we should be concerned about DNS security. Primarily wrt ISP name resolution.
The '**5nnnn' call causes the Obihai110 to make a tcp connection to 'root.pnn.obitalk.com' port 6800. Some minor tcp traffic takes place however the identification number for the ObiHai110 is sent unencrypted. Then it *appears* that an SSL.v3-like connection is setup on the TCP connection after exchanging some Obihai self-signed certs. The openSSL certs sent to the Obihai are not verified via any public service like Verisign, however that doesn't mean they aren't verified against an in-firmware cache. *Assuming* that the key exchange is secure and note the crypto selected (AES-256) is good - then the content of the traffic after SSL setup is quite safe. IOW the cert exchange and SSL means that Obihai device can be quite certain it is communicating to the Obihai server and not to a fake server, and the encrypted traffic is 'safe enough'. The security issue is similar to the concept of pointing your web browser to your bank and accepting the https certificate as assurance you have the correct site.
SO *ASSUMING* the key exchange is secure, and the certs are verified from firmware .... an exploit requires an evildoer to steal the private crypto key from Obihai, install a DNS or IP routing exploit to send traffic to his evil-server with a matching cert, and then he must arrange for the '**5nnnn' sequence to be entered on the phone, then he must download evil-firmware to the Obihia or at least change the settings.
I am greatly reassured knowing that there some sort of secure connection on this channel. I'd like to hear more about the cert verification issue - but so far I have no reason to doubt or distrust ObiHai's design decisions.
I wonder of the firmware download and ObiTalk remote settings use a similar secure channel ?
Navigation
[0] Message Index
[#] Next page
[*] Previous page