上一篇文章谈了下开放式网络的危险性，实际上在开放式网络中很危险的地方就在以DNS劫持的方式来达到钓鱼的目的——尤其是对那些安全性意识很差的人来说。有的童鞋可能会收到"您有1000积分可兑换100元话费，请点击http://jf.l0086.cn进行兑换"，于是果断点击结果被骗。所以这篇文章主要就来说说钓鱼网站的那些事。

在说钓鱼网站之前，我们首先要了解一下几个非常基础的概念：IP、域名、DNS。之后我们会说说当你在浏览器地址栏输入网址并按回车的时候发生了什么。

IP

互联网协议地址（Internet Protocol Address），缩写为IP地址（IP Address），是分配给网络上使用网际协议的设备的数字标签。常见的IP地址分为IPv4与IPv6两大类。

212.41.1.74就是一个合法的IPv4地址。

IPv4是一个32位的地址，每8位使用一个点来进行分隔，我们人类通常使用点分十进制将11111111.11111111.11111111.11111111转化为255.255.255.255，甚至是使用CIDR表示法来表示一个IP段。

IP地址就好似门牌号，对于人类来说不太好记，对于机器来说当然没问题啦！谁也不会输入220.181.112.244来访问百度吧？

于是人类就发明了一种可以把易于记住的字符串转换成对应的IP的东西，叫做DNS

域名

所谓域名，简单理解，就是你在浏览器地址栏看到的以http://或者https://开头的一串比较好记的英文字符串（不包括http://、https://）。

这里dmesg.app即是一个域名

其中最后的com被称为TLD（Top Level Domain）

TLD一般分为两种：

国家和地区顶级域名（Country code top-level domain，ccTLD）：简而言之，cn就是ccTLD

通用顶级域（Generic top-level domain，gTLD）： com就是gTLD

DNS

域名系统（英文：Domain Name System，缩写：DNS）是因特网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。

DNS使用TCP或者UDP的53号端口，通常人们默认都会使用UDP 53.因为UDP是无连接的协议，你敢想象下查询个域名还需要三次握手这么麻烦费时吗？

那么从域名到IP这个转化过程是由DNS完成的，这个过程具体是怎样的呢？我们简要的来说下。

1. 在浏览器中输入网址或者点击超链接，浏览器会先提取出来域名，比如说www.qq.com。浏览器首先会在自己的缓存中查找是否有该域名对应的IP地址，如果有，就先调用这个IP地址映射，完成域名解析。

2. 如果浏览器缓存中没有这个域名的映射，就去查找hosts，如果有，就先调用这个IP地址映射，完成域名解析。

3. 如果hosts与浏览器缓存都没查到，那就要向系统设置的DNS发送查询请求（通常这个DNS是ISP提供的DNS或者是阿里DNS等公共DNS），我们暂时称这个服务器为ISP DNS。ISP DNS服务器首先检查自身缓存，如果存在记录则直接返回结果。

4. 如果以上操作均失败，ISP DNS会在配置文件找到13组根服务器的地址，并向根域名服务器发送查询报文query www.qq.com。根域名服务器返回.com域的权威域名服务器地址，这一级首先会返回的是顶级域名的权威域名服务器。

5. ISP DNS服务器向.com域的权威域名服务器发送查询报文query www.qq.com，得到.qq.com域的权威域名服务器地址。

6.ISP DNS服务器向.qq.com域的权威域名服务器发送查询报文query www.qq.com，得到主机www的A记录，存入自身缓存并返回给客户端。

如果有点懵逼的话，你就这么想，ISP DNS是个跑腿的，假如他的缓存里没有你要解析的域名，他就去找rootDNS，rootDNS再踢皮球让他去找对应顶级域的DNS，然后再踢皮球…最终找到了真正的IP，返回并记入缓存。

想想如果DNS全都挂掉了，大家不仅仅要打IP地址上网了，各种商业交易也会完蛋，连微信都聊不了哎——实际情况非常糟糕，这大概就会是互联网和整个世界的末日。

在你敲回车时，都发生了些什么

在了解了DNS解析的过程之后，我们来说下，当你在地址栏输入一个网址并敲回车之后，究竟发生了些什么呢。假如说，你是第一次在Chrome的地址栏中输入dmesg.app吧！我猜没有几个人会输入带http、https的吧！

1. 首先根据输入的网址，提取出域名（在本例中，也就是dmesg.app）

2. 根据上面"DNS解析过程"解析出正确的IP地址。

3. 浏览器就会向这个 IP地 址 对应的 Web 端口（一般也就是80）发送 HTTP Get请求。

对于一没开HTTPS的网站来说，这就是完整的过程了，只要缓存没过期，每一次都遵循这个过程。但是…对待HTTPS的网站，要额外多出来一些步骤。

4. 服务器发送https://dmesg.app的301重定向给浏览器，浏览器向带https的443端口发起请求，开始验证证书、密钥交换等等

5. 在HTTPS建立之后，服务器会发送对应的响应报文，有些还会加上一个Strict-Transport-Security响应头。

在我的博客中，当你第二次访问dmesg.app时，除了DNS解析过程还是一样之外，请求的时候就变得不同了....

• 在接下来的一段时间内（我设置的是63072000秒，即两年），浏览器只要向bennythink.com或其子域名发送HTTP请求时，必须采用HTTPS来发起连接。比如，用户点击超链接或在地址栏输入 http://dmesg.app/ ，浏览器应当自动将 http 转写成 https，然后直接向 https://dmesg.app/ 发送请求。
• 在接下来的两年中，如果 bennythink.com 服务器发送的TLS证书无效，用户不能忽略浏览器警告继续访问网站。

当你遇到钓鱼网站时……

迷惑人的字符

我们回到文章最开始，我列举了一个中国移动积分商城的例子，如果你瞪大眼睛瞅一瞅，你会发现是l0086而不是10086（字母L和数字1）如果l0086这个网站存在并且做的和10086一样，那么你的服务密码不就跟你说拜拜啦！

相应的，有几个字符在某些非等宽字体下看起来非常相似，1、I、l，0、O、o，如果骇客恰巧注册到了这样的域名——或者是开放式网络中通过DNS劫持，轻轻松松骗起人嘛。

不同编程字体下的1Il0Oo，从左到右依次为Source Code Pro、Ubuntu Mono、Monaco、DejaVu Sans Mono

在word里用调成微软雅黑看看这个六个字符，几乎分不清的好嘛！Android的Droid Sans也一个样…

不可信的域名

有人可能会说，那我瞪大眼睛看清楚了网址（域名），确保是真正的网站而不是山寨的，不就行了嘛？这种想法，要分情况讨论，对应http的，其实是大错特错。原因在于，域名系统本身就是不可靠的！回想一下DNS解析的过程，好像DNS服务器都有个缓存哎 。这是为了提高查询效率的，先看看自己的缓存里有没有，没有了再往上一级去问。缓存是存在一定时间的时效性的，可能是几分钟也可能是几小时，缓存里的某条记录如果过期了，就会被删除。

你有没有想过，假如有人故意配置错了域名和IP的配置关系呢？假如从源头开始这个对应的映射关系就是错误的呢？假如有人抢在真正的域名服务器应答之前"抢答"了呢？（正是因为UDP协议才可以"抢答"，但是哪怕人们使用TCP的DNS，中间人也依旧可以使用RST来中断连接。可靠的办法是使用DNSCrypt加密查询请求）

这也就是针对DNS的攻击方法，常见的有DNS劫持和DNS污染

不知道有没有遇见或者听说过打开网页蹦到了什么"互联星空"，或者是下载什么软件被替换成了其他的东西，这些都属于劫持。

值得信任的https

在说废话之前，先说下结论：在理想状态下，HTTPS是可以相信的。

理想状态？没错理想状态，In theory, there is no difference between theory and practice. But, in practice, there is.

带着小锁头是指使用了HTTPS的网站，在Chrome中显示为绿色的小锁头，有些可能还会带有Certificate Transparency

在解释这个问题之前，我们首先想一想，为什么说HTTP是不安全的？

一是HTTP可以被嗅探、监听；二是HTTP可以被中间人劫持并且双方不会感觉到任何异常。

应对第一个问题，我们可以通过一种办法来使得客户端和服务器协商出来一个只有他俩知道的密钥来对通信进行加密，这样即使被窃听、被篡改也无所谓，通常我们会使用混合密码体系、Diffie-Hellman密钥交换算法来达到这个目的；

《你的灯亮着吗？发现问题的真正来源》里说过一句话：每一个解决方案都是下一个问题的来源。在应对"HTTP不安全"的第一个问题时，我们成功解决了被窃听、篡改的问题，但是随之而来我们引发了一个更严重的问题：被中间人劫持该怎么办？

再想想怎么应对中间人劫持之前，我们首先想一想问题的来源和本质：为什么我们能被悄无声息的中间人劫持？

想

几

分

钟

试

试

缺乏有效的身份认证机制是使得中间人劫持发生的根本原因。

为此，人们采取的方法是引入第三方认证机构构建PKI。

https不完全可靠的原因

垃圾浏览器警告证书错误处理不当

有些浏览器，比如说"360安全浏览器"在遇到证书错误，用户选择继续之后，地址栏竟然提示用户安全，所谓"安全浏览器"就是这么安全的？

牛逼啊，原来 360 觉得在中国很多网站用的是过期证书和自签名证书，所以 360 浏览器「为了提升用户体验」就可以在在遇到证书错误的时候默认依然载入页面。你们 360 安全浏览器真是太懂安全了。 https://t.co/lRyLC0IA9F

— multiple1902 (@multiple1902) April 2, 2015

小白用户忽略证书警告

很多小白用户不知道什么是https，不晓得加了那个s意味着什么，当然也不理解证书是怎么回事了。既然可以继续，那干嘛不继续呢？于是就被中间人劫持了。

国家级发动的利用CA的中间人劫持（WoSign、CNNIC、12306）

这种事情确实发生过，戳、戳

当一个合法的CA配合GFW进行中间人劫持时，任何浏览器都不会给用户警告。当然这种事情，一旦发现，绝对妥妥的不会再有任何浏览器信任它签发的证书。

除了用合法的CA签发证书，某些国家也可以利用行政力量强制每台电脑安装根证书，比如说哈萨克斯坦依法安装国家安全证书，还有天朝12306的那个SRCA根证书……我向来不惮以最大的恶意来揣测党国。

CA错误签发证书、CA被黑

CA的一些失误，比如说本应该签发子域名、却给了裸域的泛域名证书，CA被黑导致私钥泄露，同样也会危害https安全性。 

HTTPS降级攻击

在前面说"敲回车发生了什么的时候"，我们提到了这个问题。人们在浏览器输入网址时，或者是点击别的地方的超链接时，很少会有人打带着https开头的，所以通常是由服务器发送给浏览器一个301重定向到https的响应报文，浏览器再去访问这个新的url，验证证书、密钥交换。在这个重定向的过程中就出现了一个问题，服务器给浏览器的重定向响应报文必然是http的，因为此时还没有协商密钥呢——假如此时的响应报文被劫持，那重定向到什么地方都是可能的！
原本安全的https就这样被"降级"成了不安全的http，甚至是被重定向到别的网站！随后，人们搞了个HSTS（HTTP Strict Transport Security），服务器可选加入这样子的一个响应头：

Strict-Transport-Security max-age=63072000; includeSubDomains; preload

在63072000秒内浏览器必须使用https访问该网站，并且不允许忽略证书错误。

但是这个也要求你最起码成功的https访问了一次……还是没能彻底的解决问题。

于是Google站出来维护了一个HSTS Preload List，某个域名只要成功加入了这个Preload List，在几个月之后，这项信息就会被"硬编码"到浏览器中，浏览器就会一直对该域名使用HTTPS。麻麻再也不担心我被降级攻击了

网站使用了不安全的cipher suite或者协议、TLS爆出漏洞

众所周知SSLv3、心脏流血（heartbleed）

Mixed Content

所谓Mixed Content是指网页是https的，但是加载了一些不安全的http的资源，比如图片、音乐、form表单甚至是js等危险资源。由于这些是非https的，所以可以被替换成其他资源，导致网页外观发生变化。当这种情况发生的时候，绿锁头就消失啦！而js等危险资源默认不会被浏览器加载。很多从http迁移到https的博主们都会苦恼于Mixed Content吧。

总结

好像这篇文章都在谈着阳春白雪的技术…从钓鱼网站里想到的一些问题。大概没有涉及到怎么防骗吧。那就总结下，钓鱼的主要形式：

中奖积分等短信、留言诱骗或是美女等...用户点击链接，跳转到钓鱼网站、或者是下载吸费应用。

1. 注意1、I、l，0、O、o等看起来非常相近的字符；
2. http开头的网址不可靠、不值得相信。
3. https开头的网址，大部分情况下是可以相信的；
4. Android机尽量关闭未知源，或者不随意安装apk。

其实啊一句话，别贪小便宜呐。贪小便宜吃大亏呀~

回到本系列目录