https是如何保证安全的
在学习http与https的区别的时候，我们通常从以下几点出发：
-
http是超文本传输协议，是明文传输，有安全风险，https在TCP和http网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输
-
http连接简单，三次握手后即可传输，但是https在三次握手之后还要进行SSL/TLS的握手过程，才能加密报文传输
-
两者端口号不一样，http默认端口号是80，HTTPS默认端口号是443
-
https需要申请CA证书，需要付费
从上面的区别我们可以看出，我们使用https就是看中了他比较安全，但是他是如何确保安全的呢？
你可能会说，它不止进行TCP三次握手还要进行SSL/TLS握手，这样确保了它的安全性。
但是SSL/TLS是什么呢？它们又是怎样加密的呢？
SSL和TLS
-
SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名保证完整性、使用加密确保私密性，以实现客户端和服务端之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。 -
TLS：（Transport Layer Security，传输层安全协议），用于两个应用程序之间提供保密性和数据完整性。
SSL和TLS是一种能够在服务器，machines和通过网络运行的应用程序（例如，客户端连接到web服务器）之间提供身份认证和数据加密的加密协议。SSL是TLS的前世。多年来，新版本的发布用来解决漏洞，提供更强大支持，更安全的密码套件和算法。
为什么要使用SSL/TLS？
因为HTTP是明文传输，所谓明文，就是说客户端和服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容
所以会存在以下三个风险：
-
窃听风险，第三方可以获取通信内容
-
篡改风险，第三方可以修改通信内容，比如强制植入垃圾广告
-
冒充风险，第三方冒充他人身份进行通信
HTTPS在HTTP与TCP之间加入了TLS协议，来解决上述风险。
TLS是如何解决上述风险的呢？
-
信息加密：HTTP交互信息是被加密的，第三方就无法被窃取
-
校验机制：校验信息传输过程中是否有被第三方篡改过，如果被篡改过，则会有警告提示；
-
身份证书：验证所要访问网站的证书，判断其真实性
TLS的握手过程
加密方式
传统的TLS握手基本上都是使用RSA算法来实现密钥交换的，服务端将自己的公钥在TLS的握手阶段 传递给客户端，服务端的私钥一直留在自己这，一定要确保私钥不能被窃取。
在RSA密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对称加密算法，公钥加密的消息仅能通过私钥解密，这样服务器解密后，双方就得到了相同的密钥，再用它加密应用消息。
那么如何确保自己的公钥不被篡改的呢？这就是我们前面所说的CA证书，将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
TLS第一次握手
客户端会先向服务器打个招呼【Client Hello】，消息里面有客户端使用的TLS版本号、支持的密码套件列表，以及生成的随机数1，这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。
TLS第二次握手
当服务器收到客户端的【Client Hello】消息后，会确认TLS版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数。然后返回【Server Hello】消息，消息里面有服务器确认的TLS版本号，也给出了随机数2，然后从客户端的密码套件列表选择一个合适的密码套件。
然后，服务端为了证明自己的身份，会发送【Server Certificate】给客户端，这个消息里含有数字证书。
接着，服务端发送【Server Hello Done】给客户端，目的是，我已经把该给你的东西都发给你了，本次打招呼完毕。
TLS第三次握手
客户端验证完成证书后，认为是可信的，就会生成一个新的随机数，用服务器的RSA公钥加密该随机数3，通过【Client Key Exchange】消息传给服务端。
服务端收到之后，用RSA私钥解密，得到客户端发送的随机数
到这，双方都已经得到了三个随机数，生成会话密钥，它是对称加密，用于对后续的HTTP请求/响应的数据加解密。
生成完会话密钥后，然后客户端发一个【Change Cipher Spec】，告诉服务端开始使用加密方式发送消息。
然后，客户端再发一个【Encrypted Handshake Message（Finished）】消息，把之前所有发送的数据做个摘要，再用会话密钥加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过
在【Change Cipher Spec】之前握手数据都是明文传输的，之后都是对称密钥加密的密文。
TLS第四次握手
服务器也是同样的操作，发【Change Cipher Spec】和【Encrypted Handshake Message】消息，如果双方都验证加密和解密没问题，那么握手正式完成。
最后，就会用【会话密钥】加解密HTTP请求和响应了。
————————————————
版权声明：本文为CSDN博主「小茹想睡觉」的原创文章
原文链接：https://blog.csdn.net/Rice_w/article/details/129766938
原文始发于微信公众号（前端24）：https是如何保证安全的
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/216421.html
