最新消息:

为何我们不能正常使用Google加密搜索(转)

软件技巧 大步 695浏览 0评论

生活在此处,你永远也不知道自己身边在发生些什么。作为饮水思源BBS Google板的板主,我常常看到有人抱怨Google被重置,Gmail不稳定。这种情况必然事出有因,这种反馈却常常语焉不详。我能理解用户这种被误导被愚弄的滋味,但在信息量不足以支持判断的情况下,我只能是爱莫能助。

为了让自己好受些,我常安慰自己:何苦让这些人的无知折磨自己。但在我内心深处,我却知道事实并非如此:技术的成果不能为民众共享,却反而要民众为技术所禁锢,谁又该为这些人的不公正待遇负责?

这种心情别人很难理解。

我以Google加密搜索为例,说明在遇到问题时该如何发问和解决。

 

发现问题

如果你身在此处,那么你多半不能正常使用Google加密搜索

如何提问

在正式提问之前,让我们先问问自己,该如何提问?

提出的技术问题能否得到正确的解答,很大程度上取决于提问的方式与问题的难度。而问题得不到解决,提问者应该扪心自问,自己是否问错了人,或者问错了问题,或者是否展示出了相当的提问的诚意?

建议读者阅读 < 提问的智慧> 一文,此文列举了提问者常犯的一些错误,避免这些错误可以更好地得到解答。读完此文,你也就能理解,为何stackoverflow 能如此受技术宅欢迎。

搜集线索

此时你应尽可能多地搜集线索。在搜集线索的过程中,有可能你自己就解决了问题;就算你自己解决不了,线索也能为他人提供信息。要知道,大侦探福尔摩斯离开了线索也不能破案。如果有人不依靠线索就能解答你的疑问,这如同医生不把脉就开药方,你最好不要相信这种人。

但是在搜集线索的同时,要注意筛选线索。这几天我遇到一个愚蠢的问题,标题是“为什么电脑突然不能访问ftp了?”,内容除了一堆废话之外,只有下面这张图。请注意,这张图片什么也说明不了!

为何我们不能正常使用Google加密搜索(转) - ksharp_dabu - ksharp_dabu的博客

 

回到我们的问题,在使用Google加密搜索的过程中遇到问题,该如何搜集线索呢。在这个例子里,浏览器自带的开发工具并没有给我们更多的提示(快捷键F12可以唤出浏览器的开发工具,通常情况下这是很好的发现和解决问题的工具)。

我们使用wget来代替浏览器,看看在访问Google加密搜索时发生了什么问题。安装wget后在命令行中输入

1
wget https://encrypted.google.com/ --no-check-certificate -O -

我们看到这样的结果:

为何我们不能正常使用Google加密搜索(转) - ksharp_dabu - ksharp_dabu的博客

 

可以看到,浏览器试图访问两个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,说明这些包并不来自同一服务器。

为何我们不能正常使用Google加密搜索(转) - ksharp_dabu - ksharp_dabu的博客

 

再对TCP协议的DNS查询进行抓包,服务器返回的包TTL均为41,说明这些包来自同一服务器。

为何我们不能正常使用Google加密搜索(转) - ksharp_dabu - ksharp_dabu的博客

 

至 此,我们已经分析出了原因:有人在针对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:WindowsSystem32driversetchosts文件,加入一行

1
2
74.125.235.111 encrypted.google.com
#74.125.235.111替换为你查询到的Google ip

保存hosts

此时在浏览器中应该能打开Google加密搜索了。

如果遇到Google加密搜索自动跳转到无加密搜索,你可能需要先访问http://google.com/ncr ,去除自动跳转(ncr是 no country redirect的缩写)。

至此,我们搞清楚了不能正常使用Google加密搜索的原因,和相应的解决方法。但我这篇文章的意义仍然在于传授一种分析和解决问题的思想,这篇文章所列的具体做法并不万能。

转载请注明以下信息
文章转载自:鲁夫的爱 [ http://opengg.me/ ]
本文标题:为何我们不能正常使用Google加密搜索
本文地址:http://opengg.me/603/using-google-encrypted-search-freely/

转载请注明:大步's Blog » 为何我们不能正常使用Google加密搜索(转)

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
SiteMap