Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YouTube's road to HTTPS

youtube-eng.blogspot.com

Post reply on HN
Print view View original

71–80 of 97 posts

Re: YouTube's road to HTTPS

#71

Post by Animats »

abalone wrote: post #69
Animats wrote: post #68

Earlier quoted context omitted.

It's turning out that HTTPS is more important for content integrity than for security. It's not surveillance that's the big problem for static content. It's middle boxes designed with the delusion they're entitled to mess with the content.

> It's not surveillance that's the big problem for static content. Why would you say this? Surveilling what URLs someone is accessing / content they are watching / books they're checking out of the library has been a major security issue, historically.

HTTPS doesn't conceal the domain, or the length, or the order of requests. It's less of an issue for Google, because so much stuff comes from one domain. For small sites, figuring out who read what isn't a hard problem. In practice, you can probably buy that info from an ad tracking service.

Re: YouTube's road to HTTPS

#72

Post by mrb »

mdani wrote: post #39
acdha wrote: post #34

Earlier quoted context omitted.

Exactly – this is both easier to implement and has the advantage of not incentivizing people to use something like a VPN to get more bandwidth at the expense of everyone else.

Per user limits are not easy to implement, maybe easier to visualize - consider that there are a bunch of packet gateways sitting behind a load balancer and each HTTP session may end up on a different server. There is no entity that counts the live bandwidth usage on a per user basis, let alone control it. Billing and metering is done on a session basis through logs. So from T-Mo's point of view it is much easier to…

Per-user limits is certainly way easier to implement than deploying a cluster of proxies doing on-the-fly transcoding of video streams(!)

Re: YouTube's road to HTTPS

#73

Post by drewg123 »

mschwaig wrote: post #62
drewg123 wrote: post #29

It would be interesting to know how much overhead HTTPS added for them. Eg, a comparison of CPU usage between HTTP and HTTPS on the server side, whether or not they are using hardware offloads, etc. Netflix has some papers about their experience transitioning to HTTPS: https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf However, I expect the YouTube workload w…

I would also be interested in that. What differnce would you expect from the catalog size? I would guess that aside from maybe the handshake, decoupling storage and encryption would not be worth it in all cases where the storage medium is slower than AES-NI and this would apply even more to youtube than to netflix, exactly because of the bigger catalog.

With a small catalog, you can pre-encode everything. That means that in the unencrypted case, media files can be sent directly from the kernel's page cache, as unmapped I/O. Eg, the data is not even touched by the CPU. But in the encrypted case, you're suddenly touching every byte with the CPU, thereby doubling your memory bandwidth requirements.

With a large catalog like YouTube's, I would expect that most of the titles are saved in some master format, and are encoded on the fly. That means that the data is already being touched by the CPU to re-encode it on the fly for whatever format is needed by a particular client.

My expectation is that if YouTube was re-encoding on the fly due to the catalog size, they would suffer less of a CPU hit than Netflix did, so SSL would be "easier" for them to implement.

Re: YouTube's road to HTTPS

#74

Post by acdha »

gleenn wrote: post #65
blowski wrote: post #45

Earlier quoted context omitted.

Eh? Even cheap home routers these days allow you to set QoS rules per device. Have I misunderstood something?

Just because your cheap home router does it doesn't mean it scales to thousands of users on one router. Some home routers are actually quite capable AND very unsaturated. I'm not trying to defend carriers but it is a very apples to oranges comparison.

We did that on low-end PC hardware 15 years ago for conference and guest networks (800+ simultaneous active users, LAN and WiFi).

I find it unlikely that Linux, FreeBSD have gotten less efficient since then and the hardware has made enormous improvements, far in advance of the common uplink speed.

Re: YouTube's road to HTTPS

#75

Post by [deleted] »

drewg123 wrote: post #73
mschwaig wrote: post #62

Earlier quoted context omitted.

I would also be interested in that. What differnce would you expect from the catalog size? I would guess that aside from maybe the handshake, decoupling storage and encryption would not be worth it in all cases where the storage medium is slower than AES-NI and this would apply even more to youtube than to netflix, exactly because of the bigger catalog.

With a small catalog, you can pre-encode everything. That means that in the unencrypted case, media files can be sent directly from the kernel's page cache, as unmapped I/O. Eg, the data is not even touched by the CPU. But in the encrypted case, you're suddenly touching every byte with the CPU, thereby doubling your memory bandwidth requirements. With a large catalog like YouTube's, I would expect that most of the ti…

[deleted]

Re: YouTube's road to HTTPS

#77

Post by DanielDent »

jasonuhl wrote: post #37
mikeash wrote: post #23

Earlier quoted context omitted.

TCP already covers that sort of thing. What HTTPS adds is integrity checks against an intelligent attacker, not just random natural interference.

TCP only gives you 16 bits of checksum, which is really not enough. I used to work for a CDN which served downloads over HTTP, and when the object size grew to a few gigabytes a non-negligible percentage of users ended up with corruption. The SSL MAC is valuable even in the absence of enemy action.

This is a really interesting 'real world' anecdote. Do you know of any related data available publicly? i.e. "on our network, X bits in Y terabytes end up with undetected corruption, meaning that approximately Z% of downloads of a 2GB file will have at least one bit error".

Re: YouTube's road to HTTPS

#78

Post by hueving »

gleenn wrote: post #65
blowski wrote: post #45

Earlier quoted context omitted.

Eh? Even cheap home routers these days allow you to set QoS rules per device. Have I misunderstood something?

Just because your cheap home router does it doesn't mean it scales to thousands of users on one router. Some home routers are actually quite capable AND very unsaturated. I'm not trying to defend carriers but it is a very apples to oranges comparison.

Are there thousands of people on a single flight?

Re: YouTube's road to HTTPS

#79

Post by joshmn »

benologist wrote: post #7
JoshTriplett wrote: post #3

> In short, some devices do not fully support modern HTTPS. I'd love to know which devices, and what "modern HTTPS" features they don't support.

My NAS has security settings for modern, intermediate and old browsers that says it's to do with cipher suites they support - https://imgur.com/a/PmaUE

Love, love love love love LOVE my Synology!

Re: YouTube's road to HTTPS

#80

Post by jsjohnst »

drewg123 wrote: post #29

It would be interesting to know how much overhead HTTPS added for them. Eg, a comparison of CPU usage between HTTP and HTTPS on the server side, whether or not they are using hardware offloads, etc. Netflix has some papers about their experience transitioning to HTTPS: https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf However, I expect the YouTube workload w…

> Luckily, hardware acceleration for AES is widespread, so we were able to encrypt virtually all video serving without adding machines.

Seems that was answered in the article, no?

Post reply on HN