Open lznbuild opened 4 years ago
无法验证报文的完整性和准确性。
将 HTTP 数据提交给 TCP 层之后，数据会经过用户电脑、WiFi 路由器、运营商和目标server，在这中间的每个环节中，数据都有可能被窃取或篡改
HTTP+加密+认证 == HTTPS
HTTP走server的80端口，HTTPS走443端口，那么，80端口没用了吗，当然有用，可以传输数据。443端口，只是建立连接的时候，处理协商数据，也就是TLS握手的过程。
HTTPS在传输数据之前需要client与server进行一个握手(TLS/SSL握手)，在握手过程中将确立双方加密传输数据的密码信息。主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密。
下面总结这个握手流程。
client发起HTTPS请求，连接443端口，提交支持的对称加密算法列表+client-random，server收到请求，和自己支持的加密算法进行比对，如果不符合，则断开连接。否则，server会把符合的算法+证书+service-random发给client，包括证书时间、证书日期、证书颁发的机构，公钥。
client验证证书，包括颁发证书的机构是否合法与是否过期，证书中包含的网站地址是否与正在访问的地址一致。保存公钥，client会生成一个随机字符串pre-master，然后用服务端的公钥进行加密，这里就保证了只有服务端才能看到这串随机字符串，并向server发送加密后的数据；最后server拿出自己的私钥，解密出数据，并返回确认消息，握手过程结束。
基本思路就是传输数据阶段依然使用对称加密，但是对称加密的密钥我们采用非对称加密来传输
数字证书有两个作用：一个是通过数字证书向浏览器证明server的身份，另一个是数字证书里面包含了server公钥。
数字证书，该证书包含服务端的信息，比如颁发者、域名、有效期，为了保证证书是可信的，需要由一个可信的第三方来对证书进行签名。这个第三方一般是证书的颁发机构，也称 CA（Certification Authority，认证中心）。
此时⼜带来⼀个问题，中间⼈问题：
如果此时在client和server之间存在⼀个中间⼈,这个中间⼈只需要把原本双⽅通信互发的公钥,换成⾃⼰的公钥,这样中 间⼈就可以轻松解密通信双⽅所发送的所有数据。如果中间⼈篡改了证书，那么身份证明是不是就⽆效了？这个证明就⽩买了，这个时候需要⼀个新的技 术，数字签名。
所以这个时候体限了CA的作用，证明身份，防⽌被中间⼈攻击。 证书中包括：签发者、证书⽤途、使⽤者公钥、使⽤者私钥、使⽤者的HASH算法、证书到期时间等
数字签名就是⽤CA⾃带的HASH算法对证书的内容进⾏HASH得到⼀个摘要，再⽤CA的私钥加密，最终组成数字签 名。
当别⼈把他的证书发过来的时候,再⽤同样的Hash算法,再次⽣成消息摘要，然后⽤CA的公钥对数字签名解密,得到CA创建的消息摘要,两者⼀⽐,就知道中间有没有被⼈篡改了。
这个时候就能最⼤程度保证通信的安全了。
那么这个证书的签名怎么检验真假呢？
要回答这个问题先要理解证书签名的过程。证书签名就是将证书信息进行 MD5 计算，获取唯一的哈希值，然后再利用证书颁发方的私钥对其进行加密生成。
校验过程与之相反，需要用到证书颁发方的公钥对签名进行解密，然后计算证书信息的 MD5 值，将解密后的 MD5 值与计算所得的 MD5 值进行比对，如果两者一致代表签名是可信的。所以要校验签名的真伪，就需要获得证书颁发方的公钥，这个公钥就在颁发方的证书中。
这种通过签名来颁发与校验证书的方式会形成一个可追溯的链，即证书链。处于证书链顶端的证书称为根证书，这些根证书被预置在操作系统的内部。
HTTPS是安全的。拿物流来比方， HTTPS 就是你把包裹包装得很安全； DNS劫持 就是有个人冒充快递来收单子了；
如果在client生成密钥对，把私钥发给服务端，那么服务端需要为每个client保存一个密钥，这显然是不太现实的。所以只能由服务端生成密钥对，将公钥分发给需要建立连接的client。
HTTPS相比于HTTP，虽然提供了安全保证，但是势必会带来一些时间上的损耗，如握手和加密等过程，是否使用HTTPS需要根据具体情况在安全和性能方面做出权衡。
为什么要有HTTPS
无法验证报文的完整性和准确性。
将 HTTP 数据提交给 TCP 层之后，数据会经过用户电脑、WiFi 路由器、运营商和目标server，在这中间的每个环节中，数据都有可能被窃取或篡改
HTTP+加密+认证 == HTTPS
HTTP走server的80端口，HTTPS走443端口，那么，80端口没用了吗，当然有用，可以传输数据。443端口，只是建立连接的时候，处理协商数据，也就是TLS握手的过程。
HTTPS在传输数据之前需要client与server进行一个握手(TLS/SSL握手)，在握手过程中将确立双方加密传输数据的密码信息。主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密。
下面总结这个握手流程。
client发起HTTPS请求，连接443端口，提交支持的对称加密算法列表+client-random，server收到请求，和自己支持的加密算法进行比对，如果不符合，则断开连接。否则，server会把符合的算法+证书+service-random发给client，包括证书时间、证书日期、证书颁发的机构，公钥。
client验证证书，包括颁发证书的机构是否合法与是否过期，证书中包含的网站地址是否与正在访问的地址一致。保存公钥，client会生成一个随机字符串pre-master，然后用服务端的公钥进行加密，这里就保证了只有服务端才能看到这串随机字符串，并向server发送加密后的数据；最后server拿出自己的私钥，解密出数据，并返回确认消息，握手过程结束。
基本思路就是传输数据阶段依然使用对称加密，但是对称加密的密钥我们采用非对称加密来传输
数字证书有两个作用：一个是通过数字证书向浏览器证明server的身份，另一个是数字证书里面包含了server公钥。
数字证书，该证书包含服务端的信息，比如颁发者、域名、有效期，为了保证证书是可信的，需要由一个可信的第三方来对证书进行签名。这个第三方一般是证书的颁发机构，也称 CA（Certification Authority，认证中心）。
此时⼜带来⼀个问题，中间⼈问题：
如果此时在client和server之间存在⼀个中间⼈,这个中间⼈只需要把原本双⽅通信互发的公钥,换成⾃⼰的公钥,这样中 间⼈就可以轻松解密通信双⽅所发送的所有数据。如果中间⼈篡改了证书，那么身份证明是不是就⽆效了？这个证明就⽩买了，这个时候需要⼀个新的技 术，数字签名。
所以这个时候体限了CA的作用，证明身份，防⽌被中间⼈攻击。 证书中包括：签发者、证书⽤途、使⽤者公钥、使⽤者私钥、使⽤者的HASH算法、证书到期时间等
数字签名就是⽤CA⾃带的HASH算法对证书的内容进⾏HASH得到⼀个摘要，再⽤CA的私钥加密，最终组成数字签 名。
当别⼈把他的证书发过来的时候,再⽤同样的Hash算法,再次⽣成消息摘要，然后⽤CA的公钥对数字签名解密,得到CA创建的消息摘要,两者⼀⽐,就知道中间有没有被⼈篡改了。
这个时候就能最⼤程度保证通信的安全了。
那么这个证书的签名怎么检验真假呢？
要回答这个问题先要理解证书签名的过程。证书签名就是将证书信息进行 MD5 计算，获取唯一的哈希值，然后再利用证书颁发方的私钥对其进行加密生成。
校验过程与之相反，需要用到证书颁发方的公钥对签名进行解密，然后计算证书信息的 MD5 值，将解密后的 MD5 值与计算所得的 MD5 值进行比对，如果两者一致代表签名是可信的。所以要校验签名的真伪，就需要获得证书颁发方的公钥，这个公钥就在颁发方的证书中。
这种通过签名来颁发与校验证书的方式会形成一个可追溯的链，即证书链。处于证书链顶端的证书称为根证书，这些根证书被预置在操作系统的内部。
HTTPS是安全的。拿物流来比方， HTTPS 就是你把包裹包装得很安全； DNS劫持 就是有个人冒充快递来收单子了；
如果在client生成密钥对，把私钥发给服务端，那么服务端需要为每个client保存一个密钥，这显然是不太现实的。所以只能由服务端生成密钥对，将公钥分发给需要建立连接的client。
HTTPS相比于HTTP，虽然提供了安全保证，但是势必会带来一些时间上的损耗，如握手和加密等过程，是否使用HTTPS需要根据具体情况在安全和性能方面做出权衡。