Customers using transparent proxy must actively decrypt traffic in order to distinguish between YouTube.com and Google.com.
Transparent Proxy deployment, HTTPS Proxy enabled
Previously, Google used different SSL server certificates for each of their primary domain names. So if you connected to https://www.google.com and https://www.youtube.com, you would see different server certificates, each specifying that they are valid for one of those two domains.
Recently, Google has switched to using a single SSL server certificate for all of their web properties, signed by their own in-house CA. So if you browse to the two domains listed above using SSL, you will get the same certificate. That certificate uses an extension to X.509 called "SubjectAltName" to list a few dozen domains as valid for that certificate. A full list of Google domains that are valid for this new certificate is below.
This works fine for browsers: your browser knows it is trying to connect to youtube.com, it sees a certificate that is valid for youtube.com (and a dozen other things), and it lets the connection go through without any warnings.
How This Impacts the WSA
For any proxy server, the first thing you need to do when you see a request from a client is determine what web destination that client is trying to go to. For plain HTTP, it is pretty easy: look at the Host header in the HTTP request.
For SSL, it is more difficult. In explicit proxy mode, the browser tells us in the CONNECT request, so that is easy. The difficulty comes in transparent mode. With decryption enabled on the WSA, we need to determine where the user is trying to browse to before actually decrypting the connection.
Today, we do this by looking at the IP address the client is trying to connect to, connecting to that IP ourselves, and looking at the certificate, in particular, at the CN field. This works well when a unique hostname has its own SSL server certificate. It also allows customers to implement some amount of policy enforcement for SSL traffic without decrypting anything, and thus without distributing the WSA's CA cert to their clients. A customer can allow https://www.google.com but block https://www.youtube.com by setting the first to "allow, don't decrypt" and the second to "drop" in the decryption policy.
Now, youtube.com and google.com serve up the same server certificate. This means that in order to distinguish between the two, WSA has to look for something other than just the certificate served up at the IP address to which the client is trying to connect.
The solution to this issue is being tracked as Cisco bug ID 74969.
If you have a configuration affected by this, then the immediate solution is to turn on active decryption of SSL traffic. For customers who have not previously distributed the CA certificate from the WSA, they will need to start doing so. This is the best general solution to the problem.
List of domains for which Google's new certificate is valid:
DNS Name: *.google.com DNS Name: google.com DNS Name: *.atggl.com DNS Name: *.youtube.com DNS Name: youtube.com DNS Name: *.ytimg.com DNS Name: *.google.com.br DNS Name: *.google.co.in DNS Name: *.google.es DNS Name: *.google.co.uk DNS Name: *.google.ca DNS Name: *.google.fr DNS Name: *.google.pt DNS Name: *.google.it DNS Name: *.google.de DNS Name: *.google.cl DNS Name: *.google.pl DNS Name: *.google.nl DNS Name: *.google.com.au DNS Name: *.google.co.jp DNS Name: *.google.hu DNS Name: *.google.com.mx DNS Name: *.google.com.ar DNS Name: *.google.com.co DNS Name: *.google.com.vn DNS Name: *.google.com.tr DNS Name: *.android.com DNS Name: *.googlecommerce.com