HTTPS安全连接主要通过 身份认证、数据加密、完整性保护 三方面保证安全性。 iOS中HTTPS的安全连接问题
在通信方的 身份认证 我们通常是客户端通过验证服务器CA证书来保证安全性的，这个证书一般是从第三方权威机构买的，那么我们具体该怎么验证CA证书？
CA证书是自下而上的逐级验证的，从CA证书往上一直到根证书都是信任的就可以认为证书是可信任的。
采用CA证书中相同的散列函数计算明文信息得到信息摘要A --》用CA的公钥解密签名得到信息摘要B --> 如果信息摘要一致，则可以确认证书的合法性，即公钥合法（服务方 S 的公钥）--> 查询证书是否吊销、比对证书中的域名信息、有效时间等是否一致(可将证书内置在APP中比对公钥和域名) --> CA证书验证通过
CA验证通过之后以相同的原理验证“中间证书”，直到根证书，根证书是系统内置信任的。
证书的吊销有两种机制： CRL 与 OCSP 。
证书中一般会包含 CRL 或 OCSP 的地址
证书验证通过了，接下来看另一个问题：非对称加密的方式交换对称加密的秘钥，如何保证交换过程的安全性的？
对于客户端，要让用户生成证书是比较麻烦的，比如我们做iOS开发时，开发证书就是要自己按照步骤去生成，而且一个账号最多只能生成3个证书。
iOS APP签名机制原理详解
为了加快建立握手的速度，减少协议带来的性能降低和资源消耗，TLS 协议有两类会话缓存机制：会话标识 session ID 与会话记录 session ticket。
Session ID 相当于一个验证码(但是可以重复使用)，由服务器生成，半个小时没有使用就失效，使用就重置为半个小时有效期。http请求使用同一个 Session ID 就认为是在同一个session里面。
在HTTPS连接已经建立的情况下，我们的服务器或者客户端在特定的情况下可以主动发起重新建连接，重新进行TLS握手，并且重建连接是在原来的TCP连接之上的，比如以下情况：
HTTPS连接虽然安全, 但是在原来HTTP的基础上多了TLS握手的过程，增加了RTT延时；多了加解密的过程，会消耗更多的服务器CPU资源。
优化的方向主要有：
全站 HTTPS 的时代已经来了，你准备好了吗？
Session会话恢复：两种简短的握手总结SessionID&SessionTicket