发表日期:2018-07 文章编辑:小灯 浏览次数:1957
//第一步,为服务器端和客户端准备公钥、私钥 # 生成服务器端私钥 openssl genrsa -out server.key 1024 # 生成服务器端公钥 openssl rsa -in server.key -pubout -out server.pem//第二步,生成 CA 证书 # 生成 CA 私钥 openssl genrsa -out ca.key 1024 # X.509 Certificate Signing Request (CSR) Management.ca证书签名请求 #要求填写一些资料。Common Name是能访问的域名 openssl req -new -key ca.key -out ca.csr# X.509 Certificate Data Management.生成ca证书 openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt//第三步,生成服务器端证书 # 服务器端需要向 CA 机构申请签名证书,在申请签名证书之前依然是创建自己的 CSR 文件 openssl req -new -key server.key -out server.csr # 向自己的 CA 机构申请证书,签名过程需要 CA 的证书和私钥参与,最终颁发一个带有 CA 签名的证书 openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.cr
虽然只有 Client Hello 两个单词,但是其消息体里面包含了丰富的信息,我们在 WireShark 上选择这行记录,并双击,其里面包含了下面的一些主要信息。
(1)Handshake Type:Client Hello(握手类型)。
(2)Random(随机数)和一个时间戳。
(3)客户端支持的加密协议套装。
告诉 HTTPS 的服务器端,客户端能支持上面这 26 种加密协议套装上列出的算法,让服务器选择一个加密协议算法套装。
(4)访问的 Web 服务器的信息:
(5)客户端支持的签名算法:
客户端告诉服务器其支持 9 种签名算法,让服务器端自由选择一个用于后续的加密通信。
HTTPS 服务器马上给客户端回复了下面这 4 条 SSL 握手信息。
下面具体来看这 4 条由 HTTPS 服务器端发出的 4 条消息里面到底有什么内容,其会告诉客户端什么秘密和信息呢?
(1)Server Hello SSL 握手信息
其重点是把客户端发送给服务器端的随机数又给发送回去了,而且还生成了服务器端的 Session ID 并发送给客户端,最后告诉客户端,服务器端准备选择TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
作为秘钥交互的加密协议套装,该加密协议的套装名字肯定出现在客户端发送给服务器的支持的 26 个列表中,不信你可以翻回去对比一下。
(2)Certificate
SSL 服务器证书信息。在这条 HTTPS 服务器给客户端回复消息 SSL 握手信息里面,其还会把服务器端的 SSL 证书发送给客户端,从上图的转包信息中,我们能清晰地发现服务器端 SSL 证书的相关信息,比如,通用名字为 iis-web-01,组织单元为 it 等。
需要注意的是,如果是 SSL 的双向认证,服务器端也可以要求客户端把 SSL 证书发送给服务器端(对应的 SSL 握手消息名称为:CertificateRequest),这个时候,客户端就会把其 SSL 证书发送给服务器端,从而证明其就是服务器端信任的客户端。
(3)Server Key Exchange 握手消息
HTTPS 服务器出大招了,告诉了客户端其将会采用的 EC Diffie-Hellman 算法进行 HTTPS 服务器和客户端的秘钥交换。具体什么是 EC Diffie-Hellman 算法,大家可以自行查阅资料,这里不再赘述,并提供了 EC Diffie-Hellman 算法使用到的服务器端的参数:
named_curve: secp256r1
rsa_pkcs1_sha1
(4)Server Hello Done 握手信息
握手信息列表结束了。
当客户端收到服务器端的相关公钥信息,SSL 证书以及摘要算法和摘要信息后,也不是无动于衷,而是积极的响应了下面的 3 条 SSL 握手信息。
那么这三条 SSL 的握手信息将会透露出什么?客户端到底想告诉服务器端什么?让我们一一分解。
(1)Client Key Exchange 握手信息
其给服务器端发送了一条用服务器端公钥加密的信息,其里面就包含了预备主密码(Pre-Master secret),其是由客户端随机生成,之后会被用作生成主密码的种子。根据预备密码,服务器和客户端会计算出相同的主密码(Master secret),然后根据主密码生成下面的比特序列(秘钥素材)。
需要注意的是,Client 秘钥交换的方式主要有两种,一种是通过 RSA 公钥密码进行交互,这个时候客户端会在发送 ClientKeyExchange 消息时,将经过加密的预备主密码一起发送给服务器。当使用 Diffie-Hellman 交换秘钥的时候,客户端会在发送 ClientKeyExchange 消息时,将 Diffie-Hellman 公开值(Pub Key)一起发送给服务器,根据这个值,客户端和服务器会各自生成预备主密码,而且更加这个预备主密码能够生成相同的对称主密码。
(2)Change Cipher Spec 握手信息
告诉服务器端,我要切换密码了!
(3)Encrypted Handshake Message 握手信息
客户端发出使用主密码加密的结束信息,告诉服务器端:“秘钥交换握手协议到此结束”。
这次轮到服务器端发送“Change Cipher Spec”消息了,服务器告诉客户端:“好,现在我也要切换密码了”。
服务器端用预备主密码(Pre-Master secret)计算出的主秘钥加密了一条信息,并发送给客户端:“好的,秘钥交换握手协议到此结束”。如果通信双方都能把结束消息解密成功,说明主秘钥已经交换成功。就可以发送真正的用主密码加密的应用数据的信息了!
服务器端用成功交换了秘钥把加密过的 HTML 网页内容发送给客户端,客户端用以前收到过的对称秘钥进行解密,HTTPS 通信协议圆满结束。
上面的步骤只是把我当前环境下抓取到的使用 TL S1.2 协议规范进行了 HTTPS 通信原理和过程的梳理和解释,在不同的环境下,其通信过程会有一些差异,比如,如果配置了双向 SSL 认证,其 SSL 服务器端还会要求客户端把客户端的证书发送到服务端,从而验证客户端是否是可信任的,另外在进行主密码交换的过程中,也可能采用 RSA 公钥密码,而不是 Diffie-Hellman,此时,其 SSL 握手消息会有所不同,但是整体的流程和交互过程思路基本上保持相同。
上述具体流程如下图所示
日期:2018-04 浏览次数:6673
日期:2017-02 浏览次数:3353
日期:2017-09 浏览次数:3555
日期:2017-12 浏览次数:3438
日期:2018-12 浏览次数:4697
日期:2016-12 浏览次数:4485
日期:2017-07 浏览次数:13551
日期:2017-12 浏览次数:3405
日期:2018-06 浏览次数:4175
日期:2018-05 浏览次数:4359
日期:2017-12 浏览次数:3485
日期:2017-06 浏览次数:3900
日期:2018-01 浏览次数:3845
日期:2016-12 浏览次数:3819
日期:2018-08 浏览次数:4343
日期:2017-12 浏览次数:3607
日期:2016-09 浏览次数:6301
日期:2018-07 浏览次数:3122
日期:2016-12 浏览次数:3138
日期:2018-10 浏览次数:3293
日期:2018-10 浏览次数:3385
日期:2018-09 浏览次数:3478
日期:2018-02 浏览次数:3502
日期:2015-05 浏览次数:3434
日期:2018-09 浏览次数:3220
日期:2018-06 浏览次数:3344
日期:2017-02 浏览次数:3794
日期:2018-02 浏览次数:4248
日期:2018-02 浏览次数:4055
日期:2016-12 浏览次数:3497
Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.