Very nice work steve! I am handicapped at the moment since I loaned my only Ethernet hub to a friend and don't have it available to assist with wiresharking right now.
Quote from: stevea on May 15, 2012, 03:09:21 PM
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.
It would also be nice to know the behavior of the Obi device, particularly at power up, with regard to under what circumstances the devices actually make connections to the ObiHai servers. You mentioned the DNS requests but was a connection to the ObiHai server also performed with provisioning enabled and the service disabled? I would suspect they would have to do that in order to determine the ip of the Obi so that provisioning could later be done if necessary and was enabled. If not then it would seem that auto provisioning could only really take place if the ObiTALK service is enabled which of coarse would require a connection and thus could be used to determine the ip of the Obi device.
Of coarse a complete functional test of the connection attempts would have to be done with all four combinations of the two control bits (provisioning and service) and noting the server, port and protocol the connections take place on.
Quote from: stevea on May 15, 2012, 03:09:21 PM
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.
Not sure about that last pert of having to wait until a **5nnnn took place since that was not required when the push was performed last week. We really do not know what is required to initiate firmware push. The fact that a **5nnnn would cause one, even with the "control" bits have disabled tell us the process is completely at the desecration of the OBiHai servers though. Thus if the OBIHai server can determine your device's ip address then they have the ability to, as minimum, perform a firmware change so for all purposes they have complete control of your device.
Unfortunately to test the key exchange I think would require writing code to emulate the function of the provisioning server (including keys to further test the key exchange) and using iptables in the router to redirect traffic intended for the provisioning server to the emulator; which is a much harder task than testing normal communications.
Quote from: stevea on May 15, 2012, 03:09:21 PM
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 ?
I agree that using SSL is a good practice and like you would be willing to assume that they also are handling the key exchange properly. (I admit I am too lazy to develop something to test that ) Hopefully the firmware download and remote settings are handled properly. We know that OBiHai has the ability to push firmware updates at their will based on the fact they did last week. Testing has revealed that the control bits in the OBi device do not control the functions in the device but rather simply pass the preferences to the OBi server which OBiHai can honor or not.
That leaves the possibility of flash updates being performed at inopportune times a major reason one may wish to disable auto provisioning.
Unfortunately as we have been told, in this thread, that currently also means one must disable the ObiTALK service. Without the ObiTALK service I think the ObiApp becomes useless as well.
If one has to give up the functions of the Obi, then they may as well take the next step and block all connections to Obi in their border routers; once we have discovered all domain names/ ip addresses they use.
For the customer to be assured they can keep from having firmware updates pushed to them basically all remote features of the Obi devices must be sacrificed. I find this sad since as I suggested earlier it does not have to be that way.