深刻理解HTTPS协议

为何须要深刻理解HTTPS协议

由于目前愈来愈多的网站或者app已经全面接入HTTPS，APPLE官方也建议APP全面使用HTTPS，况且国内这种节操都没有喜欢劫持网络请求的运营商在，没有HTTPS 实在是毁用户体验。多数人都是只知道HTTPS是基于HTTP的，有加密功能，但不知道这个是怎么实现的，相信我，做为一个开发者你之后始终会碰到HTTPS的相关问题，从源头弄懂这份协议颇有必要。

阅读本文须要什么基础

最好对HTTP协议有所了解，不须要太透彻，可是基本概念要知道。若是能懂一些TCP/IP 方面的东西就更好了。

阅读本文能有什么好处

本文能让还对HTTPS懵懵懂懂的你，完全从头至尾明白这份协议究竟是怎么一回事。太多的相关文章只告诉了你这份协议怎么作， 却没告诉你为何要这么作，以及验证这份协议究竟是不是真的这么作的一个探索的过程。

从Wireshark复习TCP三次握手的重要性

还不知道TCP三次握手的同窗，能够先自行搜索一下相关知识。这里为何要复习tcp三次握手，由于HTTP连接是在这之上的， 任何一个http连接，都须要tcp的三次握手的过程，https下面的加密层其实和这个有殊途同归之妙。何况经过此次复习，咱们还能学习下wireshark的相关知识。掌握wireshark对咱们弄懂HTTPS相当重要。 简单贴一下，tcp 三次握手的流程：

到这里，相信有基础的同窗应该都回忆起来这是怎么回事了。我不作过多解释，直接上工具wireshark。 咱们随便输入一个http的地址（注意不要访问https的，有些网站好比bat这种大网站你输入http也会直接转成https因此咱们仍是 随便选个小网站确保是http的）

而后明显能看出来是吧，有三次tcp的过程，而后才是http的连接。

细致分析下这个三次握手的过程：

第一次握手：主机A发送位码为syn＝1,随机产生seq number=0的数据包到服务器，主机B由SYN=1知道，A要求创建联机；

第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=0的包

第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则链接创建成功。

完成三次握手，主机A与主机B开始传送数据。

有的人可能会问，seq number不是随机number吗，你这里怎么都是0啊。

点开详细：

这里面告诉你了 是相对数字，方便你看。你固然能够选择看实际数字 加深理解

在这个里面把相对数字选项勾选掉，就能够看到真实的seq number了

怎么样这里是否是就豁然开朗了，固然明白就好，平时最好仍是勾选这个选项这样理解的快一点。

对称加密和非对称加密

这也是理解https的重要基础之一。这里涉及到不少复杂的算法，我并不精通算法和密码学，因此这里不讲的太细。大家只要知道个大概便可：

对称加密：加密和解密都用一个密钥，有点是速度快。缺点吗，显而易见的是 双方要用这个通讯的话 必须得把密钥告知对方， 可是这个密钥一旦被截获了，就能够随便decode出来明文。实际上不够安全。

非对称加密：有一对密钥，即有公钥也有私钥。公钥随便发，私钥不会发出去 各自保管。用一个加密的话，解密就只能用另一个。好比你向银行请求一个公钥，银行把公钥发给你，你用公钥加密一条信息之后 再发给银行，而后银行用私钥解密信息。这个过程就算有人拿到公钥，可是由于非对称加密用一个加密 只能用另一个解密，因此 拿到这公钥也没用，由于没法使用公钥解密，能解密的私钥还在银行那里，银行固然不会传出去，因此非对称加密很安全。 可是这种非对称加密很是消耗资源，速度极慢，因此要有限使用。不能无节制使用。

HASH加密算法：这个就好像MD5这样的加密方式，是不可逆的。

确保安全通讯的三个原则

A.数据内容的加密

这个很好理解是吧，敏感信息确定要加密的，明文传输等于自杀。不过多解释了。

B.通信双方的身份校验

这个不少人不理解，这是啥意思，按道理说咱们用非对称加密应该就完美了啊。可是谨记咱们的数据包不是从A直接到B的。 中间要通过无数次的路由器转发等等，这个中间一旦有人截获了咱们的数据包，换成本身的数据包，就很危险了。 因此咱们还须要一种机制能校验通信双方的身份。确保我是在和我老婆说话 而不是在我和丈母娘说话。

C.数据内容的完整性

这个也不是很容易理解，按道理说TCP是能保证数据有序完整的到达对方的。可是不要忘记中间咱们通过的无数次路由器转发， 可能被劫持，被劫持之后可能会对数据包进行篡改，这个时候咱们须要一种机制保护咱们的数据不被篡改，即便被篡改 也能被咱们察觉，确保我对我老婆写的信能完整的让我老婆看到，而不是只看到一半。

https的设计思路

根据前面咱们阐述的加密算法和安全通讯三原则，为了保证咱们的通讯可以安全进行，能够试想出一种流程来保证通讯安全：

• 服务器为每一个客户端生成一个公钥，将公钥发送给客户端
• 客户端选择一个加密算法，而后用公钥加密之后发送给服务器
• 服务器收到这个公钥加密后的算法之后拿本身的私钥解密，而后就知道这个加密算法是哪一个了。从此就一直用这个算法通讯。

目前来看，这个思路是否是很完美。公钥即便被中间人截获之后也没用，由于拿到公钥也解密不出来到底双方是用哪一种算法加密的。 但有个重大缺陷：

中间人能够将服务器发送的公钥包进行掉包，客户端怎么知道这个公钥是真的服务器发送的仍是假的中间人给的非法公钥呢？

能够看这张图，基本上中间人攻击就是这个图所示的意思。

解决中间人攻击问题

这个问题的解决办法其实也很粗暴：

• 使用权威的第三方机构也就是CA向安全的服务器颁发证书。来证实这台服务器的合法性。
• 服务器经过这个证书来把本身的公钥加密之后发给客户端
• 客户端收到这个加密后的公钥之后 ，就用第三方机构的公钥 把这个服务器返回的加密后的公钥 解密 从而获得真正的服务器 的公钥

带来的问题：

客户端到哪去取第三方公钥?

• 你的操做系统或者浏览器自身就带有权威机构的第三方公钥

• 若是中间人获得CA认证怎么办？这种状况基本没办法处理，若是发生，那么这个CA下面全部的证书都被认为非法了。因此 CA审核也很严格啊

CA证书是收费的啊，我不想交钱咋办呢

能够本身制做证书，而后把这个证书的公钥放在客户端（例如app的安装目录下），这样app只要使用本身的证书公钥便可 解密了，不须要使用系统的。可是这样带来的问题是，若是有人获取到了你这个公钥证书咋办？ 数字签名认证算法便可保证此类问题，其实简单来讲就是服务器和客户端事先约定好一种加密规则便可，就能够得知是否被篡改。 这部分因为不是重点，暂时不讲的太细，只要知道有这么个事便可。实际上你弄懂整个https之后这个地方就天然而然也能 想明白了。

有了上述基础，咱们终于能够按照科班的方式来理解HTTPS真正的流程

为何HTTPS的流程要放在最后再讲，由于放在前面讲，根本不会理解为啥要这么作，很快就会忘记。有了前面的基础 再来看这个流程，就会恍然大悟。

• 先看蓝色的部分，能够看出来，这是tcp连接。因此https的加密层也是在tcp之上的。

• 客户端首先发起clientHello消息。包含一个客户端随机生成的random1 数字，客户端支持的加密算法，以及SSL信息。

• 服务器收到客户端的clientHello消息之后，取出客户端法发来的random1数字，而且取出客户端发来的支持的加密算法， 而后选出一个加密算法，并生成一个随机数random2，发送给客户端serverhello

• 让客户端对服务器进行身份校验,服务端经过将本身的公钥经过数字证书的方式发送给客户端

• 客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证经过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 PreMaster Key。并将PreMaster Key发送到服务端,服务端经过私钥将PreMaster Key解密获取到Random3,此时客户端和服务器都持有三个随机数Random1 Random2 Random3,双方在经过这三个随即书生成一个对称加密的密钥.双方根据这三个随即数通过相同的算法生成一个密钥,而之后应用层传输的数据都使用这套密钥进行加密.

• Change Cipher Spec:告诉客户端之后的通信都使用这一套密钥来进行.

最后ApplicationData 所有使用对称加密的缘由就是非对称加密太卡，对称加密不影响性能。因此实际上也看的出来 HTTPS的真正目的就是保证对称加密的 密钥不被破解，不被替换，不被中间人攻击，若是发生了上述状况，那么HTTPS的加密 层也能获知，避免发生事故。

最后咱们用WireShark再来还原一次HTTPS的交互过程把

目标访问地址就用github吧。 抓出来是这样的。

注意看tlsv1的就能够了这个就是加密层。

下面就来逐步分析

• ClientHello

• severHello

注意到这里服务器和客户端就有2个随机数了。而且加密算法也肯定了。

• severHelloDone

这部分主要是发送证书信息的 点开之后 证书的详细信息都能看到 另外serverhellodone的意思就是服务器的工做都完毕了。

• 来看看第四步，客户端-->服务端 到底作了什么

能够看出来这里一共有三个步骤，咱们来依次分析 这三次动做都作了什么

Client Key Exchange

服务器收到这个random3的加密信息之后，用本身的私钥解密，这样服务器和客户端就共同拥有了random 123 3组随机数，而后用这三组数据生成一个密钥，这个密钥就是后面咱们applicationdata交互时使用的对称加密的密钥了

• 第五步 服务端-客户端

• 最后看看第六步也是最后一步，传输数据层。

  

new session ticket是啥意思

这个session ticket就是服务器最后一步的时候传给客户端的一个数据。 这个加密数据客户端收到之后就能够保存下来，这样下一次再请求https的 时候，就能够把这个session ticket发过去，这样能够省不少握手的时间和 资源消耗。（前面咱们分析的4-5步其实已经至关复杂了，尤为是非对称加密对服务端的资源消耗至关之大）

实际上对于多数浏览器来讲，指向同一个域名的https链接，咱们都会有意识的让第一个https链接完成握手以后再链接第n个 https。由于这样 后续的https 就能够携带相关信息，能够省不少资源

这个ticket实际上就有点相似cookie。

在笔者的此次访问chrome-gitub的过程当中，浏览器并无使用ticket技术 而是使用的seession id技术：

sessionid 实际上做用和ticket差很少，可是sessionid 没法作到服务器之间同步，毕竟id 存在服务器内存中，负载均衡带来的状态机同步是一个大问题。

总结

其实HTTPS总结起来就是3次tcp握手-5次TLS握手。搞清楚每一步作什么， 用的是对称加密仍是非对称加密，整个流程就确定能搞清楚了。 之后遇到相似的问题就能快速定位优化了。甚至抓取BAT的HTTPS接口 数据都不是难事。若是有须要的话你们就在下方留言，我会尽快 教你们如何抓取bat的https接口数据 而且decode出明文。