从http谈到https

一、明文传输的http协议

http协议中数据是通过明文传输的，只要能够抓到一个http的网络请求包，便可以看到里面的所有内容。比如你通过http请求，提交了你的账户和密码，对应的信息是以明文的形式在网络中传输。
后来大家觉得不行，要对数据进行加密，那怎么加密呢？浏览器前端中的js代码对数据进行加密，然后传输给后台，后台再解密？好想法，但是怎么和后台确定密钥呢？密钥存哪里呢？其实这种公共的能力，这意味着可以框架层面来做的，这里的“框架”，实际上就是升级http，让它支持这种能力

二、如何进行加密

加密一般会有两种：对称加密和非对称加密。对称加密即加解密用的是同样的密钥，非对称加密则是加解密用的不一样的密钥

2.1 方案一：对传输的数据对称加密

这个方法好像很简单。客户端和服务器约定一个密钥和加密算法，对传输的数据通过此密钥进行加密。但是问题来了，要加密，客户端和服务器就必须先约定密钥，但是最开始的密钥怎么传输呢？或者不传输，大家约定一个，如当前时间戳？但是时间戳太简单易破解……密钥的问题解决不了，此方案废弃

2.2 方案二：对传输的数据非对称加密

简单而言，非对称加密使用一对密钥：公钥和私钥，用公钥解密，就只能用私钥解开，用私钥加密，就只能用公钥解开。公钥，顾名思义，就是可以公布给别人的密钥，而私钥就要自己保存了

那么，运用非对称加密，我们可以：

1. 客户端使用服务器的公钥加密数据，传送给服务器，服务器使用私钥解密，得到信息
2. 服务器使用客户端的公钥加密数据，传送给客户端，客户端使用私钥解密，得到信息

由于公钥不要被别人知道，所以我们一开始可以通过明文交换公钥，后面的传输时，再用各自的公钥进行加密即可

但是问题来了，如果有一开始的明文交换公钥这一步就有问题呢？A本来想传输自己的公钥给B，但是传输时候被C拦截了，C知道了A的公钥（因为此时是明文），然后C将自己的公钥传给了B，B以为此时公钥是A的。同样，C可以拦截B的公钥，将自己的公钥给了A，让A以为这是B的。那在传输信息时候，实际上是A传给C，C再传给B。这样子C可以篡改信息，而A和B还不知道。

这里的根本问题是：我收到一个公钥，这么知道它是谁的公钥？
我向某网站发了一个请求，求它的公钥，然而收到的公钥却可能不是它的公钥！太难了呀

这里采用的方法是：

1. 浏览器存有一个对应网站的证书，这个证书中有公钥信息
2. 客户端向网站发起请求，网站返回一段用其私钥加密后的信息和一段摘要
3. 客户端使用证书中的公钥解密信息，与一同返回的摘要对比，如果一致，就认为公钥信息属于对应的网站

那如果证书中的公钥就有问题了呢？实际上这个证书是权威机构（CA机构）颁发的，如果有问题，找他负责。其实也就是这个权威机构来承担风险，当然需要一个网站要让CA机构颁发证书，是需要付费的，不然他也不愿意承担这样的风险。有的网站还是使用http，其除了信息安全性要求不高，证书的费用也是一个因素

P.S 在Chrome中按F12打开调试模式，选择Security，可以看到当前网站的证书信息

image.png

三、回到https

上面解决了客户端获取服务器公钥的问题，那么服务器如何知道客户端的公钥呢？如果不接这个问题，相当于只有单向的加密：从客户端到服务器的请求加密而已

注意，既然从客户端到服务器的请求加密了，那么我们不就可以利用这来传送客户端的公钥了么！

简要流程如下：

1. 客户端通过证书确认了服务器的公钥
2. 客户端自己生成了公钥和私钥对，用服务器的公钥加密自己的公钥，传送给服务器
3. 服务器用自己的私钥解开信息，得到客户端的公钥。这样客户端和服务器就完成了公钥的交换，然后开始进行通信

上面的加密流程其实就是TLS做的事情。当然在实际中，由于使用非对称加密耗时较长，所以一般通过上面的交换公钥之后，服务器和客户端会在加密通道中协商出一个对称密钥，然后用对称密钥来加密后续的信息。

总之，通过这套加密流程，https可以进行安全传输信息。HTTPS全称是HTTP over SSL，其实就是通过SSL/TLS加密HTTP数据了。