生活在此处，你永远也不知道自己身边在发生些什么。作为饮水思源BBS
Google板的板主，我常常看到有人抱怨
Google被重置，Gmail不稳定。这种情况必然事出有因，这种反馈却常常语焉不详。我能理解用户这种被误导被愚弄的滋味，但在信息量不足以支持判断的情况下，我只能是爱莫能助。
为了让自己好受些，我常安慰自己：何苦让这些人的无知折磨自己。但在我内心深处，我却知道事实并非如此：技术的成果不能为民众共享，却反而要民众为技术所禁锢，谁又该为这些人的不公正待遇负责？
这种心情别人很难理解。
发现问题
如何提问
在正式提问之前，让我们先问问自己，该如何提问？
提出的技术问题能否得到正确的解答，很大程度上取决于提问的方式与问题的难度。而问题得不到解决，提问者应该扪心自问，自己是否问错了人，或者问错了问题，或者是否展示出了相当的提问的诚意？
建议读者阅读 < 提问的智慧> 一文，此文列举了提问者常犯的一些错误，避免这些错误可以更好地得到解答。读完此文，你也就能理解，为何stackoverflow 能如此受技术宅欢迎。
搜集线索
此时你应尽可能多地搜集线索。在搜集线索的过程中，有可能你自己就解决了问题；就算你自己解决不了，线索也能为他人提供信息。要知道，大侦探福尔摩斯离开了线索也不能破案。如果有人不依靠线索就能解答你的疑问，这如同医生不把脉就开药方，你最好不要相信这种人。
但是在搜集线索的同时，要注意筛选线索。这几天我遇到一个愚蠢的问题，标题是“为什么电脑突然不能访问ftp了？”，内容除了一堆废话之外，只有下面这张图。请注意，这张图片什么也说明不了！
回到我们的问题，在使用
Google加密搜索的过程中遇到问题，该如何搜集线索呢。在这个例子里，浏览器自带的开发工具并没有给我们更多的提示（快捷键F12可以唤出浏览器的开发工具，通常情况下这是很好的发现和解决问题的工具）。
我们使用wget来代替浏览器，看看在访问
Google加密搜索时发生了什么问题。安装wget后在命令行中输入
我们看到这样的结果：
可以看到，浏览器试图访问两个ip，93.46.8.89和203.98.7.65，而这两个ip都不是Google的ip。
提出问题
那么我们的电脑为什么会把Google的域名解析到不属于Google的ip呢？
分析问题
出于众所周知的原因，我们使用Google提供的
DNS服务器8.8.8.8来测试（如果使用国内的
DNS服务器，得到的结果都是错误的）。
在命令行中运行nslookup，一步一步分析问题。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
nslookup
默认服务器: google-public-dns-a.google.com
Address: 8.8.8.8
#此处有可能不是8.8.8.8，运行下面的命令切换到8.8.8.8
> server 8.8.8.8
默认服务器: google-public-dns-a.google.com
Address: 8.8.8.8
> encrypted.google.com
服务器: encrypted.google.com
Address: 59.24.3.173
#这不是Google的ip地址！
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** 请求 encrypted.google.com 超时
> set vc
#使用tcp协议进行DNS查询
> encrypted.google.com
服务器: google-public-dns-a.google.com
Address: 8.8.8.8
非权威应答:
名称: www3-china.l.google.com
Addresses: 74.125.235.111
74.125.235.96
74.125.235.101
74.125.235.106
74.125.235.97
74.125.235.98
74.125.235.100
74.125.235.104
74.125.235.103
74.125.235.102
74.125.235.110
74.125.235.107
74.125.235.105
74.125.235.109
74.125.235.99
74.125.235.108
Aliases: encrypted.google.com
www3.l.google.com
#这些才是正确的结果
|
我们知道，DNS查询可以通过UDP和TCP两种协议，目前Windows默认使用UDP协议进行DNS查询。而测试的结果是通过UDP协议进行DNS查询时，得到错误的结果；改用TCP协议时得到正确的结果。
那么错误的结果来自哪里呢？我们对UDP协议的DNS查询进行抓包，看到服务器返回的各个包，其TTL分别为31, 92, 32, 41, 41，说明这些包并不来自同一服务器。
再对TCP协议的DNS查询进行抓包，服务器返回的包TTL均为41，说明这些包来自同一服务器。
至此，我们已经分析出了原因：有人在针对Google加密搜索进行DNS缓存投毒。攻击者在探测到经UDP协议对encrypted.google.com的DNS查询请求时，会伪装成DNS服务器，抢先返回错误的结果。而UDP协议没有握手机制，无法验证其真伪，于是客户端就会误把李鬼当李逵。
ps.半年前我做同一个实验时，对TCP协议的DNS查询抓包，也能观测到旁路的干扰包，而且这种TCP包暴露了攻击者的ip。
解决问题
那么我们如何才能用上Google加密搜索呢？
1.客户端检查是否查询名称是其自身；
2.然后，客户端搜索本地 Hosts 文件、 $ IP 地址和名称存储在本地计算机上的列表；
3.查询域系统 (DNS) 服务器；
4.如果仍然不能解决名称，作为备份使用 NetBIOS 名称解析序列。
hosts优先于DNS服务器，所以在不使用代理、ssh、vpn等手段的前提下，手动为域名指定ip是可行的办法。
首先通过nslookup google.com或nslookup ipv6.google.com（如果有ipv6接入）得到正确的Google ip；然后在编辑C:\Windows\System32\drivers\etc\
hosts文件，加入一行
1
2
|
74.125.235.111 encrypted.google.com
#74.125.235.111替换为你查询到的Google ip
|
此时在浏览器中应该能打开Google加密搜索了。
至此，我们搞清楚了不能正常使用Google加密搜索的原因，和相应的解决方法。但我这篇文章的意义仍然在于传授一种分析和解决问题的思想，这篇文章所列的具体做法并不万能。
http://opengg.me/603/using-google-encrypted-search-freely/
