首先讲解一下这篇文字的背景。你看到的这篇文章其实已经写了很久了，不过在最近进行了一次大的改版。因为作者之前写这篇文字的时候并没有完全掌握https协议的精髓，只是记录下了https协议的一些知识点，虽然这期间作者也陆续增添了几次内容。直到作者前几天在听完某大佬分享了https协议，并产生了深深的自我怀疑——为什么有人可以随时把https建立连接的过程讲得那么清楚？这个过程明明很复杂啊！大佬当时给我的答案是：“那你就是没有真正理解！真正理解了是不会忘记的！”。于是，作者在大脑中深度思考了两天，并翻阅了所有能翻阅的资料后，终于把思路理顺了。。。
一、读完本文你将收获什么？
1、一张可以概括https建立连接过程的图，当别人询问你https相关知识时，你的脑海里只需要检索出这幅图就可以了。
2、区分几个看似很好理解，却很容易理解错，而要想掌握https协议又必须知道的密码学基础知识。比如，
（1）「密钥」、「密码」、「加密」这三者有什么关系？
（2）什么是「对称加密」和『非对称加密」?
（3）什么是「公钥」和「私钥」？
（4）什么是「数字签名」和「数字证书」？
3、「https协议建立连接」的过程和「建立TSL连接」的过程有什么关系？
4、https协议的精髓是什么？学会了什么，才算懂得https协议了？
接下来我们由浅入深逐步揭开https协议的神秘面纱。准备好跟作者一起探索https协议之旅了吗？let's go！！
二、HTTP协议有什么问题
- 如果你通过http协议访问一个网站，其所有内容都是明文传输。这意味着你的私人信息（用户名、密码）可能被别人看到。举个栗子，当你连接到wifi上，你和服务端通过http协议传输的任何内容都可以被其他连接到该wifi的用户看到。
- 如果你通过http协议访问一个网站，服务端返回的数据很可能被第三方篡改。举个栗子，当你看爱奇艺视频时，服务端本来发送给你的是“创造101”小姐姐的视频，可这视频可以被第三方截取，然后添加一段超级烂的广告再返回给你。
- 如果你通过http协议访问一个网站，服务端返回的数据很可能被掉包。举个栗子，当你想在淘宝买件衣服时，第三方可以截取淘宝返回的商品详情，直接给你换成亚马逊的某件衣服。
总之你通过http协议访问一个网站时，很可能就像下面这幅图一样。
总结一下，https协议存在以下三个问题：「窃听风险」、「篡改风险」、「冒充风险」。
而https协议的产生就是为了解决这三个问题。
三、HTTPS握手的整个过程
你要连接到https://github.com/colinNaive这个网站时，你看到的一切就只是你能看到的，你看不到的还有复杂的https握手的整个过程。
下图可以概括https握手的整个过程。这里可以先暂停一下，花几分钟时间仔细研究一下这张图。
https握手具体的步骤如下：
- 服务端生成一个公钥和一个私钥，然后把公钥发给CA进行认证。那么CA怎么认证的呢？CA自己也有一个公钥和一个私钥，它把自己的公钥内置到各大主流浏览器中，然后用自己的私钥来加密服务端发来的公钥，并把加密好的公钥返还给服务端。（严格意义上说，这一步还不是https握手的具体步骤之一，这一步是准备步骤，准备好了这一步才可以进行https握手）。
- 客户端请请求服务器发送建立连接消息，消息中包含支持的加密算法，使用的协议等。
- 服务器收到客户端支持的加密算法后，和自己支持的加密算法进行比对，如果不符合，就断开连接。否则，服务端对客户端回应一个消息，消息中包含：符合的加密算法、数字证书和数字签名。
- 客户端收到消息后，对证书的真伪进行验证。
- 验证通过之后，客户端会生成一个随机字符串，然后用服务端发来的公钥进行加密，这里就保证了只有服务端能够看到这个随机字符串。同样，客户端生成一个数字签名。
- 服务器接收到到随机秘钥，然后开始进行数据交换。
可能你对上面的步骤仍然存在疑惑，下面我们来一一为你解惑。
四、HTTPS协议简介
最初在作者浅薄的认识里，https协议是这样的——“https协议是更安全的http协议，它比http协议多了一个加密连接”。这个理解的后半句其实是含糊其辞的，不准确的。「加密连接」是什么鬼？到底是加密，还是连接？https协议到底比http协议多了什么？其实准备的说法应该是这样的：
- https协议比http协议多了加密传输（https协议中所有客户端与服务端之间通信的数据都是经过加密的）。
- https协议比http协议多了TSL连接（TSL连接保证了客户端与服务端建立了安全的连接）。
1、HTTPS是什么？
聊了这么多，https到底是什么呢？我们首先来看一张图。
最底层是Network层，上面是IP层，再上面是传输层，再往上看，是TLS层，然后是HTTP层。这就是https协议的整个层次图。也就是说，相比http协议，https协议在传输层之上多了一个TLS层，弄懂TLS层做了什么，就掌握了https协议的精髓。
总结一下，HTTPS协议是工作在TLS层上的HTTP协议，通过在传输层和HTTP层之间加入TLS层（Transport Layer Security）来「加密、认证、数据完整性保护」。这三个词你现在可能不是很理解，不用担心，读完本文你就可以理解这三个词的含义了。
不过，这里总结出一个公式：
HTTPS = 加密 + 认证 + 数据完整性保护 + HTTP
2、TLS协议是什么？
很多人理解中的https中的s就是SSL，殊不知，SSL已经在技术升级换代中被替代，替代SSL的就是TSL。TSL是SSL的现实版应用。我们来看看TSL是如何替代SSL的：
- 1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。
- 1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。
- 1996年，SSL 3.0版问世，得到大规模应用。
- 1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。
- 2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。
很明显TSL就是SSL的升级版。
为了能真正理解https协议，我们还必须弄懂以下几个概念
五、必须要弄懂的几个密码学基本概念
1、密钥、密码、加密
- 密钥是一种参数，它是在「明文转换为密文」或「密文转换为明文」的算法中输入的参数。
- 密码是一种特定的暗号或口令，常在个人取款或保密通信中用到。
- 加密包含算法和密钥两个元素。算法将密钥和密钥数据结合产生一个不易理解的密文。
我们说要对https协议传输的数据进行加密，那是怎么加密的呢？我们知道是通过密钥和算法，那么密钥和算法是不是都是保密的呢？答案是“No！”。要想搞清楚https加密的算法其实不难，最常用的加密算法也就那么几种，而这其中RSA加密算法是最普遍的。那么什么是保密的呢？是传入加密算法中的参数——密钥。
2、对称加密&非对称加密
- 对称加密，又称共享密钥。对称密钥在加密和解密的过程中使用的密钥是相同的，常见的对称加密算法有DES、3DES、AES、RC5、RC6。缺点是发送方和接收方需要协商共享同一把密钥，优点是计算速度快。
- 非对称加密，又称公开密钥。服务端会生成一对密钥，一个私钥保存在服务端，仅自己知道；另一个是公钥，可以发布供任何人使用。客户端通过公钥加密的明文，需要服务端用私钥解密。之所以称为不对称加密，是因为其加密和解密需要不同的密钥。
这里我们重点讲一下非对称加密。首先请思考一下这几个问题。
- 公钥加密，可以由公钥解密吗？
- 私钥加密，可以由私钥解密吗？
- 私钥是保存在客户端，还是保存在服务端？
公钥加密，只能由私钥解密；而私钥加密，只能由公钥解密。那如果公钥加密由公钥解密会解密出什么呢？答案是什么都解密不出来。我们可以简单的模拟一下，用AES算法加密，用DES算法解密。道理是相类似的。这里提供一个在线加解密测试网址：
http://tool.oschina.net/encrypt
在https协议中私钥是保存在服务端的，这一点比较容易搞错。因为离我们日常开发最近的能接触到公钥和私钥的是使用git时，配置git时私钥是保存在客户端，而公钥是保存在github上的，这和https协议是不同的。
3、数字签名
把服务端报文通过hash处理，得到摘要信息，然后再通过服务端私钥加密，就生成了一个数字签名。数字签名是用来验证传输的内容是不是真实服务器发送的数据，发送的数据有没有被篡改过。那么数字签名是怎么用来验证传输内容有没有被篡改过呢？下面我们来看一下验证过程：
- 第一步：服务端把报文经过hash处理，生成摘要信息（digest1），把这个摘要信息用私钥加密，得到一个数字签名。
- 第二步：当客户端接收到数据，把签名抽取出来，用公钥来解密。
- 第三步：客户端将报文提取出来做同样的hash处理，得到digest2，与digest1比较，如果相等则确认没有被篡改过。
这里为什么要清楚数字签名的概念？因为TSL层握手过程中，就要验证数据的完整性，这里就用到了数字签名。
这里总结两个公式：
摘要 = 报文 + hash
摘要 -> 服务端私钥进行加密 = 数字签名
4、数字证书
刚讲完了数字签名，怎么又冒出来了一个数字证书？作者是不是弄错了？数字证书是不是就是数字签名？数字证书跟数字签名是完全不同的两个存在，这里请不要搞混了。
数字证书的作用是：
- 证明“数据没有被掉包，确实是来自己客户端请求的服务器”。
- 把服务端生成的公钥顺利发送给客户端。
公钥为什么要发送给客户端呢？因为在客户端验证了“数据完整性”、“数据没有被掉包”后，会生成了随机数，这个随机数会发送给服务端，在服务端接收到该随机数后，客户端和服务端就会用该随机数进行对称加密。那怎么保证这个随机数能安全的到达服务端呢？就需要用公钥加密，然后服务端收到随机数后再用私钥解密。
向CA提交的证书申请文件如下：
这里总结一个公式：
服务端公钥 + 服务端基本信息 -> CA私钥 = 数字证书
六、总结
本文讲解了https的握手的完整过程。在开始写这篇文章之前，作者对于https的握手过程的认知是混乱的，经过几天的深度思考后，作者写下了这篇文章。这篇文章包含了作者的全部思考过程。当你看到这里时，作者已经把自己认为需要讲解的知识点都讲解了，如果你还有疑问，可以随时评论，作者会第一时间回复。
七、参考
https://www.cnblogs.com/ehcoo/p/6368304.html
https://blog.youkuaiyun.com/xiaofei0859/article/details/70747034
https://www.jianshu.com/p/33d0f8631f90
https://www.jianshu.com/p/b0b6b88fe9fe
https://jingyan.baidu.com/article/a3a3f811cb3e0d8da3eb8a5e.html
1423
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
