[wmt]

Maybe you should read the story again. The core focus of the criticism is directed at punching holes through firewalls by default, and in this case you cannot even disable it.

"This is a concern because the P2P function built into Foscam P2P cameras is designed to punch through firewalls and can’t be switched off without applying a firmware update plus an additional patch that the company only released after repeated pleas from users on its support forum."

Later he quotes Nicholas Weaver from ICSI:

"Given the seemingly cavalier attitude and the almost certain lack of automatic updates, it is almost certain that these devices are remotely exploitable."

[dimman]

I do fully understand how the technology works. Let me explain:

"punching holes through firewalls" <-- This _simply_ means that the device does a connect() call towards the clients IP:port while the client does a connect() towards the device:port at roughly the same time. You simply use the fact that a simple home router opens up a temporary rule allowing the destination:port to respond to your outgoing request. This won't work on symmetric NAT's for instance.

It's basically a completely safe method and does not open up for anyone else to connect ...

(The enabled by default is as I wrote in my original post is another question. The way I read the article it seems like the core focus of the post is to say that the solution used is bad or unsafe, which with given information cannot be said).

[wmt]

There you go again, misunderstanding what was actually said. I never questioned your understanding of the technology, but your understanding of what Krebs says.

Krebs also understands the technology, and quotes David Qu from Foscam about how their P2P technically works.

[dimman]

Yeah I noticed that it sounded like I misunderstood you, however I did not. Lets just get it straight:

I agree with you and him that it would be a lot nicer to let the user choose to enable this, and definitly not make it impossible to disable.

With that said, I'm still not sure that the author actually understand the technology behind or how it works.

Reading David Qu's answers they just align with what I'm saying about the technical part though. No matter what the author says, I think it's easy to misunderstand the text and make it sound like the manufacturer are doing something unsafe...

[KMag]

> It's basically a completely safe method and does not open up for anyone else to connect ...

Yes, "only allows connections to a small number of peers". However, depending on how the IDs in the P2P overlay connection are chosen, an attacker may be able to select an ID that causes their node to be one of the nodes that your device contacts. Also, in the case where a remote login or remote execution vulnerability exists, the entire P2P network can be rapidly compromised, even though each node only punches holes in firewalls to a small number of other nodes.

[dimman]

I don't know where your getting the first part from? As I said earlier I don't know how they've chosen to protect themselves, I do hope they use certificates to authenticate camera/client to verify that the client has access to the camera and that the camera verifies that the client has access.

I don't think you understand how the technology works. Each camera does _not_ "punch holes to a small number of other nodes", it setups a direct connection between itself and the client device (you) using a technique called hole punching... It's just a simple connection between you and the camera, no server in between.

[KMag]

Ahh, my background in decentralized P2P systems engineering, along with the phrase "Foscam admits that disabling the P2P option doesn’t actually do anything to stop the device from seeking out other P2P hosts online (see screenshot below)." lead me to believe they were using a DHT or other decentralized P2P system. I'd need more details to determine if they use a set of centralized coordination hosts or if they use a DHT or other decentralized system for the hosts coordinating the hole punching.

[dimman]

I think (I still don't know the details of their implementation) the confusion is caused by them using the term P2P servers. I think thats actually STUN/TURN servers that they use as help to get P2P (direct) connections between camera and your application. So in that sense it's not a P2P server as you imagine it but just a bad name for what the server is meant to help out with :) Again, I don't know but given that I've worked with these type of technologies for years it would make sense.

[tremon]

It's basically a completely safe method and does not open up for anyone else to connect ...

Except that it's opening a port into an unverified P2P network. How can you say for certain that none of the peers are compromised or nefarious?

[dimman]

What I described is a safe method (except ofc if you have someone in your network that can spoof adresses or your other endpoint has been compromised, however those are factors that we can't do much about).

I'm not saying that their solution is safe, nor am I saying that its unsafe, simply because I don't know. What I do know is that you can make it rather safe and you can do it really bad.

If they are using a TURN solution which I think they are, then it's not really a "unverified P2P network" either because the peers do not know of eachother nor do they talk to eachother. They talk to the server and have no clue about one another without some external signaling. The server connects two peers upon request of a specific uid, however this where authentication gets important and I have no clue how they've done it.

Of course you can try to create connections towards random ID's (you have a lot of ID's to go through judging by the screenshot) but hopefully you won't be allowed to connect since you don't have the correct certificate/key needed. Again I don't know how they've implemented it though.