其实在最开始抓包的时候就发现了一个问题,就是在ChangeCipherSpec消息之后,没有加密扩展、证书,甚至Finished消息都没有。在握手过程中,Finished消息是一定存在的,所以说明用Wireshark抓的包存在问题,之前提到过,ChangeCipherSpec之后的消息都是进行加密了的,所以可能是因为Wireshark没有对后续的消息进行解密,所以只是显示了ApplicationData,即加密传输的数据。
那么要想利用wireshark对其进行分析,就要想办法得到密钥,对加密的消息进行解密,这里的解决方法参照https://jingyan.baidu.com/article/20b68a88b2af7f796cec62b3.html。
简要步骤:
1.创建一个log文件,因为Firefox和Chrome浏览器都支持用log文件的方式记录下用来加密TLS数据包对称会话秘钥的,所以创建ssl.log来保存会话密钥。
2.配置环境变量。右键点击我的电脑->属性->高级系统设置->高级->环境变量->系统变量
然后新建一个系统环境变量,变量名是SSLKEYLOGFILE,变量值就是你的log文件的位置。
3.在Wireshark中进行配置。编辑->首选项->协议Protocols->SSL,在(pre)-Master-Secret log filename一栏中添加刚才的log文件位置。
然后再进行抓包,抓包结果如图:
可以看到之前的
Application Data
被解析为EncryptedExtentions、Certificate、Certificate verrify、Finished
,下面将对这几个消息进行逐个分析。Encrypted Extentions加密扩展
加密扩展中包含两个扩展内容——
supported_groups
和server_name
。Type
、Length
依旧表示类型和长度,不再进行单独解释。supported_groups
包含的是服务器所支持的曲线组,这里有x25519、secp256r1、secp384r1。server_name
表示服务器名,此处加密扩展是服务器发给客户端的,所以置为空。
Certificate
Certificate Request Context Length
,在此处置为空,即长度为0。Certificate Request
一般是在加密扩展消息之后服务器(可选)进行发送的,服务器用它来请求客户端发送证书,如果服务器发送了Certificate Request,客户端一般需要在后面发送自己的Certificate,并在Certificate消息中包含Certificate Request Context来进行响应;所以服务器发送的证书中,Certificate Request Context为空,长度为0。Certificates
,证书(CertificateEntry)序列,每个CertificateEntry包含一个证书和一组扩展。
signedCertificate
:
version
,版本为v3;serialNumber
,序列号。
signature
: Algorithm Id
,签名算法ID,这里表示sha256WithRSAEncryption。
issuer
,证书颁发者,用X.509 DN
表示,DN是由RDN构成的序列,RDN用“属性类型=属性值”的形式表示。
CountryName
,国家,此处为US。
OrganizationName
,机构名,此处为Let's Encrypted。
commonName
,通用名称,此处为Let's Encrypted Authority X3。
validity
,表示证书的合法性,包含证书有效期的起止时间。subject
,证书的主体,也用X.509 DN
表示,即RDN序列。commonName
,通用名称,此处为tls13.crypto.mozilla.org,即所颁发证书的对象。 subjectPublicKeyInfo
,证书主体公钥信息。Algorithm
,公钥算法,这里用的是RSA。subjectPublicKey
包含的就是具体的公钥,包括modulus
(系数)和Exponent
(指数)。extentions
,扩展,这里有9个扩展,分别是keyUsage
、extKeyUsage
、basicConstraints
、subjectKeyIdentifier
、authorityKeyIdentifier
、authorityInfoAccessSyntax
、subjectAltName
、certificatePolicies
、SignedCertificateTimestampList
。keyUsage
,表示证书的公钥可以完成的功能或服务,这里包含digitalSignature和keyEncipherment。extKeyUsage
,表示Extended Key Usage,包含一系列的KeyPurposeID,每一个都表示一种用途,这里包括serverAuth和clientAuth。basicConstraints
,基本约束扩展,subjectKeyIdentifier
,主体密钥标识符,用来识别包含特定密钥的证书。authorityKeyIdentifier
,**密钥标识符,用来识别证书所用私钥对应的公钥。authorityInfoAccessSyntax
,序列中的每个条目都描述了扩展所在的证书的颁发者提供的附加信息的格式和位置。信息的类型和格式由accessMethod字段指定;accessLocation字段指定信息的位置。subjectAltName
,表示Subject Alternative Name,主体可选名,可使身份与证书主体绑定,此处只给出了一个GeneralName。certificatePolicies
,证书策略扩展包含一个或多个策略信息术语的序列,每个术语由对象标识符(object identifier,OID)和可选限定符(optional qualifiers)组成。SignedCertificateTimestampList
,表示证书时间戳序列,包含时间戳(Timestamp)、签名算法(Signature Algorithm)、签名(Signature)以及其他字段。从
signature
到刚才的extensions
都是signedCertificate
中的内容。
algorithmIdentifier
,表示算法标识符,包含Algorithm ID,对应于特定算法,此处为sha256WithRSA。Padding
,填充内容,此处为空。
另外一个证书的内容和上述内容类似,不再进行详细叙述,因为证书的内容不是研究的重点,所以叙述比较简单,具体看rfc5280对X.509证书的定义https://tools.ietf.org/html/rfc5280#section-4.1.2.9。
Certificate Verify
Signature Algorithm
,签名算法,此处为rsa_pss_rsae_sha256。Signature
,签名内容。
Finished
Finished
消息是身份验证阶段的最后一条消息,Verify Data
是通过HMAC计算得来的,包含finished_key和握手消息的hash。
verify_data =HMAC(finished_key,Transcript-Hash(Handshake Context,Certificate, CertificateVerify))