1

I notice that https://gaming.youtube.com/ is secure with https.

Does the live content (videos) produced by a youtube's user is 'encrypt' too on the network ? what is the point ?

For example, Twitch doesn't use https for streaming video. And if i check this post, there is no point to do streaming with https https://stackoverflow.com/questions/1063082/streaming-video-in-https

I need some clarification about this.

Community
  • 1
mpgn
  • 290
  • 3
  • 15
  • One important point is to prevent tampering to replace parts of the videos in transit. – Natanael Dec 13 '15 at 16:20
  • 3
    Note that the question and answer on Stackoverflow you posted is from 2009. Lots of things have changed in IT security since then, namely the Snowden leaks creating a higher awareness for information security and easier access to SSL certificates and hardware acceleration for encryption decreased the cost associated with using HTTPS everywhere. – Philipp Dec 13 '15 at 18:19

2 Answers2

7

Yes, videos loaded over HTTPS will be encrypted when in transit.

HTTPS employs TLS/SSL over HTTP connections. This provides confidentiality - that is, no one on the network is aware of what you are watching, and integrity - no one can alter the video stream to substitute in a different video. Although which video you are watching could be deduced by other means - a side channel attack could be used to analyse the amount of data sent over the wire and attempt to determine possible videos that match the traffic profile.

Using HTTPS for streaming does add privacy. However, the real reason would be to protect session cookies on the rest of the site from being intercepted to protect user accounts as it is not possible to serve plain HTTP content on an HTTPS page without the browser warning the user.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • I'm just going to point out a single flaw in your answer that everyone seems to have missed -- just because a page is loaded over https doesn't mean that all of its resources are too. – Jonathan Gray Dec 14 '15 at 00:12
  • Please see my final sentence. If you have an HTML page loaded over HTTPS, [you cannot include references to any resources that would be loaded over plain HTTP](http://security.stackexchange.com/q/17156/8340). This is to protect the end user - if the browser is informing the user that the page has been encrypted in transit, a single HTTP reference means that at least part of the page is potentially insecure in transit, and depending on what that resource is, it could potentially affect the security of the page. Therefore browsers always show a warning if an HTTPS page includes HTTP. – SilverlightFox Dec 14 '15 at 09:17
  • The real issue I have is with this statement: "it is not possible to serve plain HTTP content on an HTTPS page without the browser warning the user" -- This applies with external content referenced within the HTML of the page, and possibly AJAX requests as-well, however it is entirely possible to load HTTP content with WebSockets without so much as a hint that any part of the page is not secure. I know this through experience. Plus, it probably even depends on the browser. – Jonathan Gray Dec 15 '15 at 03:43
  • Modern browsers will show a warning. WebSocket Secure (WSS) is WebSockets over SSL/TLS so that would be allowed on an HTTPS page. You can [see here](http://meta.stackoverflow.com/q/278720/413180) an example of an error message when WS is blocked over HTTPS. If you have any evidence to the contrary, please link to it. – SilverlightFox Dec 15 '15 at 10:10
  • I'm not sure when Chrome changed but a while back when developing one of my projects, I did the final switch to https and during that switch I noticed that I was still loading the http version of my websocket. There was no indication that any insecure content was being loaded, and nothing was being blocked. After viewing the link you provided I quickly set up another test and discovered that Chrome now absolutely refuses to initiate the insecure connection over TLS. TBH I thought that it was on purpose to allow encryption-free streaming. I don't know why they're implementing such restrictions. – Jonathan Gray Dec 15 '15 at 11:10
0

Just checked a random video there: Yes, the video data itself comes over Https too.
(of course, it's no guarantee that this holds for all videos, but I see no reason why it should vary)

Why? eg.
a) Did you read the second answer in your link? Insecure content warnings with a page on HTTPS and the video not were not a problem with Flash, but nowadays with HTML5...
b) I think YT has some possibilities to make a video only visible for specific users instead of everyone, depending on the level of confidentially of the content it might as well make sense to encrypt it.
...

deviantfan
  • 3,854
  • 21
  • 22
  • How did you conclude that the stream is coming through https? I found evidence to the contrary. – Jonathan Gray Dec 13 '15 at 18:04
  • 1
    @JonathanGray The video is loaded from some Url starting with eg. `https://r1---sn-uxax3vh50nugp5-8pxk.googlevideo.com/videoplayback?...` (really long parameter chain not posted). CDN servername will vary, and usually there are multiple calls for loading certain time ranges separately. If you found some link to a non-HTTPS-Site not being the video itself, this means nothing. – deviantfan Dec 13 '15 at 20:53
  • How I did find it? Copy-paste from Firebug in this case. And yes, the statement that this is the video is provable (just take the time ranges and included correctness hash into account, wget the data, and feed it to VLC or view it in a hex editor and check the data header manually. I did some experiments around YT downloading about a year ago, where I did exactly this for several cases). ... I've yet to see any "evidence" why it should be wrong. – deviantfan Dec 13 '15 at 21:09
  • Did you check for a 301 or 302 redirect to http or are you just assuming that no redirect is taking place when you try loading that URL? Sorry for being so skeptical it's just that I see no reason for the stream itself to be encrypted, and the place where I found the URL redirect to http is *inside of the https video embed source*. My guess is the JS simply grabbed the stream from the main youtube site. – Jonathan Gray Dec 14 '15 at 00:04
  • I found the same link you did using the network tab in the console in Chrome. Not sure why I didn't try that to begin with. To be honest I guess I've just been used to the old school way of reverse engineering websites. However there's no need for belittlement. All I asked for was a reference to back up your claims. Besides, what I found was evidence that non-encrypted data was available over a supposedly secure connection. Which directly correlates with the nature of the question. I know that it doesn't mean that the connection is not secure. It's not good to assume, you know... – Jonathan Gray Dec 14 '15 at 02:17
  • Just for completeness, Firebug lists redirections separately, so yes, it can't be a redirection. ... If something in my comments sounded belittling, sorry for that. – deviantfan Dec 14 '15 at 02:30