若是还没尝试过使用wiresharp
的话,能够参照我以前写过的文章《wireSharp的基本用法》。git
本篇文章不会详细说TLS
的内容,请结合我上一篇文章《深刻TLS/SSL协议》一块儿观看。github
TLS1.2
中的握手过程主要有三个目的:算法
如图所示:
一、客户端发送一个Client Hello
,包含:数据库
Client random
。二、服务器回一个Server Hello
,包括:浏览器
server
所选择的安全套件。server
发送本身的数字证书-server Certificates
。server
发送本身生成的公钥-serverKey
。三、客户端发送本身生成的公钥-clientKey
。
四、客户端与服务器根据本身的私钥与对方的公钥生成对称加密的密钥。
五、进行加密通信缓存
下面抓取www.juejin.im
为例:
安全
一、Client hello
:
服务器
Version:TLS 1.2
Random
二、Server hello
中:
session
协议版本号Version:TLS 1.2
dom
选中了一个安全套件:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
随机数Random
发送数字证书:
发送server
的公钥以及所用的签名算法:
三、Client
发送本身的公钥
四、client
与server
根据本身的私钥与对方的公钥生成对称加密的密钥
五、Change Cipher Spec
这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的密钥加密了并通知server
握手结束。
六、Change Cipher Spec
这一步是服务端通知客户端后面再发送的消息都会使用加密并通知client
握手结束。
TLS1.3
中,大大减小了所支持的安全套件。好比在openssl1.1
中只支持5种安全套件
TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS-AES-128-GCM-SHA256
TLS-AES-128-CCM-8-SHA256
TLS-AES-128-CCM-SHA256
TLS1.3
握手的变化:
因为安全套件的减小,client
能够在第一次请求中将5种安全套件所有生成一对密钥,将5种publicKey
发送给server
,而后server
选择其中一种安全套件来生成本身的一对密钥。从而相比上面说的TLS1.2的握手过程减小了一次RTT
。
TLS
握手中消耗的那一个或两个RTT
时间是对于安全性而言的。
但对于应用层的信息传递而言并无意义。
因此TLS
提供了许多种手段来减小握手过程当中所消耗的RTT
的时间。好比:session
缓存、ticket
票据等
第一次握手后服务器会生成一个sessionID
,而后传给浏览器。
在必定时间内,好比几个小时、几天内。浏览器携带这个sessionID
再次访问服务器时,服务器会从缓存中提取这个sessionID
所指向的加密密钥。没有必要再次根据ECDH
协议生成新的密钥,从而减小消耗的RTT
时间。
下面以百度站点为例:
当再次访问百度站点时,client hello
就会携带一个sessionID
:
而client Hello
步骤以后直接到了Change Cipher Spec
。并无进行DH
或者ECDH
密钥交换协议
Change Cipher Spec
里面就告诉Client
,使用以前的密钥
与sesion
机制不一样的是,ticket
机制不须要server
花费缓存来存放。而是基于一个独特的密码,这个密码是集群中所共享的。基于这个密码将ticket
解密后,就能够获取到上一次生成的密钥。
所谓0RTT
,指的是:第一次请求时就携带GET
数据,在一次RTT
后就立刻获得RESPONSE
。握手时间就是0RTT
了。
事实上这也是第二次握手中才有的。当第一次握手时,client
与server
就会把密钥信息缓存下来。第二次访问时,基于第一次缓存的,基于必定时间内有效的信息对报文进行加密。
不管是session
、ticket
仍是TLS1.3
中的0RTT
都面临着一个危险:重放攻击
如图所示:
若是Client
发送一个使用上一次的密钥加密的post
请求给server
,而一般一个post
请求是会改变数据库的。
若是这个报文被中间人获取下来了,并且并不须要解密这份报文。而后在随后的时间内,不断的发送这个报文,就能够不断的改变数据库以形成攻击效果。
因此设定一个合适的过时时间是必要的。
更多文章请移步楼主github,若是喜欢请点一下star,对做者也是一种鼓励。