HTTPS 及 Objective-C 中的使用

1. HTTPS

HTTPS 是对 HTTP 协议的扩展，我们可以使用它在互联网上安全地传输数据，使用安全套接字层（Secure Sockets Layer，SSL）保证数据传输的安全，随着传输层安全协议（Transport Layer Security，TLS）的发展，目前已经使用 TLS 取代了废弃的 SSL 协议，不过仍然使用 SSL 证书一词。
HTTPS 安全是由一套安全机制来保证的，主要包含这4个特性：机密性、完整性、真实性和不可否认性。

• 机密性：传输的数据是采用Session Key（会话密钥）加密的，在网络上是看不到明文的。
• 完整性：为了避免网络中传输的数据被非法篡改，使用MAC算法来保证消息的完整性。
• 真实性：通信的对方是可信的，利用了PKI（Public Key Infrastructure 即『公钥基础设施』）来保证公钥的真实性。
• 不可否认性：使用了签名的技术来保证消息的发送方，无法伪装和否认。

1.1 TLS

TLS 的作用是在可靠的 TCP 协议上构建安全的传输通道，其本身是不可靠的，需要下层可靠的传输层协议。在通信双方建立可靠的 TCP 连接后，就需要通过 TLS 握手交换双方的密钥了。

1.1.1 功能实现

主要依赖于三类基本算法：散列（哈希）函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列（哈希）函数验证信息的完整性。

非对称加密与对称加密

• 效率：对称加密的主要运算是位运算，速度非常快；但非对称加密计算一般比较复杂，里面设计到大数乘法、大数模等等运算。
• 空间：对称加密中，当信息量大时，要求密钥量也要足够大，需要每两个人之间都有一个密钥，对于n个人，需要n(n-1)/2个密钥；非对称加密中，每个人都有私钥和公钥，对于n个人，只需要2n个密钥就能保证安全。

1.1.2 四次握手

1. 客户端向服务端发送 Client Hello 消息，其中携带客户端支持的协议版本、加密算法、压缩算法；
2. 服务端收到客户端支持的协议版本、加密算法等信息后；
   1. 向客户端发送 Server Hello 消息，并携带选择特定的协议版本、加密方法、会话ID；
   2. 向客户端发送 Certificate 消息，即服务端的证书链，其中包含证书支持的域名、发行方和有效期等信息；
   3. 向客户端发送 Server Key Exchange 消息，传递公钥以及签名等信息；
   4. 向客户端发送可选的消息 CertificateRequest，验证客户端的证书；
   5. 向客户端发送 Server Hello Done 消息，通知服务端已经发送了全部的相关信息；
3. 客户端收到服务端的协议版本、加密方法、会话 ID 以及证书等信息后，验证服务端的证书；
   1. 向服务端发送 Client Key Exchange 消息，包含使用服务端公钥加密后的随机字符串，即预主密钥（Pre Master Secret）；
   2. 向服务端发送 Change Cipher Spec 消息，通知服务端后面的数据段会加密传输；
   3. 向服务端发送 Finished 消息，其中包含加密后的握手信息；
4. 服务端收到 Change Cipher Spec 和 Finished 消息后；
   1. 想客户端发送 Change Cipher Spec 消息，通知客户端后面的数据段会加密传输；
   2. 向客户端发送 Finished 消息，验证客户端的 Finished 消息并完成 TLS 握手；

TLS 握手的关键在于利用通信双方生成的随机字符串和服务端的公钥生成一个双方经过协商后的密钥，通信的双方可以使用这个对称的密钥加密消息防止中间人的监听和攻击，保证通信的安全。

在 TLS 1.2 中，需要 2-RTT 才能建立 TLS 连接，但是 TLS 1.3 通过优化协议，将两次往返延迟降低至一次，大幅度减少建立 TLS 连接所需要的时间，让客户端可以在 1-RTT 后就能向服务端传输应用层数据。

除了减少常规握手下的网络开销，TLS 1.3 还引入了 0-RTT 的连接建立过程；60% 的网络连接都是用户在第一次访问网站或者间隔一段时间后访问时建立的，剩下的 40% 可以通过 TLS 1.3 的 0-RTT 策略解决，然而该策略是通过重用会话和缓存来实现的，所以存在一定的安全风险，使用时也应该结合业务的具体场景。

1.2 HTTP

建立好 TCP 和 TLS 通道后，HTTP 协议可以直接利用下层建立的可靠的、安全的通道传输数据。客户端通过 TCP 的套接字接口向服务端写入数据，服务端在接收到数据、进行处理后通过相同的途径返回。因为整个过程需要客户端发送请求以及服务端返回响应，所以耗时是 1-RTT。

HTTP 协议的数据交换只会消耗 1-RTT，当客户端和服务端仅处理一次 HTTP 请求时，从 HTTP 协议本身我们已经无法进行优化。不过随着请求的数量逐渐增加，HTTP/2 就可以复用已经建立的 TCP 连接减少 TCP 和 TLS 握手带来的额外开销。

1.3 RTT

当客户端想要通过 HTTPS 请求访问服务端时，整个过程需要经过 7 次握手并经历 4.5-RTT。

1. TCP 协议需要通过三次握手建立 TCP 连接保证通信的可靠性（1.5-RTT）；
2. TLS 协议会在 TCP 协议之上通过四次握手建立 TLS 连接保证通信的安全性（2-RTT）；
3. HTTP 协议会在 TCP 和 TLS 上通过一次往返发送请求并接收响应（1-RTT）；
   HTTP/3 会使用基于 UDP 的 QUIC 协议进行握手，将 TCP 和 TLS 的握手过程结合起来，把 7 次握手减少到了 3 次握手，直接建立了可靠并且安全的传输通道。

2. CA 证书

2.1 作用

1. 颁发证书，颁发证书其实就是使用 CA 的私钥对证书请求签名文件进行签名；
2. 客户端只需要用 CA 的公钥进行验签成功就表示这个证书是合法可信的，这就需要客户端内置 CA 的公钥，也就是内置 CA 的证书。一般来说，操作系统都会内置权威 CA 的证书。.

2.2 签发及使用过程

1. 服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;（不交私钥）
2. CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
3. 如信息审核通过，CA会向申请者签发认证文件-证书。
   1. 证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名;
   2. 签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名;
4. 客户端 C 向服务器 S 发出请求时，S 返回证书文件;
5. 客户端 C 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的