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的地址
- 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
网友评论