1.HTTPS是什么 

HTTPS也是一种应用层协议。HTTPS是在HTTP协议的基础上，对其进行加密的一种协议。

由于HTTP协议内容在网络传输中都是按照文本的方式明文传输的，这就导致了数据在传输的过程中，就出现一些HTTP请求内容的一些篡改。

下图是一个关于HTTP协议在网络传输的简图 

由于HTTP协议的请求和响应在网络中都是明文传输，且网络中传输的数据很有可能经过很多路由器和交换机的转发之后，数据才能到达对方，这样就会让黑客有了可乘之机。此时黑客就能通过黑入路由器和交换机，此时黑客就能很轻松获取到请求和响应的内容，这就造成了网络数据传输的不安全。

此时，我们就要对传输的协议内容进行加密，保证数据在网络传输中的安全，此时，就用上了HTTPS协议。 

加密就是把明文（要传输的信息）进行一系列转换，生成密文 

解密就是把密文再进行一些列转换，还原成明文

在这个加密和解密的过程中，往往需要一些数据来辅助进行加密和解密，这些数据就可以被称为秘钥

2.HTTPS的加密方式 

通过HTTPS协议发送的内容就不在是以明文的方式在网络中传输，，而是经过加密之后的“密文” ，加密的方式有很多种，整体可以分为对称加密和非对称加密。

对称加密 

对称加密就是客户端和服务器共同使用一把密钥对发送的数据进行加密。

引入对称加密之后，尽管传输的请求和返回的响应能够被截获，但是黑客无法知道密钥是啥，就无法进行解密，自然而然， 也就不知道请求和响应的内容是啥。

但是事情没有那么简单，也就是在加密前，客户端和服务器就首先要一起商量共同使用的密钥key是啥。也就是，在网络传输中，需要有一方生成一个密钥，然后通过先通过网络将该密钥告知对方，由于此时还没有共同约定好的密钥，就无法对传输密钥这个过程进行加密，而黑客就有可能通过截获密钥传输的过程，来获取密钥。

一个对称加密的全部过程

此时黑客就可能获取到了密钥key，如果后续在通过密钥key进行加密，那么黑客也能通过密钥key进行解密了，这样就前功尽弃了。 

此时，就用到我们的非对称加密了。

非对称加密 

非对称加密就是客户端持有一把公钥pub，公钥可以被其他人的，而服务器持有一把私钥priv，该私钥只为服务器所持有，不会被其他人所获得，此时，客户端就可以使用公钥对传输的数据进行加密，而解密操作只能使用私钥进行解密。 

通过非对称加密，尽管黑客能截获使用公钥加密的数据，但是由于黑客没有私钥，所以无法对截获的数据进行解密，这样，黑客就无法获取到请求和响应的具体内容了。

对称加密之所以有安全隐患，是因为在进行对称加密之前，需要客户端和服务器共同约定密钥是啥，而这个约定密钥的过程就有可能被黑客截获，从而让黑客获得密钥。

而有了非对称加密，我们就可以对约定对称密钥的过程进行加密。

首先，先让客户端从服务器获取一个公钥pub1，这个公钥pub1是后续对 对称密钥 进行加密的，这个公钥是可以被其他人获取的，没有很大的影响。因为解密只能使用服务器持有的私钥pri进行解密，而私钥是无法被其他人获取的。

其次，我们就可以使用公钥pub对 对称密钥 （该对称密钥才是后续对数据进行加密的密钥），此时，就可以使用公钥pub对 约定对称密钥的过程 进行加密，这时，即使黑客能截获约定对称密钥的过程，但是由于没有私钥pri，无法进行解密，所以，黑客就无法获取 对称密钥。

后面服务器就会返回一个答应使用对称密钥的响应，该响应是用对称密钥进行加密的。 

最后，客户端就可以使用对称密钥key对传输的数据进行加密。

这时，由于黑客没有获取到对称密钥，自然而然没法获取到请求和响应的具体内容。 

非对称加密流程总结

1. 客户端先生成一个对称密钥，这个对称密钥通过公钥加密传输到服务器

2.由于中间的网络设备没有私钥，即使截获了数据，也无法对数据进行解密，自然无法获取到对称密钥

3.后续服务器通过私钥进行解密，还原出客户端发送的对称密钥，并使用这个对称密钥给返回的响应进行加密

4.后续客户端与服务器的通信只需要使用对称密钥尽心对称加密即可，因为此时对称密钥只有客户端和服务器知道

注意事项：由于对称加密的效率比非对称加密的效率高很多，因此只是在开始阶段协商密钥时使用非对称加密，后续的传输仍使用对称加密。

但是这样还存在一个问题，那就是“中间人攻击” 问题，该问题是在客户端从服务器获取公钥的过程中的安全隐患。

中间人攻击 

在没有证书的非对称加密中，黑客可以通过中间人攻击来获取传输的数据。

接下来，我先用语言描述一下中间人攻击。

首先，客户端要从服务器那里获取公钥pub1的信息，接着服务器就返回一个公钥是啥的响应，公钥是啥的相应就会被黑入侵的设备敏锐的察觉到，此时黑客入侵的设备就先截获该响应并获取到公钥pub1并保存好，接着黑客就可以根据算法构造属于自己的公钥pub2和私钥pri2，然后将劫持文报中的公钥pub1替换成自己的公钥pub2，并伪造报文发送给客户端。

当客户端接收到一个已经经过黑客更改的的报文时，由于客户端没有辨认该报文是否有经过更改的能力，然后将客户端形成的对称密钥key用公钥pub2进行加密，并形成报文发送给服务器。

此时，当使用公钥pub2加密的对称密钥发送给服务器的过程中，当该报文经过黑客入侵的路由器，黑客就能获取到该报文，由于该报文是用公钥pub2进行加密的，而黑客有与pub2对应的私钥pri2，此时就能使用私钥pri2对该报文进行解密，从而获取到对称密钥。

然后，黑客此时有重新使用公钥pub1对该key进行加密，并形成报文发送给服务器，当该报文到达服务器之后，服务器就使用私钥pri1进行解密，获取到了对称密钥。

最后，客户端与服务器的通信就会使用对称密钥key进行加密了，但是由于黑客通过中间人攻击也得到了key，最终也会导致数据传输的不安全。 

如下图

如何解决中间人攻击的问题呢？这时候就要引入证书。

引入证书 

服务器在使用HTTPS协议前， 需要向CA机构申领一份数字证书，在数字证书就是用来解决中间人问题的。该数字证书里面包含了证书申请者信息，公钥信息等信息。服务器就可以将数字证书发送给客户端，然后客户端从证书里面获取公钥就行了，证书就如同公钥的身份证，保证客户端从服务器得到公钥的真实性。

这个证书可以理解为一个结构化的的字符串，里面包含了证书的发布机构，证书的有效期，公钥，证书所有者，签名等信息。

需要注意的是：证书机构在生成一份数字证书的时候，会同时生成一对公钥和密钥，该公钥可以直接从正版的操作系统中获得，而私钥只为证书机构所持有。

 下图是一个证书的使用简图

1.申请和生成证书 

 当服务端申请证书的时候，证书机构会对服务端进行审核，并专门为该网站形成一个数字签名，过程如下

1.服务端首先向证书机构提供一组明文数据，这些明文数据包括服务器的公钥，服务器的域名等信息，接着证书机构根据这些明文数据进行hash（形象的比喻就是通过这些明文数据通过某种算法形成一个校验和），形成数据摘要，然后对这些数据摘要（校验和）使用服务器的私钥（证书机构也会生成一对非对称密钥）进行加密，得到数字签名（数字签名本质上是一个被加密的校验和）。

接着，这些数据摘要和数字签名就行成一份证书，这样一份证书就可以发送给客户端使用。

数据摘要和数字签名本质上都是一个校验和，后期客户端就通过这个校验和来判断证书的真实性。

新的理解：证书中的数字签名会使用证书机构的私钥加密，

2.证书解决中间人问题的原理 

 在客户端和服务器刚一建立连接的时候，服务器会先给客户端返回一个证书，客户端拿到证书，会先对证书的真实性进行验证。

如下图

首先，客户端会先验证该证书是否过期（证书过期了就会联系证书办法机构重新办法证书），接着判断证书的颁布机构是否能够信任（操作系统中已经内置了可信任的证书），最后验证证书是否经过篡改。

验证证书是否被篡改的过程：

首先，客户端会根据证书中的其他字段，例如证书的颁布机构，证书的有效期是时候，服务器的公钥是啥，服务器的域名是啥等信息使用相同的算法计算出一个校验和1，校验和1是针对客户端收到的数据进行计算，接着通过证书颁布机构的公钥（证书机构的公钥不是通过网络传输的，是可以从本机的操作系统中获得），对数字签名进行解密获得校验和2，校验和2就是服务器申请证书时得到的初始校验和。

接着，客户端就会对校验和1和校验和2的值进行比较。如果两个检验和的值相同，那就说明证书没有被篡改过。此时，如果证书中的公钥信息如果被修改过，那么此时通过同样的算法计算出来的校验和，由于计算校验和时会涉及到公钥的信息，如果证书中的公钥信息被修改，此时客户端计算出来的校验和2就会和校验和1不同，如果两个校验和的值不相等，就证明证书就被篡改过，此时浏览器就会跳出一个警告，告知我们该网站有风险，是否继续访问该网站。

证书验证成功后，客户端此时就会通过证书里面的公钥信息对对称密钥进行加密，然后传输对称密钥，与服务器确定后续加密的对称密钥，如下图

那中间人有没有可能篡改该证书的时候同时修改公钥和数字签名呢？

 如果中间人强行修改证书中的公钥信息和数字签名，此时还要对数字签名使用证书机构的私钥重新加密，由于中间人不可能获得证书机构的私钥，这种操作显然不可能。

如果中间人强行使用自己的私钥进行加密，就会导致客户端使用证书机构的公钥解密失败，还是会得到服务器的警告。

中间人弄个掉包证书来呢？

这种情况还是不会成功，因为证书中包含的服务器的域名，黑客申请证书的域名和服务器申请证书域名是肯定不同的，浏览器这边还是可以对域名进行验证的，输入的URL和的到证书的域名不匹配，同样认为证书非法，最终还是回收到浏览器的警告。 

常见问题 

 为什么摘要内容在网络传输的时候一定要加密形成数字签名呢？ 

 对摘要内容进行加密，形成数字签名，是为了让浏览器能够迅速察觉到摘要内容被修改过，也就是说，数据签名起到一个验证的作用。

如果数据摘要被修改过，此时根据新的摘要内容计算出的校验和肯定与数字签名（本质上也是一个校验和）不同，这样就能让浏览器察觉到摘要内容被修改过。

即使数字签名也被强行修改，但是由于没有证书机构的密钥，使用自己的公钥对数字签名加密，这样也会导致客户端解密时，会解密失败。

为什么签名不直接加密，而是要先hash形成摘要？ 

缩小签名密文的长度，加快数字签名验证的运算速度。 

HTTPS总结 

HTTPS的完整工作流程图

HTTPS的工作过程中涉及到三组密钥 

第一组密钥（非对称加密）：证书颁布机构所持有的公钥和私钥，该公钥和私钥是用来验证证书是否合法

第二种密钥（非对称加密）：用来协商对称密钥的公钥和私钥

第三组密钥（对称加密）：客户端和服务器的加密通信就通过该对称密钥加密

其实一切的关键就是围绕关于对称密钥的密钥，其他的机制只是辅助这个密钥工作

第一组非对称加密是为了让客户端拿到服务期的公钥，第二种非对称加密是为了让客户端把对称密钥传给服务器。