在讲解今天的内容之前，我们先来回顾下在上期学习的《网络安全 — HTTPS》。我们知道 HTTPS 与 HTTP 在本质上并没有什么“区别”，它的安全性完全由 TLS 来保证的。
关于安全，我们总结出四个特性：机密性、完整性、身份认证和不可否认。只有同时满足该四条特性，通信双发的利益才能得到保障，才能算得上是真正的安全。说到这，如果你还不了解的话可以先去参考下。
那作为安全保障的 TLS 它是如何为 HTTP 增加这四条特性的呢？今天，我们先来聊一聊机密这一特性，它是信息安全的基石，缺乏机密性谈安全最终会成为空谈。
机密性
实现机密性最常用的手段就是加密，就是把消息运用一个规则转换成谁也看不懂的乱码，只有掌握特殊“钥匙”的人才能再还原回原始文本。下面我们通过一个例子来熟悉下这一过程。
现在 Alice 要和 Balbo 进行通信，发送信号 M 给 Balbo。通过一些算法，比如加一个数字 e，变成一个新的数字 C，然后把 C 再传递给 Balbo。Balbo 在拿到 C 之后通过减去 e 得到原来的信号 M。
在实际应用中，加解密算法的设计要复杂的多，这里仅是举例说明。
这里的信号 M 我们称之为明文（plain text/clear text），加密后的消息 C 称之为密文（cipher text），e 就是那把钥匙，称之为密钥（key）。使用密钥加密明文的过程叫做加密（encrypt），反之就是解密（decrypt）。整个加密解密的操作过程就是加密算法。
所有的加密算法都是公开的，任何人都可以去分析研究，而算法使用的密钥则必须保密。所谓密钥就是指用以完成加密、解密的秘密信息。其表现形式就是一长串数字，约定俗称的度量单位是位（bit），例如密钥长度是 128 位，就是 16 字节的二进制串，密钥长度是 1024，就是 128 字节的二进制串。
按照秘钥的使用方式，加密可以分为两大类：对称加密和非对称加密
对称加密
关于对称加密其实很好理解，就是指加密和解密时使用的秘钥都是同一个，也就是“对称”的。只要保证了密钥的安全，整个通信过程就可以说具有了机密性。
TLS 里也提供了非常多的对称加密算法可供选择，比如 RC4、DES、3DES、AES、ChaCha20 等。但前三种算法都已经被认为是不安全的，通常被禁止使用，目前常用的只有 AES 和 ChaCha20。
AES
AES（高级加密标准，Advanced Encryption Standard）是美国政府采用的一种区块加密标准，用以替换原来的 DES，安全强度很高、性能也很好，而且有的硬件还会做特殊优化，如今已经被多方分析为全世界所使用。AES 已然已经成为对称秘钥加密中最流行的算法之一。
ChaCha20
ChaCha2o 是 Google 设计的另一种加密算法，密钥长度固定为 256 位，纯软件运行性能要超过 AES，曾经在移动客户端上比较流行，但 ARMv8 之后也加入了 AES 硬件优化，所以现在不再具有明显的优势，但仍然算得上是一个不错的算法。
非对称加密
对称加密的算法可以被设计的非常复杂，看上去好像已经完美地实现了机密性。但即使是再复杂也会存在被“窃听”的可能，恶意者可以通过穷举或通过数字的频率，一次又一次的尝试，只要截取足够多的密文，他就可以把密钥给试出来。
这时候你可能会想，能不能周期性的更换这个密钥呢？但是这时候密钥的分发又成为一个问题，如何把密钥安全地传递给对方？术语叫做“密钥交换”。
这个问题该怎么解决呢？
所以就出现了非对称加密（也叫公钥加密算法）。非对称加密指加密和解密使用不同密钥的加密算法。即它有两个秘钥，一个叫公钥（public key），一个叫私钥（private key）。两个密钥是不对称的。用公钥加密后只能用私钥解密，反之，用私钥加密后也只能用公钥解密。这便是非对称加密的单向性。
非对称加密的出现可以解决“密钥交换”的问题。服务秘密保管私钥，在网上任意分发公钥，想要与服务进行通信只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因为没有私钥，所以就无法破解密文。
非对称加密算法的设计比对称加密算法复杂的多，在 TLS 也只有很少的几种，例如 DH、DSA、RSA 以及 ECC 等。
RSA
RSA 可能是非对称加密中最著名的一个，几乎已经成为非对称加密的代名词，在公开秘钥加密和电子商业中被广泛使用。
- RSA 于 1997 年，由工作于麻省理工学院的 Ron Rivest、Adi Shamir 和 Leonard Adleman 一起提出，RSA 正是三人姓氏开头的字母组合。
10 年前 RSA 密钥的推荐长度是 1024，但随着计算机运算能力提高，现在 1024 已经不安全，普遍认为至少要 2048 位。
对极大整数做因数分解的难度决定了 RSA 的可靠性，即对一极大整数做因数分解愈困难，RSA 算法愈可靠。
ECC
ECC（椭圆曲线密码学，Elliptic Curve Cryptography）是非对称加密里的”后起之秀“，它基于椭圆曲线离散对数的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于秘钥交换，ECDSA 用于数字签名。
目前常用的两个曲线是 P-256（secp256r1，在 OpenSSL 称为 Prime256v1）和 x25519。P-256 是 NIST（美国国家标准技术研究所）和 NSA（美国国家安全局）推荐使用的曲线，而x25519 被认为是最安全、最快速的曲线。
ECC 名字里的”椭圆“经常会引起误解，其实它的曲线并不是椭圆形，只是因为方程很类似计算椭圆周长的公式，实际的形状更像抛物线，比如下面就展示了一个简单的椭圆曲线。
比起 RSA，ECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的 RSA，而 256 位的 ECC 则相当于 2048 位的 RSA。因为秘钥短，所以相应的计算量、消耗内存和带宽也就少，加解密的性能就会好，对于现在移动互联网非常有吸引力。
RSA 密钥长度随着保密级别提高，增加的很快。下表列出了对同一安全级别所对应的密钥长度
TLS 混合加密
说到这里，你是否已经认为可以抛弃对称加密了？只用非对称加密来实现机密性呢？
遗憾的是，任何“事情”都有利弊。虽然非对称加密没有”密钥交换“的问题，但因为它们都是基于复杂的数据难题，运算速度很慢，即使是 ECC 也要比 AES 差上好几个数量级。如果仅用非对称加密，虽然保证了安全，但通信的速度就要大打折扣。实际的应用价值就会降低。
那有没有一个折中的方案，既能保证机密性又兼顾性能？TLS 正是融合了两者的优势，对称加密和非对称加密各取所长，既能高效地加密解密，又能安全地密钥交换。这就是 TLS 里使用的混合加密方式。
那它们是如何折中配合完成这又好、又好的呢？说起来也简单：
“在通信的开始阶段使用非对称加密算法，例如 RSA、ECDHE，这样便解决了密钥交换的问题。然后用随机数产生对称算法使用的会话密钥（session key），再用公钥加密。因为会话的很短，通常只有 16 字节或 32 字节，性能损耗较小。对方拿到密文后用私钥解密，取出会话密钥。
这样，双方就实现了对称密钥的安全交换，后续就不再使用非对称加密，全都使用对称加密。这样混合加密就解决了对称加密算法密钥交换问题，而且安全和性能兼顾，完美地实现了机密性”。
下面我们再通过 TLS 的握手过程，再加深理解下这一过程（基于 TLS 1.2）。
TLS 握手过程
客户端与服务器在通过 TLS 交换数据之前，必须协商建立加密信道。协商内容包括 TLS 版本、加密套件，必要时还会验证证书。协商过程的每一步骤都需要一个分组在客户端和服务器之间往返一次，因而所有 TLS 连接启动时都要经历一定的延迟（我们这里不讨论性能）。
0 ms：TLS 在可靠的传输层（TCP）之上运行，这意味着首先必须完成 TCP 的“三次握手”，即一次完整的往返。
56 ms：TCP 连接建立之后，客户端再以纯文本形式发送一些规格说明，比如它所运行的 TSL 协议版本，它所支持的加密套件列表，以及它支持或希望使用的另一些 TLS 选项。
84 ms：然后服务器取得 TLS 协议版本以备将来通信使用，从客户端提供的机密套件列表中选择一个，再附上自己的证书，将响应发送回客户端。作为可选项，服务器也可以发送一个请求，要求客户端提供证书以及其他 TLS 扩展参数。
112 ms：假设两端经过协商确定了共同的版本和加密套件，客户端也把自己的证书提供给了服务器。然后客户端会生成一个新的对称密钥，用服务器的公钥来加密，加密后发送给服务器，告诉服务器可以开始加密通信了。到目前为止，除了用服务器公钥加密的新对称密钥之外，所有数据都以明文形式发送。
140 ms：最后，服务器解密出客户端发来的对称密钥，通过验证消息的 MAC 检测消息完整性，再返回给客户端一个机密的 “Finished” 消息。
168 ms：客户端用它之前生成的对称密钥解密这条消息，验证 MAC，如果一切顺利，则建立信道并开始发送应用数据。
协商建立 TLS 安全信道是一个复杂的过程，很容易出错。好在客户端和服务器会替我们做好这些工作，我们要做的就是提供和配置证书！
总结
通信双方通过非对称加密协商出一个用于对称加密的密钥，如果你能总结出这句话，说明你已经掌握了 TLS 实现机密性的原理。
虽然机密是安全性的基石，不过“万丈高原平地起”，后面的完整性、身份认证和不可否认特性如果不能得到保证，通信也不能算是绝对安全的。后面的部分我将在下期内容在详细讲解。
文中如有不妥或有更好的分析结果，欢迎您的分享留言或指正！
文章如果对你有帮助，请留个赞吧。
扩展阅读
网络优化系列
- 关于网络优化，你需要了解什么？
- 关于 5G，你应该知道的发展史
- HTTP 发展的前世今生
- Wireshark — 网络世界的“高速摄像机”
UI 优化系列
- 关于 UI 渲染，你需要了解什么？
- Android 之如何优化 UI 渲染（上）
- Android 之 Choreographer 详细分析
- Android 之你真的了解 View.post() 原理吗？
- RenderThread：实现动画的异步渲染
存储优化系列
- Android 存储优化系列专题
- Android 权限管理 — 只防君子不防小人
- Android 之不要滥用 SharedPreferences（上）
- Android 对象序列化之你不知道的 Serializable
- Android 存储选项之 SQLiteDatabase 源码分析