Case Study: Google SSL search protects your search terms

Google announced last week that users can visit https://www.google.com to establish a secure connection for their searches, which Google says “helps protect your search terms and your search results pages from being intercepted by a third party on your network”.

In response to the worries that search terms are eavesdropped by third party on public Internet accesses, especially at public like WIFI hotspots at airport, Google offers a connection over HTTPS to protect your search terms been sniffed. The purpose of this article is to figure out how does the encrypted search connection work and see if it really protects you. As packets never lie, we will go down to the packet level to check the original traffic out. Let Capsa network analyzer to prove that. First let’s check out how the normal search goes.


Normal Google Search

First run Capsa Network Analyzer and start a capture, then visit http://www.google.com, enter the keyword Capsa, and click the Google Search button. Until now, we can clearly see a HTTP packet captured with the keyword “Capsa”. If in a public network, the hacker can easily get the GET request and figure out your search terms with little tricks.



And another important way to get your search terms is to get the packet of your clicking on a link in the search results, which contains the keywords too. In this case we will click the second link in the results. When we go back to the packets, we can see there are two DNS packets, a DNS query and a response, then three-way-handshake with www.colasoft.com. The fourth packet is a HTTP GET packet (don't know much of TCP? read how to learn TCP communication).



If you are interested in this GET packet, you will find a Referer string in it, which is pretty the same as the string in figure below.





Encrypted Google Search

After the normal search, we flush the DNS (ipconfig /flushdns), start a new capture, and reopen the browser. This time we visit https://www.google.com, enter the same keyword “Capsa”, and click the Google Search button. The page loaded and we go back to the analyzer and find there are DNS packets and HTTPS packets, without any HTTP packets. As all transmissions are protected by SSL, we cannot find any search keyword in these packets, unless you have that power to decode them.



Then we click the same link over the returned search results, and we find there are two DNS packets too and three-way-handshake and then a HTTP GET packet to load the Colasoft page. We can check this packet and find there is not a Referer string in it. As google’s explanation, they’ve stopped transferring this value to the clicked page to prevent keywords being tracked.



Google also pointed out that the encryption search only protects you from keywords tracking but the website you visit later could also be spotted because of you DNS queries. And that’s something they cannot do about. But that’s not the topic of this article. We can sure that the new HTTPS Google search does what it alleged (you can learn more Google SSL search from http://www.google.com/support/websearch/bin/answer.py?answer=173733&hl=en). Furthermore, the society is talking about the network security more and more these days. We should always pay attention to our communications on the Internet, emails, social media communications and passwords, and so on.

by Sam Chen with Colasoft