2 ms·

very cool! was recently musing about how the next frontier in vpns is steganography, and here we are. are the webrtc streams running at a constant bitrate or c

by a-dub 4y ago

very cool! was recently musing about how the next frontier in vpns is steganography, and here we are. are the webrtc streams running at a constant bitrate or can the streams be detected by doing traffic timing analysis? (i once looked at adding constant bitrate support to wireguard but ultimately abandoned it as it was looking to be excessively complicated)

pojntfx 4y ago
Thanks! Its using the Pion library[1] which doesn't seem to be using a constant bitrate; that would definitely be an interesting addition though. Sending e.g. zeroes when its not transmitting packets/frames is totally doable, but atm not implemented. [1] https://github.com/pion/webrtc https://github.com/pion/webrtc
- a-dub 4y ago
  the other big upshot would be that it would never leak anything in the flow characteristics of the stream. i suspect that it might be possible to identify major websites being loaded by simply analyzing packet sizes and timings, but maybe not in http/2 world.
saurik 4y ago
This is the kind of thing I would expect to see soon from Orchid, if that's interesting, which isn't "P2P" in this sense of group-networking but that doesn't seem to be your specific interest. (I am in charge of technology at Orchid.)
Sean-Der 4y ago
The constant bitrate idea is really interesting, I think we could do it! I wonder if we can publish a constant rate at the public API of if it would take some interaction with the Congestion Controller in SCTP.
- a-dub 4y ago
  i agree! it's been percolating for a very long time in my head. i was envisioning a paper that shows how traffic analysis can be used to identify activities in the encrypted stream and then a cbr patch to ameliorate it. where it gets complicated is avoiding creation of new side channels. you need a very stable clock for pumping out the data and as you hint at, congestion control to avoid latency by actively adjusting the bitrate. i was looking at doing this in the kernel implementation of wireguard, but those parts of the kernel didn't seem a good fit for this kind of time sensitive constant spinning algorithm. if anyone is interested in this, would love to collaborate.

by a-dub 4y ago

pojntfx 4y ago

Thanks! Its using the Pion library[1] which doesn't seem to be using a constant bitrate; that would definitely be an interesting addition though. Sending e.g. zeroes when its not transmitting packets/frames is totally doable, but atm not implemented. [1] https://github.com/pion/webrtc https://github.com/pion/webrtc

a-dub 4y ago
the other big upshot would be that it would never leak anything in the flow characteristics of the stream. i suspect that it might be possible to identify major websites being loaded by simply analyzing packet sizes and timings, but maybe not in http/2 world.

saurik 4y ago

This is the kind of thing I would expect to see soon from Orchid, if that's interesting, which isn't "P2P" in this sense of group-networking but that doesn't seem to be your specific interest. (I am in charge of technology at Orchid.)

Sean-Der 4y ago

The constant bitrate idea is really interesting, I think we could do it! I wonder if we can publish a constant rate at the public API of if it would take some interaction with the Congestion Controller in SCTP.

a-dub 4y ago
i agree! it's been percolating for a very long time in my head. i was envisioning a paper that shows how traffic analysis can be used to identify activities in the encrypted stream and then a cbr patch to ameliorate it. where it gets complicated is avoiding creation of new side channels. you need a very stable clock for pumping out the data and as you hint at, congestion control to avoid latency by actively adjusting the bitrate. i was looking at doing this in the kernel implementation of wireguard, but those parts of the kernel didn't seem a good fit for this kind of time sensitive constant spinning algorithm. if anyone is interested in this, would love to collaborate.