4 ms·
Given that they own the whole stack, there would be value in statically encrypting content and serving that through an unencrypted channel, after having served
by rakoo 11y ago
Given that they own the whole stack, there would be value in statically encrypting content and serving that through an unencrypted channel, after having served the correct parameters through an authenticated-encrypted channel of course.
Basically, something like serving a torrent file through HTTPS and then using standard, unencrypted, full-speed bittorrent for sending the raw data.
- manigandham 11y agoThey don't control the browsers though.
- icebraining 11y agoThey don't need to - if they serve the video player (Flash, JS, whatever) over HTTPS, they can then use it to verify the stream.
- icebraining 11y agoSince the files are public, static encryption wouldn't do any good - the attacker could still build a database of hashes of all encrypted files, and then identify what you downloaded. What they really need is to sign the files, to avoid tampering. TLS actually supports this, using a NULL cipher - you can make a regular HTTPS connection where the domain is verified and the data is protected from tampering, but everything is in clear-text. Alas, browsers don't support this configuration, since it's usually used by mistake or as an attack.
- rakoo 11y agoSo there are 2 things we want to protect against: 1. Attacker tampering with the data 2. Attacker learning what the user is watching For 1. as I said the easy way is to distribute the torrent file through an authenticated, verified connection and then use that torrent file to get the raw data. Anything that doesn't hash to a piece in this torrent file is considered garbage. For 2. that's an issue I didn't have in mind, and as long as the attacker can sign-in they can match an exchange with a database of hashes, so it's not protected in this regard.