Linux相关概念和易错知识点（49）（HTTPS、数据摘要、SSL证书、ARP欺骗）

1、HTTPS

（1）HTTPS在协议栈的位置

HTTPS是一个应用层协议，是超文本传输的，这和HTTP一样。

在传输层之上，HTTP层之下有一个TLS、SSL层用于加密和解密，TLS、SSL仍在应用层。因此，HTTP层 -> TLS、SSL层 -> 运输层一般统称为HTTPS，HTTP -> 传输层就是HTTP。 注意现今SSL协议已被TLS取代，现在常说的SSL证书只是一种习惯。

HTTPS是一个分层式的解决方案，加密解密也是遵循协议的同层透明传输（上层对下层的操作无感知）。

（2）前4种设计方案的迭代

关于HTTPS的设计方法，我们需要通过介绍4种中间方案来进行迭代，通过建立思想、打破、再建立思想的方式，我们能够能够彻底理解HTTPS的原理。

①中间人攻击

我们的网络传输要经过运营商路由器转发，即数据必须走运营商的路由器，这就意味着如果运营商知道我们数据是什么，就能篡改它。

当我们获取下载链接时，运营商可以直接替换我们的下载链接 （运营商劫持），结果本来用户想要下载QQ，结果获取到的下载链接是微信的，我们点一下“下载”按钮就直接根据微信的下载链接下载到微信了，本质上这是运营商能看懂我们的数据导致的，我们需要对我们的数据进行加密，这样中间运营商就看不到具体内容，也不会被篡改，这就有了HTTPS。

通过运营商劫持攻击的方式就叫做中间人监听、篡改，即中间人称为设备传输数据的一个必经之路。成为中间人后用户基本感知不到被攻击。开热点、提供热点的设备就能成为中间人。

②对称加密通信（方案1）

对称加密（运算快），简单来说用什么加密就用什么解密，同一个密钥同时用作信息的加密和解密，就理解为开门和锁门的钥匙即可。 一把钥匙既可以开门也可以锁门，类似异或操作加密解密。

对称加密模式下，服务端和客户端拿着相同的对称密钥，可以对数据加密和解密。 但HTTPS通信不能只使用对称加密，客户端、服务端使用同一个密钥解析，但刚开始时一端生成密钥，始终要交换密钥给另一方，而密钥可能会被截获。那给密钥加密呢？那给密钥加密的密钥怎么办呢？这就陷入了死循环。

③非对称加密（方案2）

非对称加密（运算慢），这种加密方式需要两个密钥，一个公开密钥（公钥）一个私有密钥（私钥）。 公开密钥的意思是泄漏了无所谓，别人可以通过中间人攻击知道公开密钥。但私有密钥绝对不能让别人知道。公钥对明文加密变成密文，这个密文只能用私钥解密变成明文；也可私钥对明文加密变成密文，这个密文只能由公钥解密变成明文。 简单来说，一把钥匙加密后，就只能用另一把钥匙解密。 用公钥加密的密文，能解密的人非常少，因为对方需要持有私钥。用私钥加密的话，只有持有私钥的人才能加密，持有公钥的人都能看懂。

那么非对称加密是否可行呢？

服务器生成一对公钥和私钥，把公钥给客户端，服务器自己手上拿着私钥不传出去。 客户端用公钥加密给服务器，服务器用私钥解密。

这种方案下，公钥公开，即任何人都能拿到公钥，但只有服务器才能解密，因为私钥不公开，也就是其它人不可能知道我发给服务端的数据。 但后续服务器给客户端发消息，用私钥加密发给客户端时，需要用公钥解密，但拥有公钥的用户不止一个啊，中间人也能拿到公钥，可以监听。 因此在服务器生成公钥私钥的情况下，客户端到服务端安全，服务端到客户端不安全，即满足单向数据安全。并且非对称加密的运算速度慢，体验不好，客户端到服务端也不安全。

④双方均采用非对称加密（方案3）

客户端和服务端双方各自形成公钥私钥，一共4把钥匙。 通信开始前，双方进行公钥交换，即客户端交给服务端自己的公钥，留着私钥；同理服务端交出自己的公钥，保留自己的私钥，双方知道对方的公钥，但双方的私钥不交换。

因此交换后我们可以采用如下的通信方式：

客户端数据 + 服务器的公钥 -> 只有服务器拿着自己的私钥才能解密。
服务端数据 + 客户端的公钥 -> 只有客户端拿着自己的私钥才能解密。

从上述过程中我们知道，通信过程中，全程都是用对方一开始就交换过来的公钥在加密数据，将数据传输过去之后，对方用自己保留的私钥解密数据，这个时候双方通信都是安全的。

但这种方案其实并不提倡，为什么？非对称加密运算慢，每次通信都用非对称加密的话，效率太低！

⑤ 非对称加密 + 对称加密（方案4）

其实我们不需要双方都采用非对称加密。通过前面的方案，我们知道：服务器生成公钥私钥只能保证客户端 -> 服务端的安全通信；对称加密需要由一方生成密钥，并且在一方交换给另一方时存在安全问题。 我们何不结合一下呢？

服务器先形成公钥私钥，然后把公钥交给客户端，保留私钥。客户端拿到服务器生成的公钥后会再生成一个对称密钥X，将X用公钥加密的数据交给服务端，这个公钥加密的数据只有服务端的私钥能解密，能解密出真实内容X，所以没有中间人能够知道X具体是什么，于是对称密钥就是安全可靠的。

既然对称密钥安全了，那从此双方就完全可以采用对称加密传输数据，对称密钥X只有客户端和服务端知道。采用这种策略在保证安全的情况下能够解决方案4的效率问题（对称加密运算快）。

因此，我们可以认为方案4是上述所有方案中最安全的，这也意味着，只要方案4出现漏洞，前面3种方案不攻自破。问题是，方案4真的存在漏洞！

（3）中间人最后的攻击手段

①数据篡改过程

我们上述的安全性的讨论都基于一个事实，就是中间人只会窃听我们的数据，即它能够知道我们双方所有的通信数据。在这种情况下，就算中间人知道客户端和服务端通信的所有的数据，方案4也能保证安全可靠。但是，中间人还可以篡改数据！

首先，中间人一定在双方通信的路径中，这是中间人的定义。其次，这个中间人必须在双方开始通信前就已经做好准备。 满足这两个条件，中间人它能借助数据篡改破解方案4。

在通信前，中间人就已经准备好了一个公钥和私钥，当采用非对称加密 + 对称加密时：首先，服务端发送自己的公钥给客户端，但这个公钥数据一定会经过中间人，并且一定需要中间人来转发。中间人拿到了服务器的公钥之后，中间人把自己最开始准备好的公钥继续发给客户端，并把真实的服务器的公钥藏起来。客户端收到数据后，客户端以为自己拿到了服务端的公钥，但实际上拿到的是中间人生成的公钥。

然后，客户端会生成对称密钥X，并用中间人的公钥加密发送出去，结果就被中间人看到并解密得到X了。

但中间人不想让双方知道自己被监听了。于是，中间人拿着曾经劫持的服务器的公钥继续加密X并发送给服务器，服务器拿着私钥解密得到X，而服务器天真地觉得这是客户端发送过来的。

最后，客户端和服务端都用密钥X进行对称加密通信。 客户端和服务端都觉得世界上只有两个人知道X，但实际上中间人也是知道X的，双方的通信内容都被监视了，并且客户端和服务端还发现不了，因为双方都能正常通信。 于是前4种方案全部都被攻破了！

②问题分析

看似中间人完全打破了前面的方案，但其实中间人只有在双方交换密钥时才有机会攻破，仅这一次机会。因此，只要客户端知道自己收到的公钥是否合法，只要发现这个公钥是中间人伪装的，那么中间人将再无可乘之机。

这里有个误区，既然客户端可以通过判断自己收到的公钥是否合法来反制中间人，那么对于中间人来说，是否可以通过不篡改数据来实现监听呢？

不可能！ 中间人要实现监听，就必须替换服务器的公钥，因为服务器公钥加密的数据只有服务器的私钥才能解密，如果中间人仅仅获取公钥但不替换的话，后续客户端发的消息也只有服务端能看懂，你中间人连看都看不懂，又谈什么监听呢？所以对于中间人来说，要想监听，就一定得替换服务器的公钥。

所以接下来只要保证客户端拿到的服务器公钥合法，中间人就彻底无法攻击了。

（4）解决数据篡改问题

①数据摘要（数据指纹、hash摘要）

数据摘要（指纹），指的是利用单向散列函数（Hash函数）对一段信息进行运算，得到固定长度的数字摘要。 简单来说，就是给你一段数据（无论这段数据有多少），经过数据摘要后，就会得到固定长度的字符串。

因此，我们可以对文章文本进行hash摘要，得到固定长度的字符串。 由于hash不可逆的特性，你不能通过数据在哈希表的位置逆推key，这就意味着hash摘要这种算法可以加密，但没有解密方法。所以hash摘要其实不是加密机制，而是判断数据有没有被篡改的一个算法，篡改了的数据经过hash摘要后和原始数据的hash摘要一定不同，就算只有一个很小的改动，hash摘要都会有很大的区别。

②从hash摘要理解一些生活中的应用

a.秒传

对于某些品牌的网盘来说存在妙传功能。用户上传到网盘的数据会进行hash摘要并保存起来，所以网盘提供商那里有海量的摘要。 当有其它用户要上传数据时，用户本地会先对数据进行hash摘要，并先将摘要数据传过去，提供商拿着我们的摘要到其数据库中去找对应的hash值，如果找到了，意味着这个资源没必要传了，因为有一份相同的数据已经在网盘上了，服务器那边直接关联一份即可，就不需要用户传了。

b.重设密码不能与原密码重复

登录时，服务器收到我们的用户名和密码，并到数据库查找比对，但数据库真的会明文保存我们的密码信息吗？ 我们要考虑数据库信息被泄漏的风险，所以注册用户时，数据库保存的是密码的hash摘要（用户名也可以摘要）。后续用户登录时，就先对输入的密码进行同样的hash摘要，然后上传摘要，比对数据库里面的摘要，只要密码输对了，摘要就一定匹配，这个时候就提示密码成功。

这个时候我们就能理解账号找回密码时都是让我们重新设置密码而非直接告诉我们密码，因为hash摘要不可逆的特性，服务器从始至终不知道我们的密码究竟长什么样，它只知道其hash摘要的样子。 并且我们还会发现，重新设置密码时会提示不可设置之前设置过的密码，这个时候很多人就会觉得，你服务器知道我的密码为什么不告诉我？实际上是我们重设的密码的hash摘要和之前的密码的hash摘要匹配了，服务器仍不知道，也不存储我们的密码。

③数据签名

数据签名，就是把hash摘要用私钥进行进一步加密，加密后的数据就是数据签名。 例如，我们将一段数据hash摘要得到长度固定的数据指纹，之后签名者（可以是机构，有自己的公钥、私钥）用私钥加密这个hash摘要，然后就能得到该机构的数据签名。我们把这个数据签名和原数据拼起来，就得到了数字签名的数据。

这个东西有什么用？验证原始数据有没有被篡改！

当我们拿到有数字签名的数据时，我们需要将有效数据和数据签名分开，对有效数据做hash摘要得到A，并且将数据签名用签名者的公钥解密得到B，比对A和B，我们就可以判断原始数据有没有被修改。 为什么？数据签名就是对有效数据的hash摘要用签名者的私钥加密的，我们用签名者的公钥解开自然就是hash摘要了。如果没有篡改，两者应该是一样的。

但问题还非常多，为什么要用签名者的私钥加密hash摘要呢？

因为这是对hash摘要的保护。 一段数据，在没有篡改的情况下交给了签名者，其hash摘要被签名者提取，用私钥加密后，就再也没有人能够篡改这个hash摘要了。为什么？这意味着什么？中间人攻击怎么办？

一份数据的hash摘要是，经过签名者的私钥加密得到数据签名，有效数据 + 数据签名拼接成了一份含数据签名的数据。 如果中间人想要去替换有效数据，那就必须要伪装成签名者签名，因为如果不伪装签名，会被一眼识破。 这个时候，中间人就面临一个难题，它篡改了有效数据，并且这段篡改后的数据的hash摘要是M 。那中间人还需要伪装一个签名N，这个签名N经过原签名者的公钥的解密之后可以得到Ｍ。 中间人不可能知道这个签名长什么样！只有拥有签名者的私钥才能做到，但中间人怎么可能知道私钥呢？

所以，由于数据签名无法被伪造，只要有效数据被篡改，对方只需要用签名者公钥对签名解密，比对有效数据的hash摘要，就能马上判断出来。

为什么数据签名不直接对明文加密而是对hash摘要加密？

理论上可行，但考虑到明文的数据大小不一，对摘要签名的效率话可控。

④CA机构和SSL证书

签名者拥有一个权力：只有我才有对数据进行签名的权力。为什么？因为别人都会认可我的公钥，都会用我的公钥来解密签名得到hash摘要，再进行比对。换句话说，谁持有大家都认可的公钥对应的私钥，谁就可以签名！

这个签名者就是CA机构。CA机构拥有签发证书的权力。所有人都认CA机构的公钥。CA机构是一个组织，有不同子公司。

所以，服务器要上线HTTPS，就需要拿着域名、注册者的身份信息、公司信息、用途等信息向CA机构申请证书。 该流程是：首先服务端内部生成一个公钥、私钥。之后，服务器将域名、申请者、服务器的公钥等信息写进一个请求文件.csr中，并将这个文件发给CA机构，CA机构审核通过之后，会将我们的请求信息做数据签名，并将带数据签名的数据返回给服务端，这个返回的数据就是SSL证书。

服务器拿着SSL证书，需要安装到服务器上。这个证书里面的签发机构、证书有效时间、网站域名、公钥等信息都是明文保存的，为什么这么大胆？有数据签名，中间人无法篡改。

在对称加密 + 非对称加密的通信建立过程中，当客户端拿到服务端的公钥时，实际上客户端拿到的就是上述的服务器申请到的SSL证书（很多行数据）。这个证书里面有签发机构、证书有效时间、网站域名、公钥（就是前面说的客户端拿到的服务端的公钥，客户端最关心的）等。 其中，客户端收到证书后会对它的数据签名做验证，验证通过后证明数据一定没有被篡改，这就验证了服务端的公钥的安全性，没有被中间人篡改。

所以说，一旦服务端上传申请信息，从CA机构签名的那一刻起，这个证书的内容再也无法被改变，中间人无法篡改，服务端也不能改，安全性得到了极大的保障。

那这个时候中间人就想：我既然没办法修改证书了，我直接替换整个证书。中间人先向CA机构申请一个证书，随后整个替代服务端的证书，可行吗？不可行，只要CA机构签名，说明其证书信息的完全可靠。那么中间人的信息、假网站域名等信息将一览无余。

由此一来，中间人再也无法篡改服务端的公钥了，其攻击链被彻底防御了！

（5）整体流程

在搭建HTTPS服务之前，服务器就需要拿着自己的域名、公钥、申请者向CA机构申请证书，CA机构进行签名后返回证书，证书中携带有效日期、签发机构、申请者、服务器的公钥、域名、拓展信息。并且这个证书任何人都不能篡改，包括服务端。

之后服务器就可以上线服务了，服务器给客户端传输的是携带公钥的证书，客户端会根据数字签名验证公钥的合法性，比较明文数据的hash摘要和用CA的公钥解密数字签名的解密数据，如果合法就提取公钥 （所有客户端都会内置受信任的CA机构及其授权的子机构的公钥）。

提取合法公钥之后，客户端就会生成对称密钥X，并用证书中的可信的服务端公钥加密X，之后发给服务器，服务器用自己的私钥解密得到对称密钥X。之后双方通信就基于对称加密来进行。

（6）ARP欺骗

HTTPS中我们了解了如何防止被中间人攻击。成为中间人的话主要有以下方式：ARP欺骗、ICMP攻击、假wifi、假网站等。 稍微介绍下ARP欺骗。

主机ARP缓存之后，得到了IP和mac映射的表。 现在来了个新主机N，它想变成中间人，这个主机N就会构建大量的假的ARP应答，在应答中说我的IP地址是X，mac地址是Y。这些假的ARP应答中mac地址Y就是指向这个新主机N。。

对于一台主机而言，如果持续收到大量arp应答，主机就会认为是对方的信息更新了，就会使用最新的arp映射关系， 所以很多主机就被欺骗了，这些主机所更新的新的映射关系中，目的mac变成了那台一直伪造ARP应答的主机N，于是那台主机N就变成了中间人。

成为中间人，要学会两方都骗！ 中间人主机也能知道被骗的主机的IP、mac帧，进而伪装成被骗主机向真正的目标主机发消息，这样就没办法发现了。 在全程伪造的arp应答中，mac地址是指向自己的，而IP则是想要监听的主机的，最后，在双方都被骗的情况下，中间人会进行转发，而主机始终觉得是在互相通信。

这种中间人攻击的方式是ARP欺骗！