随着建站成本的日益降低,使用Https的成本也随之下降。现在大部分网站都支持了Https,那么什么是Https?Https与Http有什么区别?Http又是如何保证通信安全的呢?本篇文章,我们将会从实战的角度解读上述问题。本文分为以下几个部分:
- 前言
- TCP/IP网络模型
- TCP&UDP
3.1 TCP
3.1.1 三次握手
3.1.2 四次挥手
3.1.3 TCP的特点
3.1.4 抓包验证
3.2 UDP- Http
4.1 Http请求的流程
4.2 Http请求抓包的验证- Https
5.1 为什么Https要存在
5.2 解决问题的尝试
5.2.1 能否使用对称加密
5.2.2 能否使用非对称加密
5.2.3 能否使用对称加密&非对称加密
5.2.4 中间人攻击
5.2.5 CA 认证
5.3 Https请求流程
5.4 数据包分析- 总结
1. 前言
Http协议作为目前互联网中使用最多的网络协议,掌握其工作原理是必备技能。而Https作为Http的安全版,同样是工作和面试的热点问题。要搞清楚Https,需要先搞清楚Http,而要搞清楚Http,先要搞清楚网络模型,搞清楚TCP&UDP。所以下面的文章,会按照TCP&UDP->HTTP->HTTPS这个顺序来进行。在开始正文之前,老规矩先提出几个问题:
- Q1:TCP和UDP的区别?
TCP和UDP都是传输层的协议,不同的是TCP是可靠通讯协议,UDP是不可靠通讯协议。
- Q2:TCP三次握手的过程是什么?
c->s syn,s->c ack syn,c->s ack
- Q3:为什么要握手?又为什么是三次,而不是两次或者四次?
握手(双方互相告知序列号起使值,并确认对方收到)序列号起使值的过程)就是为了保证可靠传输
。之所以是三次,不是两次是因为最少要三次才能确认通信双方都能正常收发
。之所以不是四次,是因为三次就能保证双方的正确性,没必要四次浪费资源。
- Q4:TCP是如何做到可靠的?
通过序列号确认(下面会详细分析)
- Q5:Http的请求流程?
下文会详细分析
- Q6:Https的请求流程?
下文会详细分析
- Q7:什么是中间人攻击?
Man-in-the-MiddleAttack,简称MIT攻击”
- Q8:什么是CA认证?
电子认证是指为电子签名相关各方提供真实性、可靠性验证的活动
- Q9:为什么我未在浏览器上安装Server端证书,却能正确发送Https请求?
证书在建立连接的过程中通过网络传输
- Q10:有了Https就一定是安全的吗?
并不一定
2. TCP/IP网络模型
继续下面的内容前,我们先明确两个概念:
- 网络模型:试图规范网络中的模型、推动网络普及的概念模型。将网络从通信介质传输到应用层实现分层划分。每个中间层为其上一层提供功能,其自身功能则由其下一层提供。
- 网络协议:计算机与网络设备之间要通信,双方就要基于相同的方法,比如通信语言、通信如何发起、通信如何结束等,这些约定的规则就是通信协议。
网络模型的每个层级都有不同的网络协议实现。网络模型是一种抽象的概念,网络协议是具体的实现。
- OSI七层模型
OSI 即 open system interconnect(开放网络互联模型),是由ISO(国际标准化组织)研究的网络互联模型,为的是规范网络中的模型、推动互联网普及。
OSI七层模型将网络从最底层的物理传输介质到最上层的应用,划分为7层,按照层级由下到上的关系分别为:
- 物理层:最底层,包括物理联网媒介,如电缆连线连接器。(
IEEE802.2
) - 数据链路层:提供介质访问和链路管理。(
ARP、PPP
) - 网络层:IP地址及路由选择。(
IP、ICMP、RIP、OSPF
) - 传输层:建立、管理、维护端到端的连接。(
TCP、UDP
) - 会话层:建立、管理和维护会话。
- 表示层:数据格式转化、数据加密。
- 应用层:为应用层序提供服务。(
HTTP、HTTPS、FTP、Telent、SSH、SMTP、POP3
)
- TCP/IP 五层模型
TCP/IP是一组协议簇的总称,常见的互联网协议如:HTTP、HTTPS、Telnet、SMTP、DNS、TCP、UDP都属于该协议簇。TCP/IP模型将网络自下而上分为:物理层、数据链路层、网络层、传输层、应用层
- TCP/IP五层模型的协议分布
-
TCP/IP五层模型与OSI七层模型的对比
- 数据在TCP/IP协议中的传输
假设我们有个服务端接收消息接口用来接收客户端上传的信息,那么从客户端发送到服务端接收这个过程发生了什么呢?
客户端
:
- 通过Http协议组装消息,并将消息交给传输层。
- 传输层(TCP)接到消息后,会根据消息的大小选择将一个消息进行拆分成多个数据包,或者将多个消息组合成一个数据包,并在每个包的包头加上TCP包头(包含目标端口号),将包头和Http包生成完整的TCP包,然后将TCP数据包交给网络层
- 网络层(IP)在拿到TCP的包后,在TCP包的前端加上IP包头,生成IP包(包含目标ip地址),并传给物理层网卡。
- 物理层(以太网)在收到IP包后,会在IP包前加上以太网的包头(包括mac地址)作为完整的以太网数据包,通过物理介质发送个目标主机。
服务端
- 物理层(以太网)在收到以太网数据包后,会根据mac地址判断是否是发送给自己的包,如果是发送给自己的包,则转给网络层处理。
- 网络层在拿到IP包后,根据IP包头做相应的处理,然后转给传输层处理。
- 传输层在拿到完整的传输层包后,也会根据包头做处理,如校验数据是否丢失、确定目标端口对应的应用层序。没问题后,将数据包转给对应的应用层。
- 应用层接收到相应的数据,进行数据解析,处理,并按照发送的过程再给出响应。
3. TCP & UDP
TCP&UDP都是传输层的协议,不同的是TCP是可靠性传输协议,而UDP不可靠。先上一个完整的对比:
特性 | TCP | UDP |
---|---|---|
面向连接 | 面向连接 | 无连接 |
可靠性 | 可靠,有拥塞控制和ack | 不可靠,没有拥塞控制和ack |
连接对象个数 | 单播 | 单播,多播,光播 |
传输方式 | 字节流 | 报文 |
头部开销 | 20个字节 | 8个字节 |
适用场景 | 可靠性要求高,如文件传输 | 实时性要求高,可靠性要求不高,如视频电话 |
3.1 TCP
TCP(传输控制协议 Transmission control Protocol)是一种面向连接的,可靠的、基于字节流的传输层通信协议。从协议的定义,我们也能很明显发现协议的特点,可靠&面向连接,当我们需要保证传输的可靠性的时候,比如下载文件我们希望下载的是完整的文件而不是部分文件,再比如我们浏览网页,我们希望是按照顺序完整的展示网页的内容,而不是乱序的部分内容,在这些场景中,我们就可以使用TCP协议。那么TCP是如何保证可靠性的呢?可以从TCP连接的建立和断开中找到答案。
3.1.1 三次握手
三次握手过程
- 第一次握手:
客户端向服务端发送SYN报文,请求建立连接,随后进入SYN-SENT状态
。 - 第二次握手:
处与Listen状态的服务端收到客户端的SYN报文后,回复SYN,ACK报文,表示“收到客户端的请求,同意建立连接”,随后进入SYN-RCVD状态
。 - 第三次握手:
处于SYN-SENT状态的客户端收到服务端响应后,发送ACK报文,表示“客户端收到服务端同意建立连接的响应”,随后进入ESTABLISHED状态
。 -
服务端收到客户端的响应后,也进入ESTABLISHED状态,此时连接建立
。
为什么不是两次握手?
可能看到上面的过程,我们不经有个疑问,为什么不是两次握手呢?答案是要确认客户端和服务端都是可以正常收发的状态,这样可以避免以下两个情况1)避免服务端开启无用的连接增加服务器的开销 。2)避免已失效的连接请求报文突然又传到了服务器,产生错误
。
- 避免服务端开启无用的连接增加服务器的开销
假设第二次握手后就建立连接,则过程可能如下:- 客户端发送syn
- 服务端发送syn,ack 并建立连接
- 客户端由于网络原因,迟迟未收到服务端响应,超时重试
- 客户端发起新的syn,之前服务端建立的连接无人使用,浪费资源
- 避免已失效的连接请求报文突然又传到了服务器,产生错误
同样假设第二次握手后就建立连接,则过程可能如下:- 客户端发送syn
- 客户端发送的报文由于网络延迟,未送达服务端。
- 客户端重试,第二次发送syn
- 第一次发送的syn和第二次发送的syn都到达服务端,服务端建立两个连接,并回复两个syn,ack
- 对于客户端而言,显然第一次的syn是废弃掉的,但服务端却为此创建了一个连接
为什么不是四次握手?
那么既然两次握手不行,为什么不是四次握手呢?那是因为三次握手已经能确保通信双方都是可以正常收发,并能正确确认双方的序列号的。那么就没必要进行第四次握手来浪费资源了
。
三次握手的通俗场景模拟
三次握手版
三胖和川普进行会面,要进行握手
三胖伸出手:川普你看,我手里没有武器,我很有诚意,我们握个手吧(SYN)
川普看了看三胖的手说:嗯,你手里确实没有武器。然后伸开手说,你看我也没有武器。(SYN,ACK)
三胖看了看川普的手说:确实你也没武器,你也有诚意,坐下来谈,别客气(ACK)。
两次握手版
三胖伸出手:川普你看,我手里没有武器,我很有诚意,我们握个手吧(SYN)
川普看了看三胖的手说:嗯,你手里确实没有武器。
三胖高兴的伸出手和川普握手,但是此时川普却从手里拿出了手枪,三胖卒.....
四次握手版
三胖和川普进行会面,要进行握手
三胖伸出手:川普你看,我手里没有武器,我很有诚意,我们握个手吧(SYN)
川普看了看三胖的手说:嗯,你手里确实没有武器。然后伸开子的手说,你看我也没有武器。(SYN,ACK)
三胖看了看川普的手说:确实你也没武器,你看我也没武器的,说完又伸出了手。
川普心想,三胖莫不是个傻子......
三次握手的关键是,确认通信双方都有正常收发的能力,这样才能确认序列号,才能尽可能保证TCP的可靠性
3.1.2 四次挥手
上面说了连接建立的过程(三次握手),那么连接断开是怎么样的一个过程呢?
- 第一次挥手:
客户端向服务端发送FIN报文,请求释放TCP连接
。并随之进入FIN-WAIT-1状态,并停止向服务端发送业务数据,但是此时是可以正常收到服务端数据的。 - 第二次挥手:
服务端收到客户端的释放连接请求后,知道了客户端想要释放连接,随后结束ESTABLISHED状态,进入CLOSE-WAIT状态,并返回了ACK报文
。由于[图片上传中...(四次挥手.gif-dfaef1-1609220464082-0)]
是全双工协议,此时服务端还可以继续向客户端传输数据。客户端收到ACK后,知道服务端同意释放连接,则进入FIN-WAIT-2状态。 - 第三次挥手:
服务端经过CLOSE-WAIT,做好了释放连接的准备后,向客户端发送FIN,ACK报文
,此时服务端进入LAST-ACK阶段,并停止服务端向客户端方向的数据发送,但是此时仍可以收到客户端数据。 - 第四次挥手:
客户端在收到服务端FIN,ACK报文后,知道可以释放连接了。就进入了TIME-WAIT状态,并回复ACK报文。等待2MSL(两个最大段的生存周期),如果这个时间段未收到服务端的重发请求,则进入Closed状态,服务端在收到客户端的ACK报文后,立即进入closed状态
。
为什么需要握手需要三次,而挥手却需要四次?
握手的时候,因为最少通过三次请求,才能确认双方都是正常收发的状态。
- 挥手的步骤中,第一步客户端发起断开请求不能少,第二步服务端回复ACK告诉客户端收到断开请求也不可少,第四部:客户端收到服务端FIN,ACK后进入time-wait状态也必不可少,至少为三步,那么为什么需要第三步的挥手呢?因为
服务端在收到客户端断开请求后,并不能立即断开连接,因为可能数据还在处理中,并未传输完毕,所以要有第三步,数据处理完后通知客户端可以断开连接的过程即FIN,ACK报文
。所以挥手是四次
为什么客户端要在TIME-WAIT状态等待2MSL?为什么不能直接CLOSED?
这么做是为了确保服务端正确收到客户端的ACK报文
。
- 服务端会在1MSL内未收到客户端的ACK报文后,重新给客户端发送FIN,ACK报文
- 客户端如果在2MSL内重新收到服务端的FIN,ACK报文,说明服务端没收到客户端的ACK,则客户端重新发送ACK,计时器重置,重新开始2MSL的计时。
- 客户端如果在2MSL未收到服务端的FIN,ACK报文,说明服务端正常收到客户端的ACK,则客户端进入CLOSED状态,四次挥手结束。
四次挥手的通俗场景
女盆友:彦祖,该出发,看电影马上要迟到了
我:好的,我知道了,我打完这把农药
我:好了,我打完了,我们出发吧
女朋友:好的,走吧
四次挥手的关键,是服务端在准备好释放连接的时候,主动发送FIN,ACK通知客户端
3.1.3 TCP的特点
- 面向连接
TCP的传输数据是在建立连接的前提下,而连接又为可靠性做了基础保证。 - 全双工通信
TCP的客户端和服务端都能同时发送数据,而不像HTTP协议的半双工,同一个时刻只能有一端发送数据 - 可靠性
TCP通过序列号和确认号保证了可靠性,即每次发送数据包添加序列号,接收方在接收数据的时候按照序列号接收,同时回复一个ACK确认号,这样就保证了接收的顺序和明确了数据包是否送达,如发送的数据在合理的延迟(RTT)内未送达,则重传。 - 拥塞控制
当网络出现拥堵的时候,TCP能调整网络注入数据的数量和速度,降低拥塞。 - 面向字节流
TCP将数据包以字节流的方式传输。 - 仅支持单播
不支持多播和广播
3.1.4 抓包验证
上面我们说了TCP三次握手和四次挥手的过程,下面我们用wireshark抓包来验证下上面的流程。
以请求接口地址:http://www.moxieliunian.com/images/1.jpg为例
-
三次握手
-
第一次握手,客户端发送SYN
1)代表的是传输层协议(包含源端口和目标端口),2)代表的是网络层传输协议(包含源IP和目标IP),3)代表的是数据链路层协议(包含源mac地址和目标mac地址),4)代表的是物理层协议,5)当前序列号 347723889,6)当前确认号为0,7)标识为SYN
- 第二次握手,服务端发送SYN,ACK
第二次握手的ack=347723889+1=347723890,seq=2517807223
- 第三次握手,客户端发送ACK
第三次握手,ack=2517807223+1=2517807224,seq=347723890
- 四次挥手
当一个Http请求结束,我们不做任何操作之后,TCP 会通过TCP Keep-Alive 来探测连接是否存活,如果到一定的超时时间,则服务端会发起关闭连接。
所以我们可以看到第一次挥手连接关闭是由服务端发起的。
-
第一次挥手,服务端发送FIN,ACK
-
第二次挥手,客户端回复ACK
-
第三次挥手,客户端回复FIN,ACK
-
第四次挥手,服务端回复ACK
因为这里发起连接关闭的是服务端,所以上面的客户端顺序和3.1.2 中我们所说的是相反的
3.2 UDP
UDP即用户数据报协议,和TCP一样同为传输层协议,提供了一种无需建立连接就可以发送封装的ip数据包的方法。不提供数据包分组、组装、排序的功能,也就是说无法感知数据包是否正确送达。它有以下几个特点:
-
无需建立连接
。也就说发送数据时无需通过三次握手建立连接,想发数据就可以开始发送,并且也不会对包进行任何的加工,除了添加UDP包头来标识它是一个UDP数据包 -
UDP是面向报文的
。UDP对应用层给到的报文,即不拆分,也不组合,直接保留原始报文的边界,应用层序必须选择大小适合的报文 -
UDP是不可靠的
。UDP的不可靠体现在三点:1)无需提前建立连接,都不知道接收方能否正常接收就发送数据,肯定是不可靠的。2)没有ack机制,无法确认包是否正确送达。3)没有拥塞控制,网络不好的时候,可能会导致丢包。 UDP不仅仅支持单播,还支持多播和广播
UDP适合用在对实时性能要求高,但对可靠性要求不高的场景,如视频会议等
4. Http
Http 协议,即超文本传输协议,是一个基于TCP/IP协议之上的,应用层的通信协议。Http协议作为我们最常使用的协议,其请求的流程是怎么样的呢?
4.1 Http请求的流程
当我们在浏览器中,输入http://www.baidu.com的时候到底发生了什么呢?
- 域名解析。即将www.baidu.com 转换为 180.101.49.11:80的过程。
- 从浏览器DNS缓存中查找域名解析记录
- 如上面未找到,则从操作系统DNS缓存中查找域名解析记录
- 如上面未找到,则从host文件中查找域名对应的ip
- 如上面未找到,则请求配置的首选dns server查找域名对应ip(通过udp向dns server的53端口请求。这个过程是递归请求的)
- 发起TCP三次握手
- client---->server SYN seq=x(客户端请求建立连接,并且序列号为x)
- server------>client SYN,ACK seq=y,ack=x+1(服务端同意建立连接,并且期待下次的序列号为x+1)
- client-------->server SYN seq=x+1,ack=y+1(客户端已经收到服务端同意建立连接的响应,并且期待下次服务端发送的序列号为y+1)
- 三次握手建立连接后,发起Http请求
- 服务器端响应Http请求,浏览器得到Html代码
- 浏览器解析Html代码,请求Html中引入的资源
- 浏览器对页面进行渲染,呈现给用户
- 连接超过keep-alive时间,四次挥手,关闭连接
4.2 Http请求抓包的验证
上面我们已经用wireshark抓了TCP三次握手的包,这里就不再赘述了。
- 客户端发送SYN
- 服务端发送SYN,ACK
- 客户端发送ACK
- Http request
- Http response
通过分析Http的数据包,我看可以看到:Http是基于TCP协议的,同时Http是明文传输的
。明文传输,也就意味着数据能轻易的被抓取和篡改。那么有什么解决办法吗?即下面要说的Https
5.Https
Https是在Http的基础上加了一层SSL,是基于Http+SSL实现的安全的Http协议。概括来说就是Http报文在组装好给到TCP之前,先经过TLS加密。接收方TCP在接收到数据后,在将数据返回上层HTTP之前,先将数据进行TLS解密
。
5.1 为什么Https要存在
正如我们上面抓包演示的那样,Http是明文传输的,极度不安全,容易被窃听、串改、冒充,因此诞生了Https。
5.2 解决问题的尝试
上面我们说因为Http是明文传输,所以要Https,那么直接加密(对称和非对称)不就行了吗?
5.2.1 能否使用对称加密
我们尝试直接使用对称加密来解决这个问题。所谓对称加密,即加密和解密用的是同一个密钥
先看下构想图:
假如
黑客在数据传输的过程中拦截到我们的密文报文,是否我们的报文就是安全的呢
?显然是
不安全的
,问题的原因如下:
- 服务端在制定key的时候,并不知道未来客户端的数量,无法为每个客户端制定单独的key。其次为每个客户端存储单独的key,有的时候key的数量反而比业务数据更大,得不偿失,所以只能公用一个key。
- 黑客冒充正常的客户端,同样也可以拿到公用key。此时就可以解密拦截的数据,从而篡改数据。
所以对称加密不可行
5.2.1 能否使用非对称加密
既然对称加密行不通,我们自然会想到非对称加密。是否可行呢?
先看下构想图:
非对称加密同样是不可行的,这是因为所有人包括黑客都能拿到公钥,虽然黑客无法解密客户端发送服务端的数据包,但是黑客可以用公钥解密服务端发送客户端的响应报文
,同样不安全。
5.2.3 能否使用对称加密&非对称加密
上面的分析,我们可以看到,对称加密的缺点是所有客户端公用一个key,而非对称加密的缺点是服务端给客户端发送响应报文时不安全。那么能不能综合两者,得出一个唯一key从而来解决问题呢?
这种方式看起来很完美,每个客户端都有一个唯一的key num1,黑客因为没有私钥无法得到解密y得到唯一的num1。那么是不是真的万无一失了呢?
5.2.4 中间人攻击
5.2.3 中的处理方式,存在一个致命的错误,中间人攻击,即Man-in-the-MiddleAttack,简称“MITM攻击”
。如果黑客在客户端请求pk的时候就拦截了请求怎么办呢?
- 客户端请求pk。
- 黑客拦截请求返回自己的pk1(黑客持有自己的密钥对 pk1,sk1)
- 黑客请求pk,服务端返回pk,黑客记录pk。
- 客户端用pk1加密随机对称密钥num1,发送服务端。
- 黑客拦截num1,并用sk1解密,得到num1。
- 黑客用pk加密num1,发送给服务端。
- 客户端使用num1 加密数据发送给服务端
- 黑客拦截num1加密的后的数据,并用num1 解密,篡改数据后,再用num1加密发给服务端。
可以看到,黑客在这个请求流程中,充当了一个中间人的角色,因为他能得到了num1,也就意味着他能随意的篡改数据。
总结
对上面的几种加密方式做个总结
不加密=明文=裸奔
对称加密:key唯一=明文
-
非对称加密:客户端发送服务端时安全,服务端响应客户端时不安全
。 -
非对称加密+对称加密:无法预防中间人攻击
。
5.2.5 CA 认证
那么就没有一种安全的方式了吗?5.2.4中我们可以看到,中间人攻击的根本原因就是pk在网络上的传输,那么如果我们不在网络中传输pk呢
上面的流程有两个前置条件:1. CA机构提前用自己的私钥对服务器的pk进行加密,得到license,并且CA机构一定是可信的。2. 用户的操作系统里提前写入了CA系统的公钥cpk,可以通过cpk解密license,得到pk。那么如果上述的流程中黑客介入了会怎么样呢?
- 步骤1和步骤2请求license时,黑客介入,返回被劫持后的证书,则利用操作系统的cpk解密会失败,浏览器会提示不安全。
- 步骤3时黑客介入,因为黑客没有sk,故黑客无法解密得到num1。
- 步骤4时黑客介入,因为黑客没有num1,故黑客无法解密篡改数据。
可以看到利用CA认证,就解决了中间人攻击的问题
。因为非对称加密比较耗时,先利用非对称加密协商出唯一key,再利用唯一key做数据加密传输也解决了性能问题
。
5.3 Https请求流程
Https 相对于Http多了一步TLS握手的过程。其中TLS握手的流程如下
- Client Hello。
客户端向服务端发送支持TLS版本,支持的加密算法,以及随机数1
。 - Server Hello。
服务端向客户端发送使用的TLS版本、使用的加密算法、随机数2
。 - Server certificate,Server Key Exchange,Server Hello Done。
服务端向客户端发送证书,协商密钥的报文,以及首次握手结束的通知
。 - Client Key Exchange ,Change Cipher spec,Encrypted HandShake Message。
客户端在收到服务端Server Hello Done 的报文后,进行证书的验证
,验证的因素包括:证书链是否可信、证书是否吊销、证书有效期、域名。如果验证通过后,给服务端发送协商密钥的报文
。
4.1 Client Key Exchange:客户端计算产生随机数字3,并且将随机数字3用服务端公钥加密后发送服务端。客户端用随机数1和随机数2结合随机数字3,计算得出协商密钥。
4.2 Change Cipher spec:客户端告诉服务端后续的通信都用协商密钥进行加密通信
4.3 Encrypted HandShake Message:计算前面向服务端发送的数据生成一个hash作为摘要,并用协商密钥加密后发送给服务端做验证 - Server Change Cipher spec,Encrypted HandShake Message。
服务端在收到客户端的随机数字3后,用私钥进行解密后,然后根据随机数1和随机数2结合随机数3,生成协商密钥。然后将前客户端发过来的所有参数进行hash之后,比较摘要是否相同,从而验证握手是否合法
。验证之后向客户端发送数据包。
5.1 Change ciper spec:服务端告诉客户端以后通信都采用协商密钥进行加密。
5.2 Encrypted HandShake Message: 服务端经自己已经发送给客户端的数据进行hash摘要后,发送给客户端做有效性认证。 - Application Data。
安全连接建立,发送加密数据
。
上面的过程简单概括就是两件事服务端向客户端传输证书,两端共同商量出一个唯一密钥
。
5.4 Https 数据包分析
抓包验证一下上面的TLS握手过程。
- Https请求数据包总览
- 1.客户端发送支持的加密套件给服务端。
- 2.服务端发送支持的加密套件给客户端 。
- 3.服务端向客户端发送证书、协商密钥的报文及首次握手结束的通知。
- 4.客户端验证服务端的证书,验证通过后利用前面的信息生成唯一密钥,之后发送给服务端并通知服务端切换加密方式。
-
- 服务端利用相同的方法生成唯一密钥,并校验握手的合法性,然后回复客户端切换加密方式。
- 6-7 安全连接建立,发送加密数据。
- 客户端向服务端发送支持的加密套件和随机数
- 服务端向客户端发送支持的加密套件和随机数
-
服务端向客户端发送证书、协商密钥的报文及首次握手结束的通知。
4.1 服务端向客户端发送证书
4.2 服务端向客户端发送协商密钥的报文及首次握手结束的通知 -
客户端生成唯一密钥,并通知服务器切换加密方式
- 服务端校验握手的合法性,并得到唯一密钥,同时通知客户端切换加密方式
- 连接建立,加密数据传输
6. 总结
这篇文章里我们只说了一个问题:Https是怎么做到数据安全的,为了介绍这个,我们先铺垫了 网络模型、TCP&UDP、Http。同样,提出几个问题对上面的内容做个总结:
1. Https的请求流程是怎么样的?
- 客户端发送支持的加密套件和随机数
- 服务端发送支持的加密套件和随机数
- 服务端发送证书给客户端,同时选取合适的加密套件,然后通知客户端首次握手结束
- 客户端验证服务端的证书后得到公钥,同时利用上面的随机数生成唯一密钥,然后将唯一密钥用公钥加密后发送给服务端,并通知改变加密方式
- 服务端利用上面的随机数生成密钥,然后比较解密后的密钥和当前密钥,从而确定握手的合法性。之后通知客户端改变加密方式。
- 安全连接建立,数据传输。
2. Https 是如何保证安全性的?
- Https 引入了CA,保证了能得到合法的公钥,可以有效的
防止篡改,防止监听、防止伪造
。
3. 既然Https是安全的,是不是就不会被抓包了呢?
- Https只是保证了被抓取的数据包是加密的,但是并不能保证不被抓包
4. 有没有办法抓取并解析Https 加密数据包呢?
- 通过将浏览器协商的密钥保存到外置文件中,用抓包工具如wireshark配合这个外置的文件就可以捕获到当前加密的数据包。
5. CA证书干啥用的?
- CA证书防止中间人攻击,可以保证客户端得到服务端正确的公钥。
6. 既然有了Https 那我们接口还要做额外的安全处理吗?
- 当然需要了,Https是作用于协议层面的,一般加解密的工作都是web容器来做的,而接口的加解密取决于具体的业务逻辑。就好比办公室的大门上了锁,个人的抽屉难道就不需要上锁了吗。
水平有限,本文只是对Https做了粗浅的解读,难免有所疏漏,欢迎批评指正。我们下篇文章见.....
话说写文章,真的是费时费力。每次看到个位数的阅读,不禁潸然泪下....
参考文章:
https://baijiahao.baidu.com/s?id=1654225744653405133&wfr=spider&for=pc
https://blog.csdn.net/lengxiao1993/article/details/82771768
https://www.cnblogs.com/fundebug/p/differences-of-tcp-and-udp.html