There are two ways to do this:
1) Block it at the firewall, based on the destination IP address and port. For example, when I look up YouTube from my location I get:
C:\Users\mark.henderson>nslookup
Default Server: enetsdc2.enets.local
Address: 192.168.161.2
> youtube.com
Server: enetsdc2.enets.local
Address: 192.168.161.2
Name: youtube.com
Addresses: 2404:6800:800b::88
74.125.237.135
74.125.237.136
74.125.237.142
74.125.237.128
74.125.237.134
74.125.237.129
74.125.237.131
74.125.237.130
74.125.237.133
74.125.237.132
74.125.237.137
>
Which gives you a fairly clear list of what to block, and obviously HTTPS is port 443
. So if you were to block outbound to those IP addresses on 443
then that's a start. Repeat and rinse for each domain.
The catch with this is that this will only block the initial access. There may be other ways to get to the videos, such as on a subdomain that uses a different IP address. For example, Google Maps is served from dozens and dozens of subdomains, and each one could have a different IP address. Trial and error is pretty much the simplest way of going about this.
2) Man In The Middle SSL inspection. I believe that the Microsoft TMG Firewall can do this (although I haven't actually checked). Basically, the SSL connection between YouTube and your network terminates at your firewall. The firewall then decrypts the session, inspects the traffic, applies its filters, and then re-encrypts it with its own, trusted certificate, copying the details from the original certificate.
For this to work, the firewall basically acts as its own CA, issuing certificates for the domains that it does not own. For this to be seamless, each browser/client must trust the firewalls CA, as the certificates will be issued by it, instead of the actual certificate. This is easily detected by anyone with a bit of knowledge (by inspecting the certificate chain). And if set up incorrectly, will give every single user a certificate error.
All in all, I suggest the first method, for the simple reason that it means you're not going to accidentally decrypt the accountants online banking sessions, so you can't be blamed if $100,000 goes missing from the bank account that the CEO keeps for his mistress.
Further to your comments below, there is a third option, that only Google provides as far as I know. This will only work if you are on a network that runs its own DNS servers and you know how to override the public DNS entries for certain sites.
According to Google SafeSearch and SSL Search for Schools , you can override the A
record for www.google.com
with a cname
for nosslsearch.google.com
. This will perform an initial SSL handshake, but will then immediately redirect the user back to non-SSL for searching.
This won't work for YouTube or other services, unless they also offer this service.
Other notes: You are correct that DNS blocking is a bit of a crap method of blocking access, as it can be bypassed. However, if you're on a corporate network, it's likely you're running your own DNS internally, so you could always block DNS traffic headed outside your network, except from your explicitly permitted internal DNS servers. But on the other hand, you can only use DNS for blocking domains, not protocols. So you could block youtube.com, but not permit it on HTTP and block it on HTTPS.
You are incorrect in thinking that the router is the wrong place to be doing this though. In fact, it's the only place you can do it if you want the highest chance of success. Because routers (and the firewalls behind them) are the only ways in and out of your network, you can be 99% that any traffic flowing to the internet is going out through your controls. (the other 1% are people who tether their PCs to their smartphones to get internet access, but this is a management/social issue, not a technical one).