刨根问底系列之https究竟是如何防篡改的？面试必备

1.前言

https是一个老生常谈的话题了，也是面试过程种常常甚至必然会问到的一个问题 但当问到https为何安全的时候，不少人的回答就是简单的回一句：由于他加密了！而后就没而后了！你也至关于啥都没回答出来！

2.我为何要写这篇文章呢？

1.网上的文章有的不太全面或者不易懂，有的甚至理解有误差，有可能会给学习的人形成更多的疑惑

2.由于发文章有积分呀！

好，闲言少叙 进入正题

3.说https以前，先说一下http为何不安全，体如今哪里？怎么演示出来？

你们都知道，http是明文传输，可是也有很多人这样想：虽然是明文传输，但我也没遇到什么不安全的问题呀，因此我也不必搞https！

我只能给出如下几点解释

1.你很幸运，没被盯上

2.你的网站没啥流量，搞你没啥价值

3.你的帐号密码等隐私信息已经被窃取，而你依然浑然不知

接下来我给你们演示一下http为何不安全

你们都链接过公共wifi吧，这里我就用电脑开个热点，而后用手机链接热点，而后用手机访问一个http的登陆界面，并输入帐号密码登陆，我在电脑用wireshark抓包

第一步：电脑开启热点，并打开wireshark准备抓包

第二步：手机链接热点

第三步：手机访问登陆页并登陆

第四步：查看电脑抓的包

问题是否是很明白了，你的帐号密码都是明文传输的（密码是由于前端md5以后传的），中间的wifi（准确说是路由器）是直接能够截取查看的，能截取查看，是否是就能够篡改？答案固然是确定的

如今试想一下，若是你链接的wifi甚至你本地的运营商就有问题（为了利益），那他是否是就能够随心所欲了

好比:

1.窃取你的隐私信息

2.修改服务端返回的信息，加入一个js广告文件，此时广告就满天飞了

3.修改服务端返回信息，直接给你重定向到钓鱼或者广告网站，想想你有没有遇到过相似状况：你打开的百度，却跳转到了一个”你懂的“的网站

4.修改服务端返回信息，你忽然发现你平时访问的网站角落里忽然出现了个“特别吸引眼球的美女”

说到这，是否是足以说明http自己确实存在安全性问题。若是你的回答依然是否认的，建议多看几遍上面的内容，给本身洗洗脑！

4.https为何就安全了？他是怎么保证安全的？

想到安全，你们首先会想到，那就加密呗！因此引来第一个问题，如何加密 在介绍如何加密问题前，先简单介绍一下加密的大体种类

加密的大体种类：

1. 不可逆加密。 好比 MD五、SHA、HMAC

   典型用途： 密码总不能明文存到数据库吧，因此通常加密存起来，只要用户的输入通过一样的加密算法 对比一下就知道密码是否正确了，因此不必可逆

2. 可逆加密
   • 对称加密。好比：AES、DES、3DES、IDEA、RC四、RC五、RC6

     典型用途： 用同一个密码加密和解密，太常见了，我用密码加密文件发给你，你只能用个人密码才能解开

   • 非对称加密（就是公私钥）。好比：RSA、DSA、ECC

     典型用途： 1.加密（保证数据安全性）使用公钥加密，需使用私钥解密。 2.认证（用于身份判断）使用私钥签名，需使用公钥验证签名。

介绍完加密种类，接下来讲说如何加密

用不可逆加密可行吗？

首先不可逆加密的是否是能够直接排除了，不知道为啥的，能够想想本身的目的是什么哈，若是还不知道，能够打120了

用对称加密可行吗？

若是通讯双方都各自持有同一个密钥，且没有别人知道，这两方的通讯安全固然是能够被保证的,然而最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道,想想：是否是无论怎么传，中间都有可能被截获，密钥都被截获了，其余的安全是否是也就无从谈起了。看来纯粹的对称加密不能解决http的安全问题

用非对称加密（rsa）可行吗？

试想一下：若是服务器生成公私钥，而后把公钥明文给客户端（有问题，下面说），那客户端之后传数据用公钥加密，服务端用私钥解密就好了，这貌似能保证浏览器到服务端的通道是安全的，那服务端到浏览器的通道如何保证安全呢？

那既然一对公私钥能保证，那若是浏览器自己也生成一对公私钥匙，而后把公钥明文发给服务端，抛开明文传递公钥的问题，那之后是否是能够安全通讯了，的确能够！但https自己却不是这样作的，最主要的缘由是非对称加密很是耗时，特别是加密解密一些较大数据的时候有些力不从心，固然还有其余缘由。既然非对称加密很是耗时，那只能再考虑对称加密了

用非对称加密 + 对称加密可行吗？（行也得行，不行也得行，由于也没有其余方式了）

上面提到浏览器拥有服务器的公钥，那浏览器生成一个密钥，用服务器的公钥加密传给服务端，而后服务端和浏览器之后拿这个密钥以对称加密的方式通讯不就行了！完美！

因此接下来讲一下上面遗留的一个问题：服务端的公钥是明文传过去的，有可能致使什么问题呢？

若是服务端在把明文公钥传递给浏览器的时候，被黑客截获下来，而后把数据包中的公钥替换成本身伪造的公钥（固然他本身有本身的私钥），浏览器自己是不知道公钥真假的，因此浏览器仍是傻傻的按照以前的步骤，生成对称密钥，而后用假的公钥加密传递给服务端，这个时候，黑客截获到报文，而后用本身的私钥解密，拿到其中的对称密钥，而后再传给服务端，就这样神不知鬼不觉的，对称密钥被黑客截取，那之后的通讯其实就是也就全都暴露给黑客了。

卧槽，这也不行，那也不行，到底咋办？

淡定的考虑一下，上面的流程到底哪里存在问题，以至使黑客能够任意冒充服务端的公钥！ 其实根本缘由就是浏览器没法确认本身收到的公钥是否是网站本身的

如何保证浏览器收到的公钥必定是该网站的公钥

现实生活中，若是想证实某身份证号必定是小明的，怎么办？看身份证。这里国家机构起到了“公信”的做用，身份证是由它颁发的，它自己的权威能够对一我的的身份信息做出证实。互联网中能不能搞这么个公信机构呢？给网站颁发一个“身份证”？固然能够，这就是平时常常说的数字证书

什么是数字证书?证书都包含什么?

身份证之因此可信，是由于背后是国家，那数字证书如何才可信呢？这个时候找CA（Certificate Authority）机构。办身份证须要填写本身的各类信息，去CA机构申请证书须要什么呢？至少应该有如下几项吧

1. 网站域名
2. 证书持有者
3. 证书有效期
4. 证书颁发机构
5. 服务器公钥（最主要）
6. 接下来要说的签名时用的hash算法

那证书如何安全的送达给浏览器，如何防止被篡改呢？给证书盖个章（防伪标记）不就行了，这就又引出另一个概念：数字签名

什么是数字签名？签名的过程是什么

签名的过程其实也很简单

1. CA机构拥有非对称加密的私钥和公钥
2. CA对证书明文信息进行hash
3. 对hash后的值用私钥加密，获得数字签名

因此呢，总结一下：CA机构颁发的证书包含（证书内容的明文+签名）

浏览器收到服务下发的证书以后，拿到证书明文和签名，怎么验证是否篡改了呢？

你们知道，私钥签名，公钥验签。证书里面的签名是CA机构用私钥签名的，因此我只要用CA机构的公钥验证一下签名不就行了，怎么验证呢？

还记得证书里面的明文包含什么吧，不记得的话看看上面的内容。

1. 拿到证书里面明文的hash算法并对明文内容进行hash运算，获得A
2. 用CA的公钥解密签名获得B
3. 比较A 和 B，若是相等，说明没有被篡改，不然浏览器提示证书不可信

有没有发现一个问题？CA的公钥从哪里获取呢

这个简单，CA权威机构原本也没多少个，因此，浏览器内部都内置了各大CA机构的公钥信息

简单总结一下

1.若是证书被篡改，浏览器就提示不可信，终止通讯，若是验证经过，说明公钥没问题，必定没被篡改

2.公钥没被篡改，那浏览器生成的对称加密用的密钥用公钥加密发送给服务端，也只有服务端的私钥能解开，因此保证了 对称密钥不可能被截获，对称密钥没被截获，那双方的通讯就必定是安全的

3.黑客依然能够截获数据包，可是全都是通过对称加密的密钥加密的，他也能够篡改，只是没有任何意义了,黑客也不会作吃力不讨好的事了

结语

固然，https自己的加密流程比上面说的还要复杂一些，但主流程大体相同 下次面试再被问到https为何安全时，不要再简单的说 ”由于加密了“，这是一个很能体现能力的问题，不要浪费掉。 以上是我的的一些理解：我能自圆其说，但并不保证必定是对的，请读者自行诊断

几个问题

1. 为何charles等抓包工具或者浏览器控制台看到的https返回是明文的？
2. 为何制做数字签名时须要hash一次？

若是知道的话，能够留言讨论，不知道的话也可自行搜索，固然，你也能够关注我接下来的一篇刨根问底系列文章之https的详细握手过程，拜拜！