当前位置: 首页 > article >正文

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的握手过程

  1. 加密方式

传统的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请求和响应了。

参考1

参考2


http://www.kler.cn/a/3567.html

相关文章:

  • java开发,IDEA转战VSCODE配置(mac)
  • Java实现微店商品详情接口调用的完整指南
  • pikachu靶场-敏感信息泄露概述
  • 【深度学习】Java DL4J 2024年度技术总结
  • OSPF协议部分解读
  • XCode-Color-Fixer 常见问题解决方案
  • 电脑长按电源键强行关机,对SSD有伤害吗?SSD 掉盘之殇
  • 网络安全 2023 年为什么如此吃香?事实原来是这样....
  • 大数据项目之数仓相关知识
  • PLG SaaS 案例:如何实践外链自动增长策略?
  • MongoDB数据库从入门到精通系列之十:MongoDB数据库备份之文件系统快照
  • SpringBoot 解决id使用字符串类型可以解决精度问题
  • C++ Primer第五版_第六章习题答案(41~50)
  • 【数据结构篇C++实现】- 堆
  • python 使用pyshp读写shp文件
  • 3.数组算法、动态规划
  • 模型压缩-网络量化概述
  • 3.OSPF与BGP的联动
  • 我用Python django开发了一个商城系统,已开源,求关注!
  • python flask项目部署
  • 电路基础_模拟电路_问答_2023_01
  • JSON.stringify() 的 5 种使用场景
  • 【Docker】MAC电脑下的Docker操作
  • SQL注入之HTTP请求头注入
  • 浅谈计算机视觉HALCON视觉库识别车牌号
  • 【TopK问题】——用堆实现