HTTPS、对称/非对称加密、SSL/TLS

问题描述:HTTP的请求和响应都是明文传输,有安全隐患

HTTPS:HTTPS并不是一个单独的协议,是在 TCP 和 HTTP 之间加入了 SSL/TLS 安全协议,使得报文能够加密传输,SSL是TLS的前身,现在使用的大多都是TLS。

对称加密与非对称加密

对称加密 :发送方和接收方约定一个同样的规则也就是同一个密钥来对传输的信息进行加密和解密。
非对称加密:用两个密钥来进行加密和解密,公钥是所有人都可以得到的密钥,私钥是只有持有方才知道的密钥。一般情况下服务器拥有公钥和私钥,然后公布自己的公钥在网络上,客户端用这个公钥进行数据加密,此时只有服务器上的私钥才能进行解密。

TLS握手过程

TLS是同时使用了对称加密和非对称加密。

首先服务器需要向CA(证书授权中心)申请TLS证书来表明自己是经过验证的真实服务器,而不是伪造的。TCP三次握手的过程还是不变的,然后开始TLS握手。

  1. 客户端向服务器发送自己支持的TLS版本,支持的加密算法和一个随机数(第1个随机数)。
  2. 服务器响应自己确认的TLS版本,加密的算法和自己生成的一个随机数(第2个随机数),然后服务器继续发送自己的证书和公钥。
  3. 客户端验证了服务器的证书后,会生成一个预主密钥(第3个随机数),并且用收到的公钥加密然后发送出去。
  4. 服务器收到后用私钥进行解密得到客户端的预主密钥,此时只有客户端和服务器知道这个预主密钥是什么,除非私钥被泄漏了。
  5. 然后客户端和服务器都使用预主密钥+第1随机数+第2随机数 计算出一个会话密钥
  6. 也就是到了这一步,前面的加密都是非对称加密,目的就是得到这个会话密钥,之后的实际数据传输都使用这个会话密钥进行加密解密,所以正常的数据传输部分用的就是对称加密了。

HTTPS连接过程一定可靠吗

有这么一种情况,客户端通过浏览器向服务端发起 HTTPS 请求时,被「假基站」转发到了一个「中间服务器」,客户端是和「中间服务器」完成了 TLS 握手,然后这个「中间服务器」再与真正的服务端完成 TLS 握手。

从客户端的角度看,其实并不知道网络中存在中间服务器这个角色。那么中间服务器就可以解开浏览器发起的 HTTPS 请求里的数据,也可以解开服务端响应给浏览器的 HTTPS 响应数据。
但这有个前提,就是用户点击接受了中间服务器的证书。

因为中间服务器与客户端的 TLS 握手过程中,会发送自己伪造的证书给浏览器,而这个伪造的证书是能被浏览器识别出是非法的,于是就会提醒用户该证书存在问题。

相关推荐
傻啦嘿哟3 分钟前
开发者视角:应用程序中HTTP代理的集成指南
网络·网络协议·http
爱写代码的小朋友20 分钟前
IP 地址规划中的子网划分:/18 网络容纳 64 个 C 段(/24)的原理与应用解析
网络·网络协议·tcp/ip
十五年专注C++开发1 小时前
WebSocket原理详解(二)
网络·websocket·网络协议
JhonKI1 小时前
从零实现Json-Rpc框架】- 项目实现 - 服务端registry&discovery实现
网络协议·rpc·json
蜗牛沐雨2 小时前
MCP协议的Streamable HTTP:革新数据传输的未来
网络·网络协议·http
金丝猴也是猿2 小时前
如何在Flutter上实现高性能的动态模板渲染
websocket·网络协议·tcp/ip·http·网络安全·https·udp
swift开发pk OC开发2 小时前
Flutter性能优化细节
websocket·网络协议·tcp/ip·http·网络安全·https·udp
网络抓包与爬虫2 小时前
Flutter 环境搭建、常用指令、开发细节
websocket·网络协议·tcp/ip·http·网络安全·https·udp
IT成长日记2 小时前
Elasticsearch安全加固指南:启用登录认证与SSL加密
安全·elasticsearch·ssl
louisgeek3 小时前
MQTT 消息队列遥测传输
网络协议