https全链路分析

发表于 分类于
HTTPS 抓包与证书链分析，是理解 TLS 最好的实践方式之一

HTTPS 抓包与证书链分析，是理解 TLS 最好的实践方式之一。

很多人学了半天：

1
2
3
4
5
RSA
ECDHE
证书
CA
TLS

但是不知道这些东西到底在网络里长什么样。

实际上用 Wireshark 抓一次包，你会发现前面学的所有知识都能对应上。

一、HTTPS 抓包能看到什么

很多人以为：

1
HTTPS = 完全看不到

实际上不是。

HTTPS 只是：

1
应用数据加密

握手过程很多信息仍然是明文。

例如：

1
2
3
4
5
6
7
TCP三次握手

TLS握手

证书

域名(SNI)

都能看到。

举例

访问：

1
https://www.baidu.com

抓包。

会看到：

1
2
3
4
5
6
7
8
9
10
11
TCP

TLSv1.3

Client Hello

Server Hello

Certificate

Application Data

二、TLS握手长什么样

TCP连接

首先：

1
2
3
4
5
6
7
8
9
10
11
Client
    SYN
Server

Server
    SYN ACK
Client

Client
    ACK
Server

完成三次握手。

然后开始 TLS。

Client Hello

浏览器发送：

1
Client Hello

里面包含：

1
2
3
4
5
6
7
8
9
TLS版本

随机数

支持算法

支持密码套件

支持曲线

例如：

1
2
3
4
5
TLS_AES_128_GCM_SHA256

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

Wireshark里面类似：

1
2
3
4
5
6
Client Hello
    Version: TLS1.3

    Cipher Suites:
        TLS_AES_128_GCM_SHA256
        TLS_AES_256_GCM_SHA384

Server Hello

服务器回复：

1
Server Hello

表示：

1
2
3
我选择TLS1.3

我选择AES128

还能看到：

1
ECDHE公钥

三、证书在哪里

后面会出现：

1
Certificate

展开以后：

1
2
3
4
5
Certificate
 ├─ Subject
 ├─ Issuer
 ├─ Public Key
 ├─ Signature

例如：

1
2
3
4
5
Subject:
    *.google.com

Issuer:
    Google Trust Services

这就是服务器证书。

四、证书里面到底有什么

很多人以为：

1
证书 = 公钥

其实不是。

证书本质上是：

1
身份证

里面包含：

1
2
3
4
5
6
7
8
9
10
11
域名

公钥

签发机构

有效期

扩展信息

签名

例如：

1
2
3
4
5
6
7
8
9
CN=www.google.com

Public Key

Not Before

Not After

CA Signature

五、证书链是什么

这是面试高频问题。

浏览器收到：

1
google证书

为什么相信它？

因为：

1
CA签发

例如：

1
2
3
4
5
6
7
8
9
Google证书
    ↓
中间CA

Google Trust Services
    ↓
根CA

GlobalSign Root CA

形成：

1
2
3
4
5
Leaf
  ↓
Intermediate
  ↓
Root

这就是：

1
Certificate Chain

证书链。

六、为什么需要中间CA

如果根CA直接签发：

1
几亿张证书

风险巨大。

所以现实是：

1
2
3
4
5
Root CA
     ↓
Intermediate CA
     ↓
网站证书

例如：

1
2
3
4
5
Root
    私钥离线保存

Intermediate
    在线签发证书

即使中间CA泄露：

1
吊销即可

根CA仍然安全。

七、浏览器怎么验证证书链

收到：

1
Leaf证书

例如：

1
www.google.com

发现：

1
2
3
Issuer:

Google Trust Services

于是验证：

1
Leaf签名

是否由：

1
Google Trust Services

签发。

然后继续：

1
Google Trust Services

是谁签发的？

发现：

1
GlobalSign Root

继续验证。

最后：

1
GlobalSign Root

就在浏览器内置信任库里。

因此：

1
整条链可信

八、浏览器内置了什么

Windows：

1
证书管理器

Linux：

1
ca-certificates

Chrome：

1
Root Store

里面存放：

数百个根证书。

例如：

  • DigiCert
  • GlobalSign
  • ISRG
  • Let’s Encrypt

浏览器真正信任的是：

1
根证书公钥

而不是网站证书。

九、数字签名如何验证

假设证书内容：

1
2
3
CN=www.test.com

Public Key=ABC

CA计算：

1
Hash(证书内容)

得到：

1
123456

然后：

1
CA私钥签名

得到：

1
Signature

浏览器收到：

1
2
3
Certificate
+
Signature

利用：

1
CA公钥

验证。

成功说明：

1
证书未被修改

并且：

1
确实由该CA签发

十、中间人攻击怎么发生

假设没有证书验证。

攻击者：

1
2
3
4
5
Client
   ↓
 Hacker
   ↓
 Server

攻击者返回：

1
假的公钥

客户端也接受。

于是：

1
2
3
4
5
6
7
客户端
↔
攻击者

攻击者
↔
服务器

建立两条连接。

攻击者可以：

1
2
3
4
5
查看

修改

转发

所有数据。

这就是：

1
MITM

中间人攻击。

十一、为什么 Fiddler/Charles 能抓 HTTPS

很多开发者第一次用：

  • Fiddler
  • Charles
  • Burp Suite

会很惊讶：

1
HTTPS不是加密的吗？

为什么还能看见请求？

因为这些工具会：

1
自己生成一个根证书

例如：

1
Charles Root CA

然后安装到系统信任库。

浏览器认为：

1
Charles Root CA

可信。

访问：

1
https://www.google.com

时：

Charles动态生成：

1
www.google.com

证书。

浏览器验证：

1
签发者 = Charles Root CA

发现可信。

于是：

1
2
3
4
5
浏览器
 ↔ Charles

Charles
 ↔ Google

建立两条 TLS。

Charles 就能看到：

1
2
3
4
5
6
7
8
9
Request

Response

Cookie

Header

Body

全部内容。

十二、为什么手机抓包经常失败

因为很多 App 开启：

1
Certificate Pinning

证书绑定。

例如 App 内写死：

1
Google证书公钥

或者：

1
证书Hash

即使系统信任：

1
Charles Root CA

App也会检查：

1
公钥不匹配

然后：

1
TLS握手失败

十三、开发人员最应该掌握的几个命令

查看证书：

1
openssl s_client -connect www.google.com:443

查看证书链：

1
2
openssl s_client -showcerts \
-connect www.google.com:443

查看详细内容：

1
openssl x509 -text -noout