今天我抓了个 HTTPS 的包_事端_客户端

先遍及一个知识点，HTTPS = TLS + HTTP。

HTTP 我们很熟习了，以是我们想知道的 HTTPS 的知识，实质上是想知道 TLS 协议的规范，以及为什么这样设计。
以是我们本文展开讲解 TLSv1.2 协议的内容。

我们开始吧！

直接 postman 发起一个 HTTPS 的 POST 要求，这个 IP 是微博首页。

wireshark 抓包，过滤出 tls 协议的包，看到如下结果。

一下就可以看到全体 HTTPS 握手的过程了。

这个抓包数据可以加我好友，朋友圈有下载链接。
但实在你自己随便访问一个网站用 wireshark 抓一下也行。

学一个协议，最科学也是最方便的办法，便是看官方文档。

我们看 TLS 1.2 的官方文档，RFC-5246，个中 section-7.3 为我们描述了全体握手过程。

由于我们只是客户端验证做事端证书，而没有做事端验证客户端证书的过程，以是我们的包里，是不包含 Server CertificateRequest（要求客户端证书）、Client Certificate（客户端证书）、CertificateVerify（客户端证书有效性验证）这三项的。

下面我们一个一个过程拆开来看。

client_version

客户端希望的，也是客户端能支持的最高的 TLS 版本号，这里是 TLS 1.2 版本。

random

由客户端天生的随机数，之后会用到，我们称之为随机数 1。

ee8880e816ac14ca5b69bde656c188f37a08bcf2052a550b7867b041f6c1ab48

session_id

用于复用 TLS 连接，防止资源的摧残浪费蹂躏。
但这个要做事端支持才行。

cipher_suites

客户端支持的密码学套件，按客户端偏好排序，如果做事端没有可支持的，那就回应缺点（returns a handshake failure alert）并关闭连接。

本次一共发了 18 个密码学套件

我们拿个中一个密码学套件举例

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

我们知道，HTTPS 的事理便是用非对称加密的办法来交流秘钥，用对称加密的办法来通信，然后里面夹杂着哈希算法用于验证署名等。

以是这个密码学套件就包含了这三个部分。

ECDHE_RSA 指的是秘钥协商算法

AES_128_GCM 是终极通信的对称加密算法

SHA256 是哈希算法

以此来确定全体握手过程所须要的算法都用什么。

compression_methods

压缩算法

extensions

扩展字段

由此看出，本次 clientHello 最主要的信息就俩，一个随机数，一组支持的密码学套件。

做事端给客户端发送的包，相应 ClientHello。

详细包含以下内容：

server_version

TLS 的版本，详细是做事端支持的最高版本以及客户端支持的最低版本。

random

做事端天生的随机数，且生成规则不能依赖于客户真个随机数，我们称为随机数 2。

3ad03af5b8a5ebfe7902a250406b2e99d2667e37e524e0e5c333c0e0b9a637e8

session_id

做事端返回的会话 ID。

如果客户端刚刚发过来的 session_id 做事端已经有了缓存，并且赞许复用连接，则返回一个和客户端刚刚发来的相同的 session_id。

也可以发送一个新的 session_id，以便客户端下次将其携带并且复用。

也可以回答一个空值，表示不缓存 session_id，因此也不会复用。

cipher_suite

选择的加密套件。

刚刚客户端传来 18 个加密套件，做事端选择了一个回应，此处回应的是。

0xc02f

表示

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

这个刚刚阐明过了，表示用 ECDHE_RSA 作为秘钥交流算法，用 AES_128 作为通信时的对称加密算法，用 SHA256 作为哈希算法。

compression_method

选择的压缩算法，同上

extensions

扩展字段，同上

由此看出，本次 serverHello 最主要的信息也是俩，和上面的 clientHello 一样，也是一个随机数，还有一个从客户端发来的一组密码学套件中选择的一个。

至此，做事端和客户端都拥有了随机数 1 和随机数 2，并且选定了共同确定的密码学套件。

双方相互 hello 的过程就此结束了。

做事端发完上面的 ServerHello 后立即发这个包，这个包非常大略。

只有一个 Certificates 构造体，便是我们常说的证书。

而后缀还加了个 s，因此翻译成证书链，是由一组证书组成的，最上面的是做事端本身的证书。

我们把这个做事真个证书的关键信息都展开看一下：

这个证书在默认情形下都是 X.509 格式的，除非明确协商解释。

别疑惑，RFC-5246 中便是这样写的。

这种格式的构造定义在 RFC-1422 的 3.3 节中有解释。

别废话了，展开讲一下吧。

version

证书版本号，v3

serial number

证书序列号，这个每个颁发机构是唯一的，此处为：

0x0de81066db219caef5ecb01ba273cad1

signature

署名算法，仅仅是一个算法哟。

此处是 1.2.840.113549.1.1.11

表示 sha256WithRSAEncryption

这就表示用 sha256 这个哈希算法对证书进行哈希天生择要，然后再用 RSA 这个非对称加密算法，用 CA 的私钥加密刚刚天生的择要，形成数字署名。

issuer name

颁发者信息，我们展开看一下

RDNSequence item: 1 item (id-at-countryName=US)RDNSequence item: 1 item (id-at-organizationName=DigiCert Inc)RDNSequence item: 1 item (id-at-organizationalUnitName=www.digicert.com)RDNSequence item: 1 item (id-at-commonName=GeoTrust CN RSA CA G1)

validity period

证书有效期，比如本案例中的

notBefore: utcTime (0)utcTime: 20-06-09 00:00:00 (UTC)notAfter: utcTime (0)utcTime: 22-05-15 12:00:00 (UTC)

subject name

证书持有者信息

rdnSequence: 5 itemsRDNSequence item: 1 item (id-at-countryName=CN)RelativeDistinguishedName item (id-at-countryName=CN)Id: 2.5.4.6 (id-at-countryName)CountryName: CNRDNSequence item: 1 item (id-at-stateOrProvinceName=Beijing)RelativeDistinguishedName item (id-at-stateOrProvinceName=Beijing)Id: 2.5.4.8 (id-at-stateOrProvinceName)DirectoryString: printableString (1)RDNSequence item: 1 item (id-at-organizationName=Sina.com Technology(China)Co.,ltd)RelativeDistinguishedName item (id-at-organizationName=Sina.com Technology(China)Co.,ltd)Id: 2.5.4.10 (id-at-organizationName)DirectoryString: printableString (1)RDNSequence item: 1 item (id-at-organizationalUnitName=Sina.com Technology(China)Co.,ltd)RelativeDistinguishedName item (id-at-organizationalUnitName=Sina.com Technology(China)Co.,ltd)Id: 2.5.4.11 (id-at-organizationalUnitName)DirectoryString: printableString (1)RDNSequence item: 1 item (id-at-commonName=weibo.cn)RelativeDistinguishedName item (id-at-commonName=weibo.cn)Id: 2.5.4.3 (id-at-commonName)DirectoryString: printableString (1)printableString: weibo.cn

太乱了，简化下便是

countryName=CNstateOrProvinceName=BeijingorganizationName=Sina.com Technology(China)Co.,ltdorganizationalUnitName=Sina.com Technology(China)Co.,ltdcommonName=weibo.cn

顾名思义，便是微博网站这个颁发机构的信息

subject public key

证书的公钥信息，本案例中是：

3082010a0282010100c4c84ff479214c5875037500cfc453d676cec0e64c7ab5f14e0284d8b49b6f23ec70f853d38eb60dc91a6fa826d49d188fd20158c3aaa101b4b6a0c89d4df824fe755ff2cfd4f876bb2dcefe760d6f9ec5e9e2990cab4367949f27062857ca26f2303f07f6c6c953f382cb8a379ae7b28c6234983fd61739550dc6b502c4feb9c9991459265f61471b91e3b592ad3e21a276d14321f462c820477e2b34a7ea16da1f3ffa760d9065ceb5a98ffc3d19da519133d542f74dd70c4366d98d16c36c27e4384cf31130614a1398621c64c260ad91d0de32900e2ac2589029b35d21eacd078bea5cb0a9db4bc3b7ba644d0459c2e0489ae62215cc525c36784191d94b0203010001

除此之外，还剩下两项，证书署名算法（诶？这个刚刚不是已经传过了么），以及证书的署名值

从中可以读出，署名算法便是 sha256WithRSAEncryption，署名值我提取出来，如下：

220f0a0d15fa3c3909bb1e9f4d1d78cb9a41983cc9e549a4f8781f483fc18c679421eb84875354e00d86877eb1e80fb691eb0133208a0bee641ca0a7585b0e85818e88557a50f3f6241eebbc9cf49be40dc21f1d82a0cf30de30643cf236b290e74b6dee9bfdb71dab5f03b5cfd965bc16e139bc66f37119fcfc73aaf4c50fda1111bd948f507f85dd239012be73c953234328e332091c2fa38c482b6b4fdba52a26a1cc557a9c95edacea1d7b62f8996c934a5b3d762dd4f3cb88d405b805b7f604c07bd518665940f34fcb9e54121ac724a1ea3a58f42c9556f25058b19afa8c233fdf881bfeff32186051ec104fa23d4024b16b672f8eb33e359c3f813aa1

至于它是怎么算出来的，之前也画过一张图，我就直接放过来了（把稳，这里的给做事端，是指 CA 机构给做事端，然后做事端现在又给了客户端）。

还记得刚刚的署名算法么？sha256WithRSAEncryption

这个图里的哈希择要用的算法便是 sha256，而 CA 私钥加密用的算法便是 RSA。

好了，全部证书干系的信息就讲完了，同时也是 Server Certificate 这个环节的唯一信息。

证书一方面可以通过做事端给客户端通报的包解析来看，另一方面，由于浏览器要解析这个证书信息做验证，以是常日浏览器有更直不雅观的办法可以查看，就不用我们费心思了。

点开浏览器地址栏的小锁头。

看，和我们刚刚抓包剖析出来的信息，一毛一样。

我们连续看下一个包。

我相信你已经不记得全体流程到哪里了，好心的我给你放之前的图。

刚刚进行完两个 hello，以及一个通报证书的包 Certificate，接下来就要进行协商对称秘钥的过程了。

这个过程，最大略便是 RSA 算法，用做事端公钥直接加密客户端随机天生的一个对称加密秘钥，发给做事端。

但现在基本上都用更为繁芜的秘钥交流算法，我们往下看。

用于 premaster secret 天生的

之前说了，秘钥交流算法是 ECDHE 算法，这里隐含着包含了好多信息。

首先选择的椭圆曲线是 named_curve 类型，并指定了基点

天生一个私钥，这个我们抓包看不见

根据私钥和基点，打算出公钥，然后把这个公钥用做事端公钥加密，发送给做事端，这个我们能看到，便是里面的 Pubkey，值为

2ce174dbdb6f481b6ab9fd37446dca95b6ade3613afba03243d163360f63713b

至于 ECDHE 用到的椭圆曲线秘钥交流算法的细节，这里就不展开讲了，由于我也不会，就知道它终极是为了和做事端协商出来一个 premaster_secret 就好。

接着往下看。

这回轮到客户端给做事端一个用于 ECDHE 算法的公钥了。

f04e0743377afb5e9bf0a84aec5c7257957b85daee98fc48fb8971a26b457077

而同时客户端与这个公钥配对的私钥，我们也无法通过抓包看出来。

便是打算出终极对称加密用的秘钥 master_secret，这也是全体花里胡哨的过程，终极且唯一的一个目的，并且两端算出来的结果肯定是一样的。

HTTPS 的目的，不便是双方协商出一个共同的对称加密秘钥么，怕被中间人拦截到，以是做的证书呀，非对称加密算法呀，秘钥协商算法等繁芜的规定。

那 master_secret 是怎么打算出来的呢？

还记不记得之前我们得到了三个随机数：

随机数 1（客户端随机数）：在 ClientHello 里，由客户端天生的随机数，是 ee8880e816ac14ca5b69bde656c188f37a08bcf2052a550b7867b041f6c1ab48

随机数 2（做事端随机数）：在 ServerHello 里，由做事端天生的随机数，是3ad03af5b8a5ebfe7902a250406b2e99d2667e37e524e0e5c333c0e0b9a637e8

随机数 3（pre_master)：通过秘钥交流算法 ECDHE 打算出的，我们叫它 pre_master。

终极的对称加密秘钥 master_secret，便是根据这三个随机数共同打算出来的。

一旦双方协商出来了这个相同的对称秘钥，那就可以开始愉快地安全通信了，TLS 层的事情也就圆满完成。

以是可想而知，接下来的事情，就都是扫尾事情了，由于秘钥已经协商好了。

验证客户端证书有效性，本案例中没有。

可以看到，便是个标识，没有携带什么有用的信息。

这一步对应的是 Client Finish ，客户端将前面的握手天生择要再用协商好的秘钥加密，这是客户端发出的第一条加密。
做事端吸收后会用秘钥解密，能解出来解释前面协商出来的秘钥是同等的。

也是秘钥改变关照，此时做事端也已经天生了 master_secret 了，后面的通信都用此值加密。

同 Client Finish，做事器端发送握手结束关照，同时会带上前面所发内容的署名到客户端，担保前面通信数据的精确性。

之后便是真正加密的数据了。

总结

我们去掉客户端证书这个部分，全体过程简化来说一遍。

1. client --> server ClientHello

客户端天生随机数，并发送一组密码学套件供做事端选

2. server--> client ServerHello

做事端天生随机数，并从上述密码学套件组里选一个

3. server--> client Certificate

做事端发给客户端证书

4. server--> client ServerKeyExchange

做事端发给客户端秘钥交流算法所需的值

5. server--> client ServerHelloDone

做事端 hello 阶段结束

6. client --> server ClientKeyExchange

客户端发给做事端秘钥交流算法所需的值

7. client --> server ChangeCipherSpec

客户端见告做事端，我已经知道秘钥了，之后的我就都加密发送了。

8. client --> server Finish

结束并验证

7. server --> server ChangeCipherSpec

做事端见告客户端，我已经知道秘钥了，之后的我就都加密发送了。

9. server--> client Finish

结束并验证

如果不看客户端证书，不看繁芜的 premaster_secret 协商算法，不看压缩算法这些细节，实在大略说只有三大步骤。

首先第一步，客户端对做事端说 hello，并且发一组密码套件。

第二步，做事端对客户端说 hello，并且选择一组密码套件，同时把附带公钥的证书发给客户端。

第三步，客户端验证证书，并且把对称加密的秘钥用做事真个公钥加密，发给做事端，做事端用私钥解密出便是对称加密秘钥了。
（当然实际情形没这么大略，比如我们本次抓包是用 ECDHE 秘钥交流算法，这也是目前大部分网站的做法）。

经此三步之后，客户端与做事端就都拥有了相同的对称加密秘钥，进行大略的扫尾事情，也便是关照对方秘钥已天生好的信息，之后就可以开始通信了。

来源：https://mp.weixin.qq.com/s/k7hI4PTtZxB5mNciCU5Z3A

标签：客户端算法