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 握手过程中,会发送自己伪造的证书给浏览器,而这个伪造的证书是能被浏览器识别出是非法的,于是就会提醒用户该证书存在问题。

相关推荐
Derrick__13 小时前
Python网络编程——TCP编程
python·网络协议·tcp/ip
小杨的全栈之路5 小时前
生产级实践:在 Docker 中安全导入自签名证书,保障 Spring Boot 应用通信安全
docker·https
2503_924806856 小时前
海外IP的适用业务范围
网络·网络协议·tcp/ip
-快乐的程序员-7 小时前
simple websocket用法
网络·websocket·网络协议
半桔8 小时前
【网络编程】网络通信基石:从局域网到跨网段通信原理探秘
linux·运维·网络协议·php
沐浴露z9 小时前
【深入理解计算机网路07】详解局域网:以太网、VLAN与无线局域网
网络·网络协议·计算机网络·408
00后程序员张10 小时前
苹果软件混淆的工程逻辑,从符号空间到资源扰动的体系化实现
android·ios·小程序·https·uni-app·iphone·webview
XUE-521131419 小时前
路由策略与路由控制实验
运维·网络·网络协议·智能路由器
加油201919 小时前
如何快速学习一个网络协议?
网络·网络协议·学习·方法论
coder4_20 小时前
OpenSSL 加密算法与证书管理全解析:从基础到私有 CA 实战
https·openssl·ssl/tls·加密算法·ca证书