How does the Reolink UID actually WORK?

[justin_87388068069621]

Hello,
Doing some searching, I have the identical concern this gentlemen does:
https://thedocsworld.net/reolink-security-concern/

Prior to finding this article, I realized it's indeed the UID allowing external access to my system. By disabling the UID, it caused the app to no longer function, which I then manually set up via the IP and TCP port *I* configured in my router's port forwarding .

What I can't seem to find is HOW the UID function actually works? How is my NVR establishing external, two-way communication with my iPhone via the UID? I had not opened/forwarded any ports and it just 'worked.' Is the NVR unknowingly communicating (sending video) via Reolink's cloud? What is the 'system' that the UID is actually UNIQUE on??

Think about it: If we HAVE security cameras in the first place, we ARE a security-conscious bunch. I NEED to know EXACTLY how this works for me to feel comfortable with this system. And SOON.

Thank you,
Justin

[Crimp On_62210811129]

My understanding is "yes, the Reolink devices (cameras, NVR) open IP connections to the Reolink cloud servers." Once a connection is opened "outbound", it is open for return traffic from that IP. Like, when you connect to a web site, that web site can send packets back to you. The unique user name and password are used to look up the connection to a particular UID that is associated with that customer. Port forwarding allows anyone, anywhere to attempt to connect to your cameras. The only thing stopping them is knowing the user name/password for the camera. (Just like they need to know the user name/password for the Reolink app.)

I would email the question to "support@reolink.com", rather than asking Community members. We users have opinions, whereas the support staff are usually pretty knowledgeable.

People who are "totally paranoid" about security do not register their cameras using UID, and probably do not set up port forwarding. They either do not allow access from outside their LAN, or they set up VPN's to tunnel into their network.

[Carl_31331526639]

Hi Justin, about the remote accessing on Reolink products. We provide the UID (based on P2P) for users to make it easy to use. You may just connect the cameras/NVRs to the Internet and log in them via the UID with your username/password. For the P2P, please refer to here. And the UID uses the random UDP ports on the network. If you don't need that, you may just disable it and set the port forwarding by yourself. But we hope to provide users with a convenient way to use the cameras/NVRs, users needn't know how it works or worry about the security issue. We used the private protocol and also has the encryption from the AWS to protect your data safety. Also, our server won't save any private data from users. If you still have any questions, feel free to contact us at https://support.reolink.com/hc/en-us/requests/new. Have a nice day!

[melroy]

Sorry it's an old topic, but still relevant today and unanswered. Also high in the search results.

Reolink should indeed do a better job explaining their "UID" mechanism / P2P system. Which is actually contacting the Amazon cloud. Using a technique called "hole punching" through the firewall, without the users knowing.

This is very dangerous, so you should ideally put your camera within a separate VLAN. Reolink, please just be more transparent about your products.

Another option I found is to basically disable P2P by unchecking "Enable UID" within: Settings-> Network Settings -> Advanced -> Enable UID.

After more searching, I finally found this article from Reolink: https://reolink.com/blog/p2p-ip-camera/

@Reolink If I disabled UID feature, can I still enable port forwarding manually when needed, giving back control to the users? Which port should I then forward manually to keep using your mobile app?

Hint; search on Google: "Peer-to-Peer Functionality in IoT Security Cameras and Its Security Implications"

[Crimp On_62210811129]

@melroy I am not confident that Reolink software engineers monitor the user forums. My guess is that the answer is "can't be done". The mobile app works the way it does, and no other way.

As the article referenced explains, a device opening a port to a remote server creates a link that the remote server can use to communicate with the device.
My impression is that when a customer opens the Reolink smartphone app, the app connects to the cloud and uses the customer login credentials to scan the database for UIDs registered to that user who have open links to the server. If the connection is not already open, then the server has no idea which IP address any particular device may be related to.
Only cameras that have connected to the server with their UID can be opened with the app.

Opening a port on a customer router for remote access (i.e. port forwarding), does not restrict access to any particular IP address on the internet. For example, the Reolink RLC cameras include a web server that provides a way to view the camera video. If a user forwarded an external port on their router to port 80 (or 443) on a camera on the local LAN, then they could access that camera remotely. (provided that they can supply the correct user name/password.) This does not scale well, because every camera would need a separate external port linked to their internal IP address.

[joseph_1979]

@melroy UID is like your ID number which is a unique identifier pointing to a number of profiles in various institutions. If you go to the hospital they will ask you for the ID and by entering this ID they will get all your health information.

When you power up your camera, it does some DNS queries to get the IP addresses (A record) of the P2P servers (provided by Amazon and Azure) and registers with the P2P servers using its UID (we are assuming here that UID is enabled). At regular intervals the camera sends packets to the P2P servers which shall include the UID (encrypted). The application on the P2P server decrypts the packet and extracts the UID. The application extracts the private IP and Public IP (BroadBand IP:Port) of the packet and populates them in the respective record associated with UID. If the camera changes IP then the record pointed out by the UID is updated accordingly. The credentials you created are not forwarded to the P2P servers. Well if you can emulate the P2P protocol and know the encryption method/phrase then you would be able to get the private and public IP of a particular UID. But so far there have been no such breaches and still you need the credentials to get access to the camera. Therefore it is imperative to follow the policies associated with passwords such as create a strong password and change it at regular intervals. At this point we see that there is a P2P socket between the camera and the P2P server. For your perusal the camera sends the alerts to the domain pushx.reolink.com. The application server will then forward the push message request to FCM (Android) or APNS (IoS) which shall push the message to your smartphone. Token provided by FCM to your smartphone on registration is forwarded to Reolink pushx application server. This token is included in the request made by this application server to the FCM to push the alert on your smartphone.

Now let's take a look from the client side. When you run the Reolink client, it will send a DNS query to 16 P2P servers (p2p1, p2p3, etc) and the response is the A record containing the IP address of the P2P server. Any P2P server which is not yet assigned will get the A record with the loop IP (127.0.0.1). For each working P2P server, the client requests the Public IP (the Relay P2P server with which the camera is connected) and Private IPs of the camera using destination port 9999. So if we have 8 working P2P servers and 8 cameras, then the client will send 64 requests over UDP. At the same time the client broadcast a packet with command aaaa0000 on the network with destination port 2000. Note that the Client broadcasts the packet with payload aaaa0000 using destination addresses 255.255.255.255.255 and 192.168.1.255 (or your configured IP subnet). Now 255.255. 255.255 is the limited broadcast address which is only propagated within the single subnet of the interface that sent it. It is never routed to other subnets unlike the subnet directed broadcast address 192.168. 1.255 which may be routed from elsewhere, depending on router configuration. So in most cases only the cameras within the same subnet receives this packet. If there are cameras on the same network they have port 2000 opened and are listening for any broadcast with command aaaa0000. If this is received then the camera will reply to the source IP with the command aaaa0000, UID, IP, port 9000, mac and ID. So once the client receives this on port 3000 then it will start communication with the camera using TCP and port 9000. Note that at this point the communication is directly between the client and the camera which are on the same network. At the same time the client also sends the request using the public IP. This public IP is not the public IP on your BB router but rather the IP of the AWS/Azure Relay P2P server to which the camera has been registered. But if communication using the private IP fails then the client establishes connectivity with this Relay P2P server. Recall that the camera has already a p2p socket opened with this server. Communication is over UDP. In my opinion, this has been adopted because a number of ISPs restrict users to connect directly to other devices. Technically this is not P2P as there is the Relay server in the middle. So in this case the encrypted packets flow from the client to the Relay server and from the Relay server to the camera and vice versa. In this case the encrypted credentials are sent to the camera through this Relay P2P server. And here comes a question....if there are 1000 12Mbps@25fps and using high def H.265 and the cameras are being accessed remotely using the public IP, then on the P2P relay servers we need a bandwidth of 17Gbps .......... which is really massive.....This explains the delay between viewing using private/local IP (cameras and client on same network) and public IP (other). And I do not think that neither Amazon nor Azure will give unlimited bandwidth.

Now the question being posed is 'Do we trust this setup?' Do you trust passing the bank information when buying over the internet? Do you trust ATM machines which are connected over BB? Do you trust your voice calls over 3G (A5/2 encryption)? etc etc.............. so you have the answer.

No matter how much security you have...there is always a way to get through. Even Alcatraz was a prison where nobody can escape...but they escaped. Nevertheless we need to do our best to protect and be secured.

Apologise for the lengthy answer...but this is high level...can go to the low level...ha ha these are rather simple protocols with the most complicated being within the Telco NEs.

[user_711147997069442_711147997069442]

This post is deleted!