当信息分组在网络上传输时，是通过网络节点不断接力，逐跳抵达目标节点的。每一跳都需要通过路由表查找下一跳 IP，再根据 ARP 协议将下一跳的 IP 地址转换为 mac 地址来进行实际投递，在投递过程中从物理介质的角度看到的是广播，通过网卡的主动过滤——只接收匹配本网卡 mac 地址的报文，来营造一种定点投递的假象，并沿着 OSI 模型向上传递，最终抵达应用层。
戳破这种假象的一种方式是在抓包时开启网卡的混杂模式，这样就能抓取到网卡连接到的物理链路上的所有报文信息——压根不用 hack 你的电脑，假设我们的电脑都连接到同一个数据链路层，比如同一台交换机，这时候我开启网卡混杂模式，就可以抓到所有电脑的通信报文，如果上层协议没有准备，所有秘密都将一览无遗。理论上我们的信息报文从本机到目标网站服务器上经过的所有二层都存在这个问题。
这还不算完，DHCP、DNS、BGP、HTTP，甚至 IP 地址配置协议在机制设计上都存在这种安全上的疏漏——想想 AWS 的集群因为 BGP 配置错误而引发大规模下线的事件以及非著名 DNS 污染行为，可以说我们早期的核心网络协议都是基于信任为前提的，不考虑恶意行为的话，协议的确可以设计得相当简洁优雅。随着 Internet 取得超乎想象的成功，带来了巨大的经济效益，原先的单纯开始变得不合时宜了，在看到了可观经济利益的流氓面前，简直漏成了筛子。
在普及 TLS/SSL 之前，上层应用都是各自为战，更普遍的情况可能是压根就不设防，毕竟找几个廉价劳动力就可以搞出个网站，出多少成本理应得到多少质量。
世界的前进方式就是开着飞机换翅膀，为了以一种统一的方式解决这个棘手问题，在传输层之上又植入一层安全传输层。通过 TLS/SSL 来加密要传输的数据。目前 SSL 家族只剩 3.0，其他成员因为安全问题已经被放弃。而 TLS 1.0 其实就是 SSL 3.1 ——这里又牵涉到当年巨硬和 Netscape 关于 Web 统治权的争斗。在可见的将来，SSL 将退出历史舞台，TLS 则继续前进。我们的 HTTP 如果是基于 TLS/SSL 进行传输的，就叫 HTTPS（http over tls）。
TLS/SSL 包括两个要点：其一是工作在传输层上，即在数据被解释为有意义的信息之前进行加解密（和最近做的一项改造工作有点类似）；其二是通过 pki 体系验证身份，通过密钥交换来协商对称密钥，然后通过对称加密传输数据。
TLS 主要包含 4 个核心子协议：
- 握手协议（handshake protocol）
- 密钥规格变更协议（change cipher spec protocol）
- 应用数据协议（application data protocol）
- 警报协议（alert protocol）
说一下关键的握手协议，一次完整的握手协议包括：
- Client：ClientHello
- Server：ServerHello、Certificate*、ServerKeyExchange*、ServerHelloDone
- Client：ClientKeyExchange
在握手阶段，协议分两层：靠近 tcp 层的是记录层协议（record protocol），上层是握手协议（handshake protocol）。
在握手协议中有两个关键点：身份验证、密钥协商。
1、身份验证。一般情况下，我们只要求对服务端的身份进行验证，通过 Server Certificate 消息，服务端将证书链发送给客户端，有了证书链，就可以验证服务端是否可信。若需要同时验证客户端身份，则服务端需要向客户端发送 Certificate Request 消息，由客户端返回 Certificate、Certificate Verif
2、密钥协商。密钥协商主要是为了生成预主密钥。密钥协商有三种方式：RSA、DH（Diffie-Hellman）、ECDH（elliptic curve DH）。
RSA 协商方式比较直接，预主密钥是客户端生成的46字节随机数，使用服务器在 Server Certificate 消息中公布的公钥加密预主密钥发送给服务端，存在的风险是一旦服务端的私钥泄漏，在后续的时间里攻击者可以冒充服务端。
DH 和 ECDH 则更复杂一些，客户端并不直接生成预主密钥，而是通过和服务端交换一些参数，采用相关的算法各自生成一致的预主密钥。
预主密钥（pre_master_secret）经过伪随机函数（PRF）处理后就得到了主密钥（master_secret），作为加密传输数据的对称密钥。
master_secret = PRF( pre_master_secret, "master secret", ClientHello.random, ServerHello.random )