WebRTC uses a peer-to-peer (P2P) architecture for communication. In a P2P network, peers (users' devices) communicate directly with each other without intermediaries, using IP addresses or IDs to connect. Think of it like dialling a friend's phone number; your number appears on their caller ID, linking your identities. WebRTC operates similarly, with no central servers; peers connect dynamically. This decentralized approach enables seamless data exchange and minimizes lag. Just know your Internet Service Provider(ISP) can basically do whatever it wants. Law enforcement can also spy on you through your ISP.
Everyday sites like Facebook, Discord, WhatsApp, Signal, Snapchat, Twitter(X) and many more utilize WebRTC. It's also an open-source program, allowing the community to edit code and address exploits promptly, this allow for keeping WebRTC up-to-date. Community auditing ensures better performance and security for users. Open-source projects provide access to source code, enabling programmers and engineers to write patches in real time.
Like all web applications, security in WebRTC falls into two categories: application and server security, which is the responsibility of the entity maintaining them, and personal security, which users must uphold. Security isn't black and white; vulnerabilities exist, as with human flaws. WebRTC's open-source nature also means hackers can review code for potential manipulation.
Hackers can exploit WebRTC, compromising users' actual IP addresses despite VPN use due to how WebRTC is coded. A STUN server facilitates this; it relies more on browsers than VPNs (This means that it's in direct communication with your net work undermining the purpose of a VPN), exposing IP addresses to servers. STUN utilizes NAT and UDP traffic to find IPs for seamless connections, appealing to developers for its direct system connections. What does this really mean? This means that the STUN server communicates with only IP addresses. It will bypass your VPN because the device you downloaded to use WebRTC has your IP and other data points about you (Even to the size of your screen).
RTP Bleeds, a favourite exploit of mine, involves injecting evil packets into recorded or streaming data, enabling stream manipulation through an open port. This method, almost like phreaking in the 70s and 80s, exploits frequency harmonics, basically using sound to hack. 2600hz baby (Only the phreakers will get it). This is not a new trick, just a revided trick. Computers and Lan Line systems still have many things in common. A system admin can write simple tool that will test the ports to see if anything can come through, they can also write a bit of code that will log all the traffic and they can monitor logs on a regular bases. There are other methods that can be put in place to stop these attacks, I get into that sometime later.
Hackers also understand that P2P itself, by default, is vulnerable to exploits. These exploits can lead to problems with server connections, DDoS attacks, and Sybil attacks (which I spoke about in an earlier blog post). Man-in-the-middle attacks are also a concern for some. Now, why would this happen? SDP needs to be trusted when communicating because it's easy to trick. It is set up to communicate with many different browsers, and in a larger setting, there is way more traffic to deal with. Evil packets could be injected to trick this process. That's why browsers use HTTPS protocols to help protect against this. Better encryption methods can counter a sneaky packet. We could simply zap it with a 404 in the server if it catches something sneaky. There is one attack that concerns me, thats the 51% law. If one enity can control atleast 51% they can do whatever they want. After 10 years this is still a topic I research. If a malicious group controlled over 50% of the WebRTC network, they could potentially manipulate communication channels by disconnecting or connecting to people, or change the data being flowed.
I can sit here and name a bunch of exploits that people should be concerned about, but I feel this is more of a lesson on personal security and the security big tech should be pushing for. People need to take their privacy seriously. As far as companies using WebRTC, if the company takes security seriously, they can find fixes for all the things that need better security. I like zero-trust encryption and decentralized networks because they just make sense to stay safe(I wrote about it in different blogs), but at the same time, companies need to be able to hold those who break laws or rules accountable for their actions.
If someone implements things like Stronger Encryption methods and protocols, Stronger authentication systems, Keeping all libraries up to date, Searching for exploits and fixing them because they are abused, Secure WebSockets, sandboxing environments, and stronger user verification methods. Any system admin would know these things. The point is to build an environment that is safe for the company and for the users. It's all about building the system properly. WebRTC is fine for the masses if implemented correctly.
There is always the idea of taking a protocol like WebRTC and improving it by rewriting your own version for security and making it closed source to keep hackers or others out. I strongly feel that building your own communications system is always the best idea if you have the resources to get it done. Keeping in mind if you are communicating on any platform online you are in the eye of the hacker. They love manipulating systems to do their bidding. Like I always say.. Security is a cat and mouse games and the roles are always changing.
Sources:
https://surfshark.com/webrtc-leak-test
https://security.stackexchange.com/questions/56775/is-webrtc-safe-against-man-in-the-middle-attacks
https://www.rtcsec.com/newsletter/2023-07-rtcsec-news/
https://www.msn.com/en-us/news/technology/webrtc-leaks-a-complete-guide/ar-AA1kjKBj