Open lovelmh13 opened 3 years ago
在 HTTP 传输中，内容都是以明文的方式传递的，不安全，很容易被获取到。这个方式叫做中间人攻击。如果要安全的传输内容，就要使用 HTTPS，对请求和响应的内容进行加密。
HTTPS 在 HTTP 和 TCP 请求之间，多加了一层 TLS 安全层来对数据进行加密解密。
对称加密是最简单方便的加密，发送端和接收端都是用相同的方式来进行加解密。
但是，对称加密有个问题，就是生成密钥之前的协商过程，加密套件和 client-random 和 service-random 是使用明文传递的，这样也会被拦截。
为了避免加密套件和随机数被拦截到，改用非对称加密。非对称加密使用公私钥来进行加密。
服务器会生成两种密钥 ，一个是公钥一个是私钥。服务器会把公钥发给浏览器端。自己留下私钥，从不公开。如果只有公钥，没有私钥，那么也不能解密。
公钥加密的数据只能用私钥解，私钥加密的数据只能用公钥解。
浏览器端发送非对称加密套件列表给服务器。
服务器选择一个非对称加密套件和一个公钥给浏览器（在非对称加密时服务器上需要有浏览器加密的公钥和服务器来解密的私钥，这个公钥需要传给浏览器，让浏览器对数据进行加密）。
浏览器和服务器互相返回确认消息。
有了公钥的浏览器，就可以对数据进行加密了，只有有对应私钥才可以对公钥加密的数据进行解密。所以及时被别人拿到了公钥也不用担心数据被解密。
不过这里存在一个明显的问题，就是黑客也可以获取到公钥，服务器端只能用私钥加密，私钥加密的数据可以用公钥来解，这样就不能做到服务器端发送数据的安全性了，黑客可以解密并篡改服务器端发送的数据，浏览器能够收到数据，那攻击者必然也能够收到数据。
所以，使用非对称加密虽然可以保证浏览器发送的数据安全，但是并不能保证无服务器发送来的数据是安全的。
非对称加密还有一个缺陷：非对称的加密效率太低，会影响用户体验。
我们既想做到效率高，又想做到安全，于是乎就把对称加密和非对称加密混合起来用，结合他们的长处，规避短处，来满足我们希望的效果。
浏览器发送对称加密套件列表和非对称加密套件列表和 client-random 给服务器。
服务器保存 client-random。选择一个对称加密套件和一个非对称加密套件，生成一个 service-random，然后把对称加密套件、非对称加密套件、 service-random 和 公钥发给浏览器。
浏览器拿到公钥，再生成一个随机数 pre-master。使用公钥对这个 pre-master 加密，把这个加密后的 pre-master 发送给服务器。
服务器拿到加密后的 pre-master 对 pre-master 进行解密，返回确认。
此时，浏览器和服务器都拥有了相同的 client-random、service-random 和 pre-master，此乃对称。
由于浏览器和服务器是同一套方法来加密的，又是对称的，所以生成的密钥也是一样的。
在这个过程中，pre-master 是在浏览器端经过公钥加密生成后再传输的，所以黑客拿到了 pre-master 也没有私钥，生成不出解密的密钥，这就保证了数据的安全性。
即使是经过了混合加密，但是如果黑客通过 DNS 劫持，直接把被访问的网站的 IP 改成了他自己的 IP 地址，那么我们再怎么加密也于事无补了。
所以，需要服务器证明，「我即是我」。
通过 CA 机构办法的数字证书，可以来证明。数字证书里面包括服务器的身份和服务器的公钥。
在混合加密的基础上，做了两点改变：
验证证书主要是通过摘要信息来验证。
具体其他数字证书的相关问题，可以看极客时间 《浏览器工作原理与实践》
极客时间 《浏览器工作原理与实践》
HTTPS
在 HTTP 传输中，内容都是以明文的方式传递的，不安全，很容易被获取到。这个方式叫做中间人攻击。如果要安全的传输内容，就要使用 HTTPS，对请求和响应的内容进行加密。
HTTPS 在 HTTP 和 TCP 请求之间，多加了一层 TLS 安全层来对数据进行加密解密。
使用对称加密
对称加密是最简单方便的加密，发送端和接收端都是用相同的方式来进行加解密。
但是，对称加密有个问题，就是生成密钥之前的协商过程，加密套件和 client-random 和 service-random 是使用明文传递的，这样也会被拦截。
使用非对称加密
为了避免加密套件和随机数被拦截到，改用非对称加密。非对称加密使用公私钥来进行加密。
服务器会生成两种密钥 ，一个是公钥一个是私钥。服务器会把公钥发给浏览器端。自己留下私钥，从不公开。如果只有公钥，没有私钥，那么也不能解密。
公钥加密的数据只能用私钥解，私钥加密的数据只能用公钥解。
浏览器端发送非对称加密套件列表给服务器。
服务器选择一个非对称加密套件和一个公钥给浏览器（在非对称加密时服务器上需要有浏览器加密的公钥和服务器来解密的私钥，这个公钥需要传给浏览器，让浏览器对数据进行加密）。
浏览器和服务器互相返回确认消息。
有了公钥的浏览器，就可以对数据进行加密了，只有有对应私钥才可以对公钥加密的数据进行解密。所以及时被别人拿到了公钥也不用担心数据被解密。
不过这里存在一个明显的问题，就是黑客也可以获取到公钥，服务器端只能用私钥加密，私钥加密的数据可以用公钥来解，这样就不能做到服务器端发送数据的安全性了，黑客可以解密并篡改服务器端发送的数据，浏览器能够收到数据，那攻击者必然也能够收到数据。
所以，使用非对称加密虽然可以保证浏览器发送的数据安全，但是并不能保证无服务器发送来的数据是安全的。
非对称加密还有一个缺陷：非对称的加密效率太低，会影响用户体验。
混合加密
我们既想做到效率高，又想做到安全，于是乎就把对称加密和非对称加密混合起来用，结合他们的长处，规避短处，来满足我们希望的效果。
浏览器发送对称加密套件列表和非对称加密套件列表和 client-random 给服务器。
服务器保存 client-random。选择一个对称加密套件和一个非对称加密套件，生成一个 service-random，然后把对称加密套件、非对称加密套件、 service-random 和 公钥发给浏览器。
浏览器拿到公钥，再生成一个随机数 pre-master。使用公钥对这个 pre-master 加密，把这个加密后的 pre-master 发送给服务器。
服务器拿到加密后的 pre-master 对 pre-master 进行解密，返回确认。
此时，浏览器和服务器都拥有了相同的 client-random、service-random 和 pre-master，此乃对称。
由于浏览器和服务器是同一套方法来加密的，又是对称的，所以生成的密钥也是一样的。
在这个过程中，pre-master 是在浏览器端经过公钥加密生成后再传输的，所以黑客拿到了 pre-master 也没有私钥，生成不出解密的密钥，这就保证了数据的安全性。
数字证书
即使是经过了混合加密，但是如果黑客通过 DNS 劫持，直接把被访问的网站的 IP 改成了他自己的 IP 地址，那么我们再怎么加密也于事无补了。
所以，需要服务器证明，「我即是我」。
通过 CA 机构办法的数字证书，可以来证明。数字证书里面包括服务器的身份和服务器的公钥。
在混合加密的基础上，做了两点改变：
验证证书
验证证书主要是通过摘要信息来验证。
具体其他数字证书的相关问题，可以看极客时间 《浏览器工作原理与实践》
参考
极客时间 《浏览器工作原理与实践》