https是建立在SSL(Secure Sockets Layer 安全套接层)上的网络安全协议，最初由NetScape公司提出，在http的基础上添加了一个安全传输层，对所有的数据都加密后再进行传输，客户端和服务器端收到加密数据后按照之前约定好的秘钥解密。之后由IETF标准化为TLS(Transport Layer Security 安全传输层协议），其端口为443。
https也称作HTTP over TLS。TLS的前身是SSL，TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3
下图描述了在TCP/IP协议栈中TLS(各子协议）和HTTP的关系。
① HTTP的困境
当我们学习HTTP的时候，肯定使用过抓包工具(wireshark， fiddler）帮助我们认识HTTP协议。回忆一下就知道，抓包工具不论是get请求还是post请求都能准确截取其中传输内容，如果想要隐藏传输内容，就必须进行密文传输，就像战争年代的电报密码，即使被截取也不能破解其中的内容。
② 加密方式
让我们设想这样一个情景：海绵宝宝想和蟹老板秘密协商新的蟹黄堡配方，如果让你来设计加密过程，你有几种方法呢？
1.海绵宝宝和蟹老板约定一个密钥，传输和解读都通过这个密钥解密，这个密钥称为公钥。
双方使用相同密钥进行加密通讯
2.小心谨慎的蟹老板有一个只有自己知道的密钥(称为私钥)和公钥，他把公钥发给海绵宝宝，海绵宝宝可以通过公钥解密私钥加密的消息，但是公钥加密的消息只有私钥能解开，这在一定程度上做到了单向安全。
这便是HTTPS中用到的两种加密方式，前者称为对称加密，通讯双方持有相同的密钥，后者称为非对称加密。
③ 协商
那么HTTPS中用的哪种加密方式呢？
如果采用对称加密，那么蟹老板和所有人都拥有同一个密钥，这无异于没有加密！！！
所以蟹老板需要和每个人协商一个密钥，每个人互不相同，这样就能保证加密了。
在HTTPS中，这个协商的过程一般是用非对称加密来进行的。客户端一旦得到了真的服务器公钥，往服务端传消息就是安全的。因为只有服务端的私钥才能解密公钥加密的数据。但是，客户端可没那么容易得到真正的公钥，因为发送公钥的过程存在被别人调包的可能性，这就是传说中的中间人攻击。
④ 中间人攻击
让我们回到情景中。痞老板听闻消息，企图在协商过程通过中间人的方式截取蟹黄包配方。
如图，蟹老板想告诉海绵宝宝自己的公钥，此时痞老板出现，替换了蟹老板的公钥，海绵宝宝收到一个来自痞老板的公钥并以为是蟹老板的，由此在之后的传输中痞老板便可以轻松的浏览蟹老板和海绵宝宝的所有沟通内容了。 为了防止痞老板窃听，那这个协商的过程也必须加密，这样下去协商加密也要加密，……问题没有穷尽。那怎么办呢？
⑤ HTTPS数字证书
现在美人鱼战士和企鹅男孩登场了，他们保证作为一个权威中间机构为大家提供认证服务，负责为大家发放统一的公钥。
蟹老板先将自己要传输的公钥给美人鱼战士，美人鱼战士用自己的私钥加密后返回给蟹老板。这样大家只要能通过这个公钥解密蟹老板发来的密文，提取蟹老板的公钥，就能保证这个公钥不是来自痞老板。 这个时候即便痞老板想替换公钥，伪造的公钥也不能用美人鱼战士的公钥解开了。 这就是数字证书。
服务器通过CA认证得到证书，这个证书包含CA的私钥加密后的服务器公钥，客户端用预先存储在本地的CA公钥即可解密得到服务器的公钥，从而避免公钥被替换。
⑥ HTTPS数字签名
如果你是痞老板，你有什么方法可以再次窃取消息呢？
显然不能通过简单替换公钥来窃取了，海绵宝宝只能解开美人鱼战士颁发的证书，那我也去申请一个证书，直接替换整个证书不就可以从而替换掉公钥了吗？
企鹅男孩发现了这个问题，他决定在证书里面添加一些额外的信息以供验证（数字签名）。现在企鹅男孩颁发的证书格式如下：
来自：蟹堡王
加密算法：MD5
公钥：xxxx（已通过私钥加密，可通过公钥解密）
海绵宝宝只要通过企鹅男孩的公钥提取到“蟹堡王”+“MD5” 计算出一个公钥，与证书内的公钥进行对比，就可以验证证书是否经过替换，如下图：
带有签名的证书
对比发现证书被替换(上图有误，被替换的证书应该是来自：痞老板工厂)。
虽然痞老板依旧可以截取证书，但是他却不能替换其中任何的信息，如下：
来自：痞老板工厂
加密算法：MD5
公钥：awkspoc512
此时海绵宝宝可以发现来自不是蟹堡王而拒绝信任，并且
痞老板工厂 + MD5 !== djawdn888
综上，用一句话总结https：在https协议下，服务器与客户端通过非对称加密的方式协商出一个对称加密的密钥完成加密过程。其中数字证书的作用是避免公钥被替换，而数字签名的作用是校验公钥的合法性。
⑦ HTTPS的握手过程
明白了HTTPS的原理，握手过程就十分简单，总结如下：
1.客户端：发送random1 + 支持的加密算法 + SSL Version等信息
2.服务端：发送random2 + 选择的加密算法A + 证书
3.客户端：验证证书 + 公钥加密的random3
4.服务端：解密random3，此时两端共有random1，random2，random3，使用这3个随机数通过加密算法计算对称密钥即可。
以上只有random3是加密的，所以用random1 + 2 + 3 这3个随机数加密生成密钥。
这里详细说明一下客户端验证证书的流程：
- 我们知道CA机构在签发证书的时候，都会使用自己的私钥对证书进行签名
证书里的签名算法字段 sha256RSA 表示，CA机构使用sha256对证书进行摘要，然后使用RSA算法对摘要进行私钥签名，而我们也知道RSA算法中，使用私钥签名之后，只有公钥才能进行验签。 - 如果我们使用的是购买的证书，那么很有可能，颁发这个证书的CA机构的公钥已经预置在操作系统中。这样浏览器就可以使用CA机构的公钥对服务器的证书进行验签。确定这个证书是不是由正规的CA机构颁发的。验签之后得到CA机构使用sha256得到的证书摘要，然后客户端再使用sha256对证书内容进行一次摘要，如果得到的值和验签之后得到的摘要值相同，则表示证书没有被修改过。
- 如果验证通过，浏览器就会显示绿色安全字样，如果服务器购买的证书是更高级的EV类型，就会显示出购买证书的时候提供的企业名称。如果没有验证通过，就会显示不安全的提示。
⑧ Q&A
1.客户端的公钥从哪里来的？
权威机构的公钥是由操作系统和浏览器共同维护，预先存储在本地的。
2.握手过程为什么要用3个随机数？
一方面，https的握手过程中出现的3个随机数，只有第三个是加密的随机数。另一方面，由于很多主机可能产生弱随机数，因此3个叠加使用更接近随机，比较安全。
参考博文：
海绵宝宝也懂的HTTPS
图片理解数字签名和验签过程