5 ms·

I understand the need for HTTPS when browsing Netflix, but is there really any benefit in encrypting the actual media stream? The file is already encrypted for

I understand the need for HTTPS when browsing Netflix, but is there really any benefit in encrypting the actual media stream? The file is already encrypted for DRM purposes... if thry want to go beyond that, how about a system where each edge server gets a differently encoded file from the master?

wmf 12y ago
I think the context here is that Netflix does not want to serve video over HTTPS but some browsers are talking about restricting EME DRM so that only HTTPS origins can use it.
dantillberg 12y ago
Without encrypting the video contents, anyone sniffing the data stream can easily tell what you're watching, when you paused, or skipped, or re-played, etc. They may not be able to steal your money with that data, but it still exposes real, personal information. (though... I was just thinking about this, and due to the use of variable-bitrate encoding, the varied rate of data transmission over time (even though encrypted) would give each video a fingerprint that an observer could use to determine whatever it is that you're watching, anyway, albeit with greater effort that simply inspecting the unencrypted stream)
- phkahler 12y ago
  >> I was just thinking about this, and due to the use of variable-bitrate encoding As I recall, monitoring total home power consumption could also identify what you're watching on TV. That was on the old CRT sets, not sure about now. Gotta love side channel attacks.
  - wmf 12y ago
    Some HDTVs have dynamic LED backlighting that is probably a power side channel.
    - jjp 12y ago
      http://www.nds.rub.de/media/nds/veroeffentlichungen/2012/07/24/ike2012.pdf http://www.nds.rub.de/media/nds/veroeffentlichungen/2012/07/...
      - thrownaway2424 12y ago
        This is why I only drink rainwater and grain alcohol, and use pure class A amplifiers, Mandrake.
        jjp 12y ago
        And you know that can be tracked as well - http://www.academia.edu/5585470/Hydrological_Studies_Using_Isotopes http://www.academia.edu/5585470/Hydrological_Studies_Using_I...
- Lx1oG-AWb6h_ZG0 12y ago
  If the DRM key is transferred securely, how can an attacker tell what you're watching without fingerprinting the entire Netflix library? You can't just open up parts of the stream and parse it as a plain video file to my understanding. I'll give you the rewind scenario, but play/pause events are going to be equally obvious in HTTPS. Besides, what exactly does the attacker learn? That you were watching Netflix during that time? The HTTPS traffic to Netflix will be an equally good indicator of that.
  - comex 12y ago
    Fingerprinting the entire Netflix library - especially if you limit yourself to popular shows - probably isn't that hard. I concur with not really understanding the point, though. One possibly relevant factor is that shared encryption keys make it harder to authenticate the data: you can't rely on an HMAC, and RSA verifying every frame would be too slow. You can still do it efficiently with a hash tree, but I bet Netflix currently isn't, and TLS allows browsers to enforce verification on behalf of the user. Without verification, you could potentially exploit the browser with malformed audio or video data, or freak the user out by injecting some other video...
  - dheera 12y ago
    I imagine a side-channel attack could reveal some of this information. Fingerprint bandwidth usage over time. Movies consume less bandwidth when scenes move slowly and HTTPS doesn't do a good job of hiding this information.
higherpurpose 12y ago
HTTP can be used not only for spying on you, but for attacking you with malware as well (or even something as "innocent" as being injected with the ISP's own ads): https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/ https://citizenlab.org/2014/08/cat-video-and-the-death-of-cl...
- zaroth 12y ago
  The "Great Cannon" is probably the best demonstration of the perils of unencrypted transport that we could have hoped for.
- Lx1oG-AWb6h_ZG0 12y ago
  Yes, I agree with you, but in this specific instance, when the DRM key has been transferred securely -- and when everything in the pipeline will fail when the content is messed with -- what is the point of HTTPS?
jemfinch 12y ago
You'd be surprised how many ISPs want to MITM media.
deleted 12y ago
[deleted]
pornel 12y ago
It's not about encrypting video files specifically, but: * Not leaking any tracking or user-identifiable information. EME DRM plug-ins track users, but browsers don't have control over this (and I guess it may even be illegal to audit EME DRM security due to DMCA), so it's best to have it on HTTPS just in case. * All new browser features require HTTPS (and EME DRM plug-ins are new-ish), because browser vendors want to deprecate HTTP, and don't want headache of mixed content or HTTPS alternatives built on DRM.
- hsivonen 12y ago
  Saying "EME DRM plug-ins track users" is misleading. Rather, an EME DRM plug-in designed only to fulfill its DRM mission in a straight-forward way without specifically trying to also fulfill a privacy mission is likely to have the side effect of exposing identifiers that network eavesdroppers could use for tracking.
hsivonen 12y ago
In the HTML5 context, adaptive streaming is done with the MSE API. This involves fetching the media data using XHR. Since mixed-content XHR is blocked, if the app is on an https origin, the media data has to come from https origins, because cross-scheme CORS is blocked for security reasons. You want to have the app on https for several reason, starting with the security of session cookies, but in the case of DRM, there's a reason for browsers to seek to limit the EME API (the JS API for communicating with the DRM component) to https (though AFAIK no browser does so at the moment): DRM schemes usually implement node locking, i.e. anti-cloneability of the DRM state from one device to another. The obvious way to do this involves keys that no other device has. If information about the possession of a persistent key that no other device has is exposed to a network eavesdropper (e.g. by presenting, in the clear, a certificate for a unique key), the eavesdropper can use that piece of information to track devices and, therefore, users. While this problem could be mitigated in the design of the DRM protocol, to move addressing the problem out of what the DRM component controls to what the browser controls, limiting EME to https is the most straight-forward solution that can be implemented on the browser level. And as noted above, this has the side effect of limiting the MSE-feeding XHR to https, which means the media data needs to be served over https.

wmf 12y ago

I think the context here is that Netflix does not want to serve video over HTTPS but some browsers are talking about restricting EME DRM so that only HTTPS origins can use it.

dantillberg 12y ago

Without encrypting the video contents, anyone sniffing the data stream can easily tell what you're watching, when you paused, or skipped, or re-played, etc. They may not be able to steal your money with that data, but it still exposes real, personal information. (though... I was just thinking about this, and due to the use of variable-bitrate encoding, the varied rate of data transmission over time (even though encrypted) would give each video a fingerprint that an observer could use to determine whatever it is that you're watching, anyway, albeit with greater effort that simply inspecting the unencrypted stream)

phkahler 12y ago
>> I was just thinking about this, and due to the use of variable-bitrate encoding As I recall, monitoring total home power consumption could also identify what you're watching on TV. That was on the old CRT sets, not sure about now. Gotta love side channel attacks.
- wmf 12y ago
  Some HDTVs have dynamic LED backlighting that is probably a power side channel.
  - jjp 12y ago
    http://www.nds.rub.de/media/nds/veroeffentlichungen/2012/07/24/ike2012.pdf http://www.nds.rub.de/media/nds/veroeffentlichungen/2012/07/...
    - thrownaway2424 12y ago
      This is why I only drink rainwater and grain alcohol, and use pure class A amplifiers, Mandrake.
      - jjp 12y ago
        And you know that can be tracked as well - http://www.academia.edu/5585470/Hydrological_Studies_Using_Isotopes http://www.academia.edu/5585470/Hydrological_Studies_Using_I...
Lx1oG-AWb6h_ZG0 12y ago
If the DRM key is transferred securely, how can an attacker tell what you're watching without fingerprinting the entire Netflix library? You can't just open up parts of the stream and parse it as a plain video file to my understanding. I'll give you the rewind scenario, but play/pause events are going to be equally obvious in HTTPS. Besides, what exactly does the attacker learn? That you were watching Netflix during that time? The HTTPS traffic to Netflix will be an equally good indicator of that.
- comex 12y ago
  Fingerprinting the entire Netflix library - especially if you limit yourself to popular shows - probably isn't that hard. I concur with not really understanding the point, though. One possibly relevant factor is that shared encryption keys make it harder to authenticate the data: you can't rely on an HMAC, and RSA verifying every frame would be too slow. You can still do it efficiently with a hash tree, but I bet Netflix currently isn't, and TLS allows browsers to enforce verification on behalf of the user. Without verification, you could potentially exploit the browser with malformed audio or video data, or freak the user out by injecting some other video...
- dheera 12y ago
  I imagine a side-channel attack could reveal some of this information. Fingerprint bandwidth usage over time. Movies consume less bandwidth when scenes move slowly and HTTPS doesn't do a good job of hiding this information.

higherpurpose 12y ago

HTTP can be used not only for spying on you, but for attacking you with malware as well (or even something as "innocent" as being injected with the ISP's own ads): https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/ https://citizenlab.org/2014/08/cat-video-and-the-death-of-cl...

zaroth 12y ago
The "Great Cannon" is probably the best demonstration of the perils of unencrypted transport that we could have hoped for.
Lx1oG-AWb6h_ZG0 12y ago
Yes, I agree with you, but in this specific instance, when the DRM key has been transferred securely -- and when everything in the pipeline will fail when the content is messed with -- what is the point of HTTPS?

jemfinch 12y ago

You'd be surprised how many ISPs want to MITM media.

deleted 12y ago

[deleted]

pornel 12y ago

It's not about encrypting video files specifically, but: * Not leaking any tracking or user-identifiable information. EME DRM plug-ins track users, but browsers don't have control over this (and I guess it may even be illegal to audit EME DRM security due to DMCA), so it's best to have it on HTTPS just in case. * All new browser features require HTTPS (and EME DRM plug-ins are new-ish), because browser vendors want to deprecate HTTP, and don't want headache of mixed content or HTTPS alternatives built on DRM.

hsivonen 12y ago
Saying "EME DRM plug-ins track users" is misleading. Rather, an EME DRM plug-in designed only to fulfill its DRM mission in a straight-forward way without specifically trying to also fulfill a privacy mission is likely to have the side effect of exposing identifiers that network eavesdroppers could use for tracking.

hsivonen 12y ago

In the HTML5 context, adaptive streaming is done with the MSE API. This involves fetching the media data using XHR. Since mixed-content XHR is blocked, if the app is on an https origin, the media data has to come from https origins, because cross-scheme CORS is blocked for security reasons. You want to have the app on https for several reason, starting with the security of session cookies, but in the case of DRM, there's a reason for browsers to seek to limit the EME API (the JS API for communicating with the DRM component) to https (though AFAIK no browser does so at the moment): DRM schemes usually implement node locking, i.e. anti-cloneability of the DRM state from one device to another. The obvious way to do this involves keys that no other device has. If information about the possession of a persistent key that no other device has is exposed to a network eavesdropper (e.g. by presenting, in the clear, a certificate for a unique key), the eavesdropper can use that piece of information to track devices and, therefore, users. While this problem could be mitigated in the design of the DRM protocol, to move addressing the problem out of what the DRM component controls to what the browser controls, limiting EME to https is the most straight-forward solution that can be implemented on the browser level. And as noted above, this has the side effect of limiting the MSE-feeding XHR to https, which means the media data needs to be served over https.