HTTPS 原理以及流程

参考来源：https://blog.csdn.net/iispring/article/details/51615631
https://limboy.me/tech/2011/02/19/https-workflow.html
一、密码学基础
明文： 明文指的是未被加密过的原始数据。
密文：明文被某种加密算法加密之后，会变成密文，从而确保原始数据的安全。密文也可以被解密，得到原始的明文。

密钥：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。

目前而言，加密算法可以分两大类，一类是对称加密算法，还有一类是非对称加密算法。

对称加密：对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快，适合于对大数据量进行加密，常见的对称加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。
其加密过程如下：明文 + 加密算法 + 私钥 => 密文
解密过程如下：密文 + 解密算法 + 私钥 => 明文
对称加密中用到的密钥叫做私钥，私钥表示个人私有的密钥，即该密钥不能被泄露。
其加密过程中的私钥与解密过程中用到的私钥是同一个密钥，这也是称加密之所以称之为“对称”的原因。由于对称加密的算法是公开的，所以一旦私钥被泄露，那么密文就很容易被破解，所以对称加密的缺点是密钥安全管理困难。

非对称加密：非对称加密也叫做公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通信双方使用相同的密钥，如果一方的密钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对密钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的密钥，任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。
被公钥加密过的密文只能被私钥解密，过程如下：
明文 + 加密算法 + 公钥 => 密文， 密文 + 解密算法 + 私钥 => 明文
被私钥加密过的密文只能被公钥解密，过程如下：
明文 + 加密算法 + 私钥 => 密文， 密文 + 解密算法 + 公钥 => 明文
由于加密和解密使用了两个不同的密钥，这就是非对称加密“非对称”的原因。
非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。
在非对称加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（椭圆曲线加密算法）等。
二、HTTPS简介：
HTTPS是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。在HTTPS数据传输的过程中，需要用SSL/TLS对数据进行加密和解密，需要用HTTP对加密后的数据进行传输，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。

SSL的全称是Secure Sockets Layer，即安全套接层协议，是为网络通信提供安全及数据完整性的一种安全协议。，SSL标准化之后就改名为TLS（Transport Layer Security）了

HTTPS为了兼顾安全与效率，同时使用了对称加密和非对称加密。数据是被对称加密传输的，对称加密过程需要客户端的一个密钥，为了确保能把该密钥安全传输到服务器端，采用非对称加密对该密钥进行加密传输，总的来说，对数据进行对称加密，对称加密所要使用的密钥通过非对称加密传输。

HTTPS在传输的过程中会涉及到三个密钥：

• 服务器端的公钥和私钥，用来进行非对称加密
• 客户端生成的随机密钥，用来进行对称加密

---

一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。

1. 客户端向服务器发起HTTPS请求，连接到服务器的443端口。

2. 服务端的配置:
   采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。

3. 传送证书:这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。服务器将自己的公钥发送给客户端

4. 客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用改证书对该随机值（客户端密钥）进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。

5. 客户端会发起HTTPS中的第二个HTTP请求，传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了

6. 服务端用私钥解密后，得到了客户端传过来的随机值(客户端秘钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 然后服务器将加密后的密文发送给客户端。

8. 客户端用之前生成的随机数（客户端秘钥）解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

---

参考来源：https://www.cnblogs.com/sujing/p/10927569.html#!comments
数字证书
客户端第一次与服务器进行通信的时候，服务器需要出示自己的数字证书，证明自己的身份以及自己的公钥，类似如下（实际上就是一堆数据，这里为了直观）

那这个数字证书怎么产生的呢？总不能是服务器自己造一个吧？上面说到了我们生活中的证书是由权威机构颁发的、无法伪造的，比如身份证就是由派出所发证、毕业证由教育部发证，如果需要验证真假，只需要上相关的系统输入编号查询就能查到了！那我们数字证书也应该有这两个特性-权威机构颁发、防伪！

CA机构
  CA机构就是数字证书颁发的权威机构，负责颁发证书以及验证证书的合法性。如果服务器需要做个有身份的服务器，就需要向CA机构提交申请，当然有钱才好办事，交钱才能给你办证……

服务器向CA机构提交申请，需要提交站点的信息如域名、公司名称、公钥等等，CA审批无误之后就可以给服务器颁发证书了！

客户端在拿到服务器的证书后，就需要验证证书编号是否能在对应的CA机构查到，并且核对证书的基本信息如证书上的域名是否与当前访问的域名一致等等，还可以拿到证书中服务器的公钥信息用于协商对称密钥！

证书颁发了，可是又怎么防止伪造，怎么保证在传输过程中不被篡改呢？万一小王截获到数字证书，把公钥改成自己的那不是依然无法保证安全了么？这就需要数字签名了！

数字签名
 与公司签过劳动合同的朋友应该都知道，在合同信息的填写中，是不能有涂改的，否则需要重新填写！并且在最后需要甲方和乙方签名并且盖章。一旦签名盖章后的合同就具有了法律的效力，合同就不能再修改。签名和盖章操作就是防止合同伪造，规定不能修改就防止了合同被篡改！

在实际生活中签名、盖章操作是实实在在的动作，作用在具体某个物体上的！但是我们的数字证书本身就是虚拟的，怎么去给一个虚拟的证书签名盖章呢？数字签名又是什么机制呢？

我们在做权限系统的时候，存储用户密码的时候都会经过MD5计算摘要后存储，在登录的时候计算用户填写的密码的MD5摘要与数据库存储的摘要进行对比，如果一致则密码正确，否则登录失败！MD5是不可逆的，且不同的数据计算出来的摘要是不一样的（当然也有极小的概率会hash碰撞），基于这个特性，就有了数字签名的思路。

服务器提交自己的基本信息想CA机构提出申请，CA机构在给服务器颁发证书的时候，会连同数字证书以及根据证书计算的摘要一同发送给服务器，且这个摘要是需要经过CA机构自己的私钥进行加密的。申请流程如下：

 啥？不够直观？那我们再来个直观点的！通过下图我们能看到，CA给服务器颁发的证书是有自己专属的“公章”的。
 
哪些CA机构对于客户端来说是权威或者说是认可的呢？我们打开IE浏览器能看到客户端内置的CA机构的信息，包含了CA的公钥、签名算法、有效期等等…

 服务器在与客户端通信的时候，就会将数字证书和数字签名出示给客户端了。客户端拿到数字证书和数字签名后
 先通过操作系统或者浏览器内置信任的CA机构找到对应CA机构的公钥对数字签名进行解密， 然后采用同样的摘要算法计算数字证书的摘要，如果自己计算的摘要与服务器发来的摘要一致，则证书是没有被篡改过的！这样就防止了篡改！第三方拿不到CA机构的私钥，也就无法对摘要进行加密，如果是第三方伪造的签名自然也在客户端也就无法解密，这就防止了伪造！所以数字签名就是通过这种机制来保证数字证书被篡改和被伪造。
 **具体流程如下：

  啥？又不够直观？那我们继续…

 这里需要注意一点，一个是CA机构的公钥，内置在客户端，用来解密数字签名！另一个是目标服务器的公钥，在数字证书内容里，用来协商对称密钥！