1、概述
互联网上进行的任何活动（阅读本文，朋友圈上传图片，在淘宝上买东西）都可以归结为向服务器发送消息和从服务器接收消息。而两者之间传递消息就需要遵守一些协议，不然的话就如同鸡同鸭讲，根本没法进行沟通。其中在应用层用的最多的就是HTTP协议（HyperText Transfer Protocol，超文本传输协议）。而HTTP协议传输的数据没有进行过任何加密操作，基本上就相当于在网上裸奔。于是在HTTP协议的基础上，出了一个HTTPS协议（HyperText Transfer Protocol over Secure Socket Layer）。可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL/TLS，加密的处理就需要 SSL/TLS，用于安全的 HTTP 数据传输。
2、类比解释HTTPS原理及诞生过程
2.1 开始天真的沟通
我们这边有一群小甲和一个小乙，小甲们是小乙的粉丝，而当时只能通过飞鸽传书来传递小甲们对小乙的喜爱之情。一开始是这样的，每次小甲们想要想给小乙传信件的时候，就把信件绑在信鸽腿上，通过信鸽飞到小乙那边，小乙从信鸽腿上去下信件读取消息，然后根据信件里的发件人和地址用同样的方式回信件给小甲们。
直到有一天，有个叫小坏的人，在信鸽飞行的途中，把信鸽拦截了下来，偷偷看了里面的信件，甚至还修改了信件里面的内容，再把信鸽放走让它继续往目的地飞过去。这个操作有天被小甲们和小乙知道了，他们就不乐意了，感觉自己的隐私受到了侵犯。
2.2 加密
于是小甲们和小乙就决定用密码写他们的信息，他们将每个字母在字母表中移动3个位置。例如，D→A，E→B，F→C。消息“secret message”将是“pbzobq jbppxdb”。现在如果小坏就算拦截了鸽子，也看不懂里面的内容了。
可是好景不长，有个小甲有一天说漏了嘴，让小坏知道了加密规则，小坏按照规则，就可以反推出真实的消息。
这时候小甲们和小乙决定，每个小甲每一串互发信件的过程，都和小乙重新商讨一遍加密规则。这样就算小坏知道了其中一个小甲这串信件的规则，顶多也就能破解这个小甲和小乙这串信件，对于其他小甲们和其他信件串就无法破解了。
但问题又出现了，小甲和小乙都不在一个地方，商讨规则也只能通过飞鸽传书，如果每次在商讨规则的时候鸽子被小坏截下来了，那岂不是又就要被小坏知道秘密了。
2.3 飞鸽带箱子
为了解决上面一个问题，小甲们和小乙提供了一个更好的方案。当小甲想要给小乙发送封信件的时，会按照下面的步骤进行操作：
① 小甲发送一封没有内容的信件通过鸽子给小乙。
② 小乙把鸽子带回家，给鸽子绑上一个开着带锁的箱子，自己保存着开锁的钥匙。
③ 小甲拿到箱子，把信放在箱子里面，合上箱子，通过鸽子给小乙
④ 小乙拿到箱子，通过钥匙打开箱子，读取信件。
这样小坏就算拦截了鸽子，没有钥匙也打不开箱子，也就无法读取里面的信件了。这样一来问题看似就解决了，但是还出来了一个新的问题，如果小坏伪装成小乙，在小乙给小甲箱子的时候把鸽子拦截下来，换上一个新的钥匙在小坏手里的箱子。那之后小甲把信件放在这个箱子里，传给小乙时候，小坏再拦下这个鸽子，打开箱子，读取修改信件，再把信件放到小乙给的那个箱子里。那不就又被小坏得逞了。
2.4 确认箱子是真的
为了解决上面一个问题，小乙决定给自己的箱子签上名。这样当小甲收到箱子时候检查一下这个签名是不是小乙的签名，这样就可以判断中途箱子有没有被小坏掉包了。但是小甲如何判断小乙的签名的真假呢？这时候小甲和小乙就找到了一批德高望重的长者。长者给了小乙一个含有小乙名字的印章，每次传箱子时候，在箱子上盖一个这个印章。同时德高望重的长者承诺给人颁发印章时候，只会给人发这个人自己名字的印章，而不会给他发别人名字的印章。小甲拿到箱子时候，看到印章里面的名字是小乙，再去问一下长者，这个印子是真印子没错吧。得到长者的肯定答复后，就可以确定这个箱子是小乙传来的那个箱子了。到此似乎小坏已经没有空子可以钻了。但还有一个问题，那就是，如果小乙小给小甲回消息，似乎也要有这么一个传箱子的费劲事情。而且箱子真的很重，鸽子不想一直带着箱子来回跑。
2.5 箱子太重
虽然前面的一顿操作已经让小坏没有机会了。但是箱子真的太重了，影响了鸽子的飞行速度。于是小甲们和小乙决定，小甲只在箱子里面放加密规则。一旦小乙收到加密规则后，之后的通信就按照前面所说的加密方式进行通信。因为已经通过箱子印章操作解决了在商讨规则时候被小坏拦截下来的问题。
到此整个小甲们和小乙通信的过程就得到了很好的保密，同时也尽可能的减少了鸽子的压力。
3、HTTPS原理解释
其实HTTPS的操作就如同前面所说，接下来从专业的角度解释一下前面所说的小甲们小乙长者箱子等个代表什么意思，同时再串一遍HTTPS的通信过程。
小甲们：客户端
小乙：服务端
小坏：黑客
商讨规则的加密方式：对称加密
箱子和钥匙：非对称加密里的公钥和私钥
长者们：证书颁发机构CA，如Symantec、Comodo、GoDaddy、GlobalSign等。
长者给小乙印章：如果需要采用HTTPS协议服务端需要向CA申请认证证书。
箱子太重：非对称加密要比对称加密复杂，加解密过程更加耗费时间。
而整个HTTPS通信步骤大致如下：
① 客户端发送一个空消息给服务端
② 服务端将包含有非对称加密公钥和CA认证证书的服务器证书传给客户端
③ 客户端根据放在本地库里面的CA证书列表判断传来的CA认证证书是否是有效的
④ 客户端随机生成对称加密公钥，并将这个对称加密公钥用从服务器传来的非对称加密公钥加密，发给服务端。
⑤ 服务端收到用非对称加密公钥加密过的数据，通过非对称加密的私钥解密，获取里面的对称加密公钥。
⑥ 服务端和客户端用对称加密公钥对消息进行加密后互相发送通信。
4、SSL/TSL
根据前面所述，已经大致走通了HTTPS的通信流程，这边再对服务端（小乙）如何CA机构（长者们）申请认证证书（印章），以及客户端（小甲们）如何向验证证书进行一下说明。这层验证是基于网络层里面SSL/TSL层进行的。
CA即证书授权中心( certificate authority)，这些机构受国际认可。他会对他受信任的申请对象颁发相应的证书server.crt，同时他可以随时吊销申请对象的证书。而客户端的本地一般会存储有ca.crt，可以来验证server.crt的正确性。要看本地的ca.crt对于chrome浏览器可以通过：设置 -> 高级 -> 管理证书 -> 授权中心 查看。服务端想申请server.crt，需要先生成一对server.pub/server.key（传信件的带锁箱子和解锁钥匙），然后将组织信息，个人信息（域名等）和server.pub（带锁箱子）一起打包成一个server.req即申请认证文件给CA认证机构。CA认证机构通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。如果一切合法，就向申请者签发认证文件证书。证书里面包含如下信息：申请者公钥（带锁箱子）、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等明文信息，同时包含一个签名。最后一个签名很关键，它是通过如下算法生成的：首先，使用散列函数计算明文信息的信息摘要。然后用 CA的私钥（ca.key）对信息摘要进行加密，密文就是这个签名。而这个签名的解密公钥就是前面说的放在本地的ca.crt。每当客户端向服务端发起请求，服务端需要返回证书文件。客户端读取证书中的明文信息，采用同样的散列函数计算得到信息摘要。然后利用对应CA机构的ca.crt去解密签名。如果计算的信息摘要和解密出来的签名一致，代表这个信息没有被篡改过，是可信的信息。也就是说信息里面的公钥（带锁箱子）合法，客户端然后会验证证书相关的域名信息、有效时间、是否吊销等信息。 一切通过了，这时候就可以用证书明文信息里面的公钥（带锁箱子）进行加密客户端随机生成的对称加密的公钥了。整个流程如下图：
Tips：从上面的表述可以看到，公钥可以用来加密也可以用来解密，私钥也是一样。两者的区别在于私钥只有创建者知道，公钥是传出去给需要的人用的。公钥加密的信息只有对应私钥能解密读取，私钥加密的信息只有对应公钥能解密读取。CA就是用自己的私钥（ca.key）对证书加密，用公钥（ca.crt）对证书解密。而服务端是用公钥（带锁箱子）来对信息进行加密，用私钥（解锁钥匙）来对信息进行解密的。这种是一对公私钥的加密方式指非对称加密。客户端随机生成的一对都是公钥的加密方式指对称加密，这种被公钥加密过的信息，所有公钥都能解密出来。