P2P Stream Hijacking
Learn about how to securely stream a P2P live stream without the danger of peers manipulating your video content.
How to securely deliver P2P live streams
Modern live streaming technologies like HLS or MPEG-DASH are mostly based on HTTP.
This means, existing infrastructures like CDNs or web caches can easily be utilized to optimize the delivery. For security reasons, HTTP is getting replaced by HTTPS, so most live streams are already secured against most man-in-the-middle attacks.
Differences between HTTP and HTTPS:
- HTTP sends data over port 80 while HTTPS uses port 443.
- HTTP operates at application layer, while HTTPS operates at transport layer.
- No SSL certificates are required for HTTP, with HTTPS it is required that you have an SSL certificate and it is signed by a CA.
- HTTP doesn’t require domain validation, where as HTTPS requires at least domain validation and certain certificates even require legal document validation.
- No encryption in HTTP, with HTTPS the data is encrypted before sending.
However, live streaming in general is a growing market and it is actually growing faster than CDNs and the internet infrastructure. Therefore, long buffering times and multiple stream crashes are usual for high interest streams like sports or gaming. We at Strive believe that the solution for this problem is based on WebRTC (P2P) to distribute the load evenly among all viewers.
But there is a catch, what happens, if the viewers, who are supposed to send video chunks to each other, are not trustworthy? You could say, that this is a corner case, but actually it is not!
We call this problem Stream-Hijacking, which means that an attacker could turn a P2P-optimized live stream into anything he wants. Basically, P2P/WebRTC-based live streaming optimizations disable HTTPS, which is a big deal.
noun | plural: Stream-Hijackings
An act of illegaly changing streaming content by compromising the origin server.
The solution is to employ a new trust system within the delivery process to keep the guarantees promised by HTTPS. At first, SHA or MD5 hashes seem fine in order to prove data integrity, since they are very hard to break. But this can easily introduce a lot of overhead, since every viewer has to know the hash of any chunk. This might sum up in total and becomes very fast inefficient.
We at Strive solved this issue very uniquely by using digital signatures.
This way, each viewer only has to know its own chunk and signature and is free to forward both to other viewers. Now, if a viewer receives a chunk and signature from another viewer, it can easily check and verify data integrity. We used this technique in our innovative product StriveCDN TrafficBoost, which is first on the market solving Stream-Hijacking once and for all.