HTTPS安全性的几个具体问题

HTTPS安全连接主要通过身份认证、数据加密、完整性保护三方面保证安全性。iOS中HTTPS的安全连接问题
在通信方的身份认证我们通常是客户端通过验证服务器CA证书来保证安全性的，这个证书一般是从第三方权威机构买的，那么我们具体该怎么验证CA证书？

一、证书链验证

1. CA证书的生成过程

首先我们来了解CA证书的生成和使用流程（图是借的） CA 的使用流程

• 证书的生成：
  服务器域名/申请人信息/组织信息/服务器公钥 ---> 向服务商申请生成.csr文件（Certificate Sign Request） ---> 提交csr文件给CA机构的第三方证书服务机构进行信息审核 ---> 审核通过，签发证书。

• 证书包含的内容：
  主要包含如上图所述的明文信息、签名，其中签名的生成是：
  明文信息 --> 散列函数加密生成密文 --> 使用CA私钥对密文进行加密生成签名。

• 证书链

  
  证书链

  我们向第三方购买的证书一般是3或4级证书，可能有多个中间证书（如图），根证书是客户端内置的，从根证书到中间证书再到CA证书形成一条证书链。

2. CA证书的验证过程

CA证书是自下而上的逐级验证的，从CA证书往上一直到根证书都是信任的就可以认为证书是可信任的。
采用CA证书中相同的散列函数计算明文信息得到信息摘要A --》用CA的公钥解密签名得到信息摘要B --> 如果信息摘要一致，则可以确认证书的合法性，即公钥合法（服务方 S 的公钥）--> 查询证书是否吊销、比对证书中的域名信息、有效时间等是否一致(可将证书内置在APP中比对公钥和域名) --> CA证书验证通过
CA验证通过之后以相同的原理验证“中间证书”，直到根证书，根证书是系统内置信任的。

3. CA证书的吊销

证书的吊销有两种机制：CRL 与 OCSP。
证书中一般会包含CRL 或 OCSP的地址

OCSP的地址

• CRL（Certificate Revocation List）证书吊销列表文件

文件包含了 CA 已经吊销的证书序列号（唯一）与吊销日期，包含了生效日期及下次更新该文件的时间，当然该文件必然包含 CA 私钥加密后得到的签名用来验证文件的合法性。
该吊销方式的优点是不需要频繁更新，但是不能及时吊销证书。因为 CRL 更新时间一般是几天，这期间可能已经造成了极大损失。

• OCSP(Online Certificate Status Protocol)在线证书状态协议

实时查询证书是否吊销。请求者发送证书的信息并请求查询，服务器返回正常、吊销或未知中的任何一个状态。证书中一般也会包含一个 OCSP 的 URL 地址，要求查询服务器具有良好的性能。

证书验证通过了，接下来看另一个问题：非对称加密的方式交换对称加密的秘钥，如何保证交换过程的安全性的？

二、对称加密的秘钥是怎么安全交换到服务器的

TLS握手的过程.png
由上图可以得知，协商秘钥（安全通道建立后通信使用的对称加密的秘钥）的生成需要3个随机数，客户端和服务器双方都参与了随机数的生成，而且最后的随机数 Pre-master 是公钥加密后传送到服务器的，只有拥有私钥的服务器能解开，所以是能保证协商秘钥的安全性。

另外的安全性隐患：

• 另一方面，在发送client_hello和sever_hello报文时，其实是明文的，这个时候如果是有中间人攻击，把客户端支持的协议版本号降低为安全性更低的版本的协议比如：TLS1.1 -> SSL 1.0，那么后续的通信使用了更低安全性的加密算法，也存在安全隐患.
• 假如客户端、服务器生成随机数不随机或者有规律，这个问题也存在安全隐患。
  TLS也是有解决办法的详见：HTTPS 加密的细节

• 证书的双向验证
  上面的过程是客户端验证服务器证书，是单向的，我们一般情况下也是单向验证就可以了；如果对安全性有更高的要求，服务器也要验证客户端证书来验证客户端身份合法性，这时候就是双向验证了，服务器可以在TLS握手的过程中向客户端发送client_certificate_request请求，验证的原理也是一样的。

对于客户端，要让用户生成证书是比较麻烦的，比如我们做iOS开发时，开发证书就是要自己按照步骤去生成，而且一个账号最多只能生成3个证书。
iOS APP签名机制原理详解

三、会话缓存握手过程

为了加快建立握手的速度，减少协议带来的性能降低和资源消耗，TLS 协议有两类会话缓存机制：会话标识 session ID 与会话记录 session ticket。

• Session ID的再次连接
  Session ID是协议中的标准字段，因此基本所有服务器都支持。服务器端保存会话 ID 以及协商的通信信息，Nginx 中 1M 内存约可以保存 4000 个 Session ID 机器相关信息，占用服务器资源较多，客户端只保存服务器返回的Session ID的值；由于Session ID主要保存在服务器主机Server Cache中，在多个服务器主机的情况下就容易出现需要重新连接的情况。
  SessionID会话恢复.png

Session ID相当于一个验证码(但是可以重复使用)，由服务器生成，半个小时没有使用就失效，使用就重置为半个小时有效期。http请求使用同一个Session ID就认为是在同一个session里面。

• Session Ticket的再次连接
  使用Session Ticket可以避免多个服务器主机的问题，实现的方式是：在第一次建立连接后服务器会用公钥加密会话数据，发送给客户端保存，服务器不保存，客户端后续发送请求时会携带Session Ticket信息, 服务器收到之后用私钥解密Session Ticket即得到之前的秘钥之类的信息，接下来的恢复会话就跟Session ID的一致了，最后，在恢复连接后会更新一次Session Ticket的有效期生成新的Session Ticket发给客户端，这点是不同于Session ID。

四、重建连接

在HTTPS连接已经建立的情况下，我们的服务器或者客户端在特定的情况下可以主动发起重新建连接，重新进行TLS握手，并且重建连接是在原来的TCP连接之上的，比如以下情况：

• 服务器重建连接，服务器端重建连接一般情况是客户端访问受保护的数据时发生。
• 客户端重建连接，客户端重建连接一般是为了更新通信密钥。

五、HTTPS优化

HTTPS连接虽然安全, 但是在原来HTTP的基础上多了TLS握手的过程，增加了RTT延时；多了加解密的过程，会消耗更多的服务器CPU资源。
优化的方向主要有：

• CDN 接入
  HTTPS 增加的延时主要是传输延时 RTT，RTT 的特点是节点越近延时越小。CDN 基于就近访问的原则，天然离用户最近，因此选择使用 CDN 作为 HTTPS 接入的入口，将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少 HTTPS 带来的延时。
• 会话缓存
  虽然前文提到 HTTPS 即使采用会话缓存也要至少 1*RTT 的延时，但是至少延时已经减少为原来的一半，明显的延时优化。同时，基于会话缓存建立的 HTTPS 连接不需要服务器使用 RSA 私钥解密获取 Pre-master 信息，可以节省 CPU 的消耗。如果业务访问连接集中，缓存命中率高，则 HTTPS 的接入能力将明显提升。当前 TRP 平台的缓存命中率高峰时期大于 30%，10k/s 的接入资源实际可以承载 13k/s 的接入，收效非常可观。
• 硬件加速
  为接入服务器安装专用的 SSL 硬件加速卡，作用类似 GPU，释放 CPU，能够具有更高的 HTTPS 接入能力并且不影响业务程序。测试某硬件加速卡单卡可以提供 35k 的解密能力，相当于 175 核 CPU，至少相当于 7 台 24 核的服务器。考虑到接入服务器其它程序的开销，一张硬件卡可以实现接近 10 台服务器的接入能力。
• 远程解密（自用且规模不大不建议使用）
  采用本地接入方式消耗过多的 CPU 资源，浪费了网卡和硬盘等资源。考虑将最消耗 CPU 资源的 RSA 解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。远程解密的方式也是 CDN 提供大规模 HTTPS 接入的解决方案之一。
• SPDY/HTTP2
  前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能，但是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优势，通过修改协议的方法来提升 HTTPS 的性能，提高下载速度等。

全站 HTTPS 的时代已经来了，你准备好了吗？
Session会话恢复：两种简短的握手总结SessionID&SessionTicket