04.安全-TLS1.2连接过程
TLS 握手的前几个消息都是明文的，能够在 Wireshark 里直接看。
但只要出现了“Change Cipher Spec”，后面的数据就都是密文了，看到的也就会是乱码，不知道究竟是什么东西。
为了更好地分析 TLS 握手过程，可以再对系统和 Wireshark 做一下设置，让浏览器导出握手过程中的秘密信息，这样 Wireshark 就可以把密文解密，还原出明文。
首先，你需要在 Windows 的设置里新增一个系统变量SSLKEYLOGFILE，设置浏览器日志文件的路径，比如
D:\http_study\log\sslkey.log
然后在 Wireshark 里设置“Protocols-TLS”
（较早版本的 Wireshark 里是“SSL”），在“(Pre)-Master-Secret log filename”里填上刚才的日志文件
ECDHE握手过程
在 TCP 建立连接之后，浏览器会首先发一个“Client Hello”消息，也就是跟服务器“打招呼”。
里面有客户端的版本号、支持的密码套件，还有一个随机数（Client Random），用于后续生成会话密钥
Transport Layer Security
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 512
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 508
Version: TLS 1.2 (0x0303)
Random: deb646e741a099b49bfef08f38871a4ac8d86b1f265ea6dc…
Session ID Length: 32
Session ID: 559393da63fd63f325d1f52088aa649401260c65f1e499fc…
Cipher Suites Length: 34
Cipher Suites (17 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 401
Extension: Reserved (GREASE) (len=0)
Extension: server_name (len=19)
Extension: extended_master_secret (len=0)
Extension: renegotiation_info (len=1)
Extension: supported_groups (len=10)
Extension: ec_point_formats (len=2)
Extension: session_ticket (len=0)
Extension: application_layer_protocol_negotiation (len=14)
Extension: status_request (len=5)
Extension: signature_algorithms (len=20)
Extension: signed_certificate_timestamp (len=0)
Extension: key_share (len=43)
Extension: psk_key_exchange_modes (len=2)
Extension: supported_versions (len=11)
Extension: compress_certificate (len=3)
Extension: Reserved (GREASE) (len=1)
Extension: padding (len=202)
作为“礼尚往来”，服务器收到“Client Hello”后，会返回一个“Server Hello”消息。
把版本号对一下，也给出一个随机数（Server Random），
然后从客户端的列表里选一个作为本次通信使用的密码套件，在这里它选择了“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384”
Transport Layer Security
TLSv1.2 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 112
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 108
Version: TLS 1.2 (0x0303)
Random: 306ba0a553a042f119e52473b67c6e293f3ee61012fff8ff…
Session ID Length: 32
Session ID: 27e4112dd0e1299b7fd853c7787c16308bf03435a620a8fd…
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Compression Method: null (0)
Extensions Length: 36
Extension: renegotiation_info (len=1)
Extension: server_name (len=0)
Extension: ec_point_formats (len=4)
Extension: extended_master_secret (len=0)
Extension: application_layer_protocol_negotiation (len=11)
TLSv1.2 Record Layer: Handshake Protocol: Certificate
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 770
Handshake Protocol: Certificate
Handshake Type: Certificate (11)
Length: 766
Certificates Length: 763
Certificates (763 bytes)
Certificate Length: 760
Certificate: 308202f4308201dca003020102020900fa9c5b27a0c1368d… (id-at-commonName=www.chrono.com)
signedCertificate
algorithmIdentifier (sha256WithRSAEncryption)
Padding: 0
encrypted: 6dd90318e47d1b41728f04802a85eedca00a615feed7a67f…
TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 300
Handshake Protocol: Server Key Exchange
Handshake Type: Server Key Exchange (12)
Length: 296
EC Diffie-Hellman Server Params
Curve Type: named_curve (0x03)
Named Curve: x25519 (0x001d)
Pubkey Length: 32
Pubkey: 780f25b44d2ebb5df7ead5e9b6b32c2d40bb7094f16ac7c6…
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: RSA (1)
Signature Length: 256
Signature: 6778592c6742cbd45ff120ce72d1a442a8c5cdbb65e792d5…
TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 4
Handshake Protocol: Server Hello Done
Handshake Type: Server Hello Done (14)
Length: 0
然后，服务器为了证明自己的身份，就把证书也发给了客户端（Server Certificate）。
接下来是一个关键的操作，因为服务器选择了 ECDHE 算法，所以它会在证书后发送“Server Key Exchange”消息，里面是椭圆曲线的公钥（Server Params），用来实现密钥交换算法，再加上自己的私钥签名认证
TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 300
Handshake Protocol: Server Key Exchange
Handshake Type: Server Key Exchange (12)
Length: 296
EC Diffie-Hellman Server Params
Curve Type: named_curve (0x03)
Named Curve: x25519 (0x001d)
Pubkey Length: 32
Pubkey: 780f25b44d2ebb5df7ead5e9b6b32c2d40bb7094f16ac7c6…
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: RSA (1)
Signature Length: 256
Signature: 6778592c6742cbd45ff120ce72d1a442a8c5cdbb65e792d5…
[*] 1.指明自己使用的椭圆曲线（一般根据客户端的拓展中supported_groups中的选择椭圆曲线算法）
[*] 2 服务器本地计算一个大数（BIGNUM），乘上曲线的base point，得到一个新的point，这个point就是公钥，用04+x+y的格式组织起来。04表示unconpressed point，和客户端的ec_point_formats有关。
[*] 3 签名 。和RSA握手不同，RSA情况下， 只要能值正常协商密钥，那么必然服务器端有证书对应的私钥，也间接表明了服务器拥有该证书。
DHE/ECDHE不同，证书对应的私钥并不参与密钥协商，如果要证明服务器拥有证书，则必然有签名的操作（就像双向认证的情况下，客户端需要发送certificate verify）。
被签名数据从curve type起，至point的y为止。
对于TLS1.2，签名算法使用client hello拓展中提供的摘要算法；TLS1.0和TLS1.1，如果本地证书是ECC证书，即若要使用ECDSA签名，这种摘要算法为SHA1，其他的情况摘要算法为md5+sha1。
计算摘要之后就调用RSA或者ECDSA进行签名。注意的是，TLS1.2时报文要带上2字节的“Signature Hash Algorithm”，如上图高亮部分，这是TLS1.2协议相较于之前协议不同之处之一，但是这2部分不参与签名计算
这相当于说：“刚才我选的密码套件有点复杂，所以再给你个算法的参数，和刚才的随机数一样有用，别丢了。为了防止别人冒充，我又盖了个章。
”之后是“Server Hello Done”消息，服务器说：“我的信息就是这些，打招呼完毕。”这样第一个消息往返就结束了（两个 TCP 包），结果是客户端和服务器通过明文共享了三个信息：Client Random、Server Random 和 Server Params。
客户端这时也拿到了服务器的证书，那这个证书是不是真实有效的呢？
开始走证书链逐级验证，确认证书的真实性，再用证书公钥验证签名，就确认了服务器的身份：“刚才跟我打招呼的不是骗子，可以接着往下走。”然后，客户端按照密码套件的要求，也生成一个椭圆曲线的公钥（Client Params），用“Client Key Exchange”消息发给服务器。
Handshake Protocol: Client Key Exchange
EC Diffie-Hellman Client Params
Pubkey: 8c674d0e08dc27b5eaa…
现在客户端和服务器手里都拿到了密钥交换算法的两个参数（Client Params、Server Params），就用 ECDHE 算法一阵算，算出了一个新的东西，叫“Pre-Master”，其实也是一个随机数。
至于具体的计算原理和过程，因为太复杂就不细说了，但算法可以保证即使***截获了之前的参数，也是绝对算不出这个随机数的。
现在客户端和服务器手里有了三个随机数：Client Random、Server Random 和 Pre-Master。
用这三个作为原始材料，就可以生成用于加密会话的主密钥，叫“Master Secret”。而***因为拿不到“Pre-Master”，所以也就得不到主密钥。为什么非得这么麻烦，非要三个随机数呢？
这就必须说 TLS 的设计者考虑得非常周到了，他们不信任客户端或服务器伪随机数的可靠性，为了保证真正的“完全随机”“不可预测”，把三个不可靠的随机数混合起来，那么“随机”的程度就非常高了，足够让***难以猜测。
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
这里的“PRF”就是伪随机数函数，它基于密码套件里的最后一个参数，比如这次的 SHA384，通过摘要算法来再一次强化“Master Secret”的随机性。
主密钥有 48 字节，但它也不是最终用于通信的会话密钥，还会再用 PRF 扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）等等，避免只用一个密钥带来的安全隐患。
有了主密钥和派生的会话密钥，握手就快结束了。客户端发一个“Change Cipher Spec”，然后再发一个“Finished”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证。
意思就是告诉服务器：“后面都改用对称算法加密通信了啊，用的就是打招呼时说的 AES，加密对不对还得你测一下。
”服务器也是同样的操作，发“Change Cipher Spec”和“Finished”消息，双方都验证加密解密 OK，握手正式结束，后面就收发被加密的 HTTP 请求和响应了
[*]HTTPS 协议会先与服务器执行 TCP 握手，然后执行 TLS 握手，才能建立安全连接
[*]握手的目标是安全地交换对称密钥，需要三个随机数，第三个随机数“Pre-Master”必须加密传输，绝对不能让***破解；
[*]“Hello”消息交换随机数，“Key Exchange”消息交换“Pre-Master”；
[*]“Change Cipher Spec”之前传输的都是明文，之后都是对称密钥加密的密文
TLS协议组成
记录协议
Record Protocol ,规定了TLS收发数据的基本单位。它有点类似TCP里的segment,所有的其它子协议都需要通过记录协议发出
但是多个记录数据可以在1个TCP包里一次性发出，也并不需要像TCP那样返回ACK
警报协议
Alert protocol 职责是向对方发出警报信息,类似http协议里的状态码。
比如protocol_version 就死不支持旧版本 bad_certificate就是证书有问题
收到警报后，另一方可以选择终止连接，也可以选择继续
握手协议
（Handshake Protocol）是 TLS 里最复杂的子协议，要比 TCP 的 SYN/ACK 复杂的多，浏览器和服务器会在握手过程中协商
[*]TLS 版本号、
[*]随机数、
[*]密码套件等信息，
然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统
变更密码规范协议
（Change Cipher Spec Protocol），它非常简单，就是一个“通知”，告诉对方，后续的数据都将使用加密保护。那么反过来，在它之前，数据都是明文的
第一阶段：C/S两端共享Client Random、Server Random 和 Server Params信息
客户端--->服务器：
客户端的版本号、支持的密码套件，还有一个随机数（Client Random）
服务端--->客户端：
客户端的版本号、选择的客户端列表的密码套件如：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、随机数随机数（Server Random）
服务端--->客户端：
服务端证书（Server Certificate）
服务端--->客户端：
发送Server Key Exchange类型的请求，携带椭圆曲线的公钥（Server Params）用以实现密钥交换算法，另附私钥签名
服务端--->客户端：
发送完毕
第二阶段：证书验证
前验条件：客户端证书链逐级验证、证书公钥验证签名，服务端身份验证成功（证书合法）
客户端--->服务端
发送Client Key Exchange类型的请求，携带椭圆曲线的公钥（Client Params）用以实现秘钥交换算法
第三阶段：主密钥生成
客户端、服务端分别使用Client Params、Server Params通过ECDHE算法计算出随机值pre-master，然后用
Client Random、Server Random 和 Pre-Master三个值作为原材料，用PRF伪随机数函数（利用密码套件的摘要算法再次强化结果
值maser secert的随机性）计算出主密钥Master Secret，
主密钥并不是会话秘钥，还会再用PRF扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）
客户端--->服务端:
客户端发一个“Change Cipher Spec”，然后再发一个“Finished”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证.
服务端--->客户端：
服务器也是同样的操作，发“Change Cipher Spec”和“Finished”消息，双方都验证加密解密 OK，握手正式结束.
1.client hello 【client->server】
[*]client发送 随机数randomC,tls版本，支持的密码套件，扩展信息到服务端
2.server hello 【server-client】
[*]server 发送 随机数randomS,tls版本确认，选择的密码套件，扩展信息到client
3.certificate 【server->client】
4.server key exchange 【server->client】
[*]EC Diffie-Hellman Server Params
[*]Curve Type(曲线类型)
[*]Pubkey
[*]Signature Algorithm和Signature
5.server hello done 【server ->client】
https://blog.csdn.net/mrpre/article/details/78025940
页:
[1]