ekaleido
Mar 05, 2015Cirrus
SPDY and filtering URLs that traverse an existing connection
As I understand it, this is a basic version of SPDY as it relates to Google Hangouts...
- Your browser connects to www.google.com:443
- Your firewall/proxy accept this request and lets it pass through it and all data in this connection is now encrypted. No one knows what requests you are doing, except Google and the computer.
- Because of SPDY, www.google.com replies that it can also handle talkgadget.google.com, mail.google.com, … requests. This helps to save time, because creating a new connection is a long process.
- When the browser see this reply, it stores the information.
- Now, you connect to Hangouts, through talkgadget.google.com:443.
- The browser detects that it already has a connection to www.google.com:443 who also handles talkgadget.google.com requests, so it sends a requests on the same connection.
- As the request is encrypted, the firewall doesn’t even know that you’re doing a request to talkgadget.google.com, it just knows it’s the same connection, so it lets data pass through it.
- You get a reply and Hangouts can connect.
Has anyone tried, or been successful at, stopping the SPDY messages that enable talkgadget.google.com or blocking it inside the SPDY stream? iRule?
Considering everything is encrypted, could I create a fake www.google.com virtual server facing my inbound VLANs that proxies out so it can decrypt?