Netflix and HTTPS

[BobW]

I am curious what the general take of the recent Netflix announcement is with regard to our ability to control the traffic. Announcement here .  I have an opinion as to whether it is necessary, but that is another subject altogether.

It is clear there is only so much application ID that can occur if the data is encrypted, but can it be combined with URL rules to control the traffic?  We would, for example, have to know all of the URLs/subnets that youtube (or Netflix) videos are streamed from.  Is that even possible?

We have yet to implement any decryption, but I see that it is going to have to happen at some point.  But if we implemented it, is anything going to be able to keep up with the decryption process when it is decrypting a bunch streaming data?

Any thoughts would be appreciated,

Bob

[jvalentine · Accepted solution]

No different than something like Facebook.  You can see the domain name in the SSL certificate (unencrypted) during the handshake. 

Without decryption, you're limited to permit/deny on the application as a whole.

With decryption, you have access to the sub-functions within that application (ie: being able to tell the difference between netflix queue management and streaming, or the difference between facebook-posting and facebook-file-transfer). 

Even if you don't use decryption, you'll at leave be able to tell that it's Netflix traffic. 

I highly recommend enabling decryption, though.  Not enough people do it... more people need to.

[cstancill]

Jared is absolutely correct regarding using decryption to enable inspection. To address the performance concern: whether or not decryption has an appreciable effect on your performance depends entirely on *how much* you are decrypting. Each platform has specific upper limits in terms of the maximum number of concurrent decrypted sessions. The additional overhead caused by decryption will depend on this volume. You can limit the scope of decrypted traffic using different criteria (e.g. URL category). This approach will let you inspect things that need to be, like youtube, facebook, etc. while not wasting resources on sessions that probably don't need to be (e.g. online banking, healthcare, etc).

[BenjAudy.MTL]

It depends if Netflix just wants to protect the name of the content being watched, or if they really want hide the fact you watch Netflix at all. Like Jared said, you can see the domain name during the SSL/TLS handshake, so you will still be able to block Netflix if you want. After all, if a user cannot login to the main page, he won't be able to watch anything.

The problem I see is more with the QoS. The content is currently streamed from a lot of servers using domain names ending in *.nflxvideo.net. If Netflix encrypts those streams and change the domain name to something less obvious, the firewall will see it as generic encrypted traffic and the QoS rule for Netflix won't match, unless you have a decryption rule in place. I guess there will also be the option of simply giving a low priority to generic encrypted trafic.

[BobW]

Thank you for the reply.  I guess my point is if streaming media is using encryption for all traffic, soon everyone will.

Maybe a better example is:  Someone logs onto Google.com, then goes to youtube via the google apps link.  Unless I am missing something, the PA is seeing this traffic as SSL as the call to google is already encrypted.

Bob

[jvalentine]

Bob, that's a perfect example.  If google uses *.google.com as a certificate for all of their properties (including youtube, gmail, google-search, google-hangouts, etc.) then it will become increasingly difficult to identify, inspect, and secure the traffic within that SSL tunnel without performing SSL decryption.