伴随着互联网的飞速发展和用户规模的迅猛增长，互联网长期面临着严峻的安全威胁和数据隐私风险。围绕HTTP流量的黑产在非法牟利的同时，对互联网用户体验及安全隐私带来严重影响，也给互联网服务提供商的声誉和利益带来巨大损失。使用HTTP协议面临的典型问题包括：
- 内容篡改：用户访问的页面内容被恶意篡改，例如搜索结果页链接被恶意修改、下载页面安装包被恶意替换、浏览页面植入大量广告等
- 隐私泄露：用户网络活动行为被嗅探，个人数据被泄漏及利用，受到垃圾广告或诈骗电话干扰等
- 流量劫持：用户访问被劫持到钓鱼网站，用户账号信息在诱导下被窃取等
HTTPS相比HTTP协议在底层使用了TLS协议传输，提供完整性、私密性、身份认证机制，可以保障互联网用户流量的接入安全。国内外诸多大型互联网公司已经全面支持HTTPS。浏览器厂商、移动应用商店等生态厂商也在加速推进HTTPS。例如：
- Google Chrome浏览器在HTTP域名输入框前增加“不安全”的提示。Google正推动 Chrome 浏览器将 HTTPS作为默认设置（而非 HTTP）。用户直接输入域名后，Chrome 将首先尝试使用 HTTPS协议访问。
- Apple iOS10 ATS (App Transport Security) 策略强制要求所以在iOS 应用商店上架的应用都必须支持HTTPS。
对于一个中大型的网站而言，全面HTTPS化除了需完成网站页面HTTPS改造，还面临以下重要问题：
-
访问速度问题：HTTPS相比HTTP一般会额外引入1～2个RTT。当然，这并不包括一些情况下用户首先访问HTTP再跳转到HTTPS的延迟，以及HTTPS证书状态检查所引入的延迟。在移动网络环境下往返延迟往往更大，还会带来更明显的影响。
-
性能及成本问题：协议握手及数据加密传输引入的密码学计算，带来不可忽视的性能开销。尤其是TLS握手过程中的非对称计算，是性能开销的主要来源。以Nginx为例，在短连接及完全握手情况下，HTTP相比HTTPS吞吐高达10倍。
-
安全性问题：正确的部署及保障HTTPS安全性，需掌握一定的安全领域知识及最佳实践。运维人员往往容易在HTTPS部署时留下安全隐患，无法满足业务运营所要求的安全合规标准。
-
可用性问题：HTTPS生态更为复杂，第三方CA成为网站稳定性的一个新依赖。同时，由于客户端的多样性，端协议实现的兼容性及缺陷，也可能导致服务访问异常。
常见的HTTPS优化手段简要说明如下。
HTTPS引入总延迟大小取决于往返延迟大小和往返交互次数。从用户访问流程角度看，HTTPS交互延迟既包括建立安全会话的延迟，还包括从HTTP向HTTPS跳转延迟及HTTPS证书状态检查延迟。相应的，我们可以通过如下多种方法来优化访问延迟。
| 优化方法 | 具体机制 |
|---|---|
| 降低往返延迟 | 通过在边缘节点完成TLS握手 |
| 减少交互次数 | 通过TLS会话复用握手来减少交互次数，其中TLS 1.2 需要2个RTT(含TCP握手)，而TLS 1.3只需1个RTT(含TCP握手)，使用QUIC只需0个RTT。此外，可以通过HSTS机制或重定向缓存机制，优化从HTTP再跳转到HTTPS的延迟；通过OCSP Stapling机制优化证书状态检查延迟。 |
| 隐藏交互延迟 | 通过启发式预建立连接，来屏蔽建连延迟的影响 |
HTTPS服务端在通信过程中，非对称密码学计算是性能开销的主要来源。非对称密码学算法安全长度的进一步提升还会加剧这个问题。例如自2010年起主流CA已停止签发不安全的 RSA 1024长度证书，并使用RSA 2048长度证书。针对非对称计算性能的优化有如下多种方法。
| 优化方法 | 具体机制 |
|---|---|
| 减少非对称计算次数 | 提升连接复用率、会话复用率来减少TLS完全握手及引入的非对称计算次数 |
| 优化非对称计算性能 | 通过硬件加速卡或支持密码学计算指令的CPU，提升非对称算法计算性能 |
| 优先使用高性能算法 | 自适应优先使用ECC证书而不是RSA证书（不具备硬件加速的场景） |
HTTPS安全性风险来源于CA基础设施、协议及算法漏洞、HTTPS部署配置、HTTP应用等。有一些公开服务支持自动评估HTTPS站点等安全性，并提示潜在的安全漏洞。
此外，HTTPS服务提供商需要制定并应用HTTPS部署最佳实践及规范。例如SSLLabs编写的《SSL/TLS部署最佳实践》，NIST发布的《保护Web事务的安全：TLS服务端证书管理》等。
同时，需建立关于HTTPS的监控机制。包括HTTPS证书监控、HTTPS混合内容监控、安全Cookie监控、HTTPS安全漏洞扫描等。
通过灰度机制及冗余机制，来支撑业务线构建变更风险小、止损速度快、更稳定可靠的HTTPS服务。相关机制（控制HTTP向HTTPS的灰度跳转、HTTPS证书灰度更新等）具体说明详见下文。
为更好适应大型站点的需求，BFE相比常见开源方案进行了一些针对性改进，下文针对一些差异化的机制简要介绍如下。
BFE支持将TLS会话状态，存储在分布式Cache集群中。客户端与BFE集群中任一实例连接后，可基于Session ID完成会话复用握手，从而提升在集群部署模式下的TLS会话复用率。
在上文分布式TLS会话缓存中，存储的会话状态可以采用两种格式：原始格式及OpenSSL格式。如果是BFE新用户，可优先使用原始格式，这种格式更紧凑可降低分布式缓存的存储开销；如果是需要替换基于OpenSSL反向代理，可以配置OpenSSL格式，这样两种程序可兼容读取对方保存的会话状态，实现平滑迁移而不影响会话复用握手。
如果Session Ticket key泄漏将无法保障前向安全性。基于Session Ticket会话复用的连接，如果恶意攻击者预先录制流量，后续使用泄漏的Session Ticket key，可以成功计算出会话密钥并解密还原出明文信息。
为了避免以上问题，应定期更新Session Ticket key文件。BFE支持热加载并更新Session Ticket key，同时无需进程热重启导致长连接中断。
OCSP Staple文件具有一定的有效期。如果握手过程中服务端意外发送了一个过期的OCSP Staple文件，可能导致握手失败。在一个大规模的分布式集群环境中，由于流程或机制原因导致OCSP Staple未及时成功更新或遗漏更新，这样的情况并不罕见。
BFE支持自适应处理即将过期的OCSP Staple文件。在OCSP Staple即将过期时，BFE将自动降级并停止发送OCSP Staple文件，避免潜在的握手失败影响。
非对称密钥算法在TLS握手过程中，一般用于身份认证及密钥交换。目前主流的非对称算法包含RSA/ECC。由于CA根证书兼容性原因，RSA类型证书依然是目前最广泛使用的证书。目前RSA算法建议的安全长度是2048位，相比等价强度的256位ECC算法而言，RSA算法的性能开销要远大于ECC。
如果用户流量全部来自自有移动端，或握手报文满足特定特征，可通过选择ECC类型证书及私钥，来减少非对称密码学计算引入性能开销。
如果用户流量大量来自低端客户端，则需要使用RSA类型证书及私钥以保证兼容性。通过使用支持RSA算法的硬件加速卡，可以大幅降低RSA计算引入性能开销。
基于硬件加速的方案一般有两种类型：
- 同机模式：同机部署支持RSA加速的CPU或部署RSA硬件加速扩展卡
- 远程模式：远程访问具备RSA硬件加速条件的非对称计算服务
远程模式相比同机模式的优势是：
-
不必全面升级现有的转发机器，降级升级周期及成本
-
可以弹性适配BFE转发机器的计算需求，避免硬件加速卡资源浪费（注：基于硬件加速卡）
-
可以为密钥提供集中式、基于硬件的安全保护机制（注：基于CPU特殊指令）
由于远程硬件加速服务可用性难以达到100%，为避免引入依赖远程硬件加速服务降低BFE整体可用性，在访问远程硬件加速卡出现偶发异常时，通过自动降级使用本地计算来消除影响。
在多租户的环境中，需要为不同的租户使用不同的证书。同一个租户由于业务原因（例如品牌考虑），也可能使用了多个证书。
在实际部署中，BFE为不同租户提供了不同的VIP，可以为不同的VIP配置不同的证书。
Google工程师统计发现现在Chrome代码库中所有严重的安全漏洞，70%都是内存管理的安全漏洞。微软工程师也宣称，微软过去12年的安全更新大概70%都是在解决内存安全漏洞。OpenSSL著名的心脏出血漏洞(Heatbleed Bug)被称为互联网史上最严重的安全漏洞之一，由于内存信息越界访问导致内存中敏感信息泄漏，波及了大量常用网站和服务。
受益于Go语言内置内存安全特性，BFE可以避免常见C语言缓冲区溢出内存问题所引发的安全问题。
正确配置服务的各项TLS/SSL参数（协议版本、加密套件）要求运维人员对TLS/SSL安全有较深入的理解。为降低管理员误配置引入部署安全风险，BFE提供了四种TLS安全等级，具体如下。不同安全等级下BFE所支持的TLS协议版本及加密套件是不同的。
| 安全等级 | 说明 |
|---|---|
| 等级A+ | 安全性最高、兼容性最低 |
| 等级A | 安全性较高、兼容性一般 |
| 等级B | 安全性一般、兼容性较高 |
| 等级C | 安全性最低、兼容性最高 |
相应的，不同安全等级具有不同的安全性及兼容性，适用不同的业务场景。例如，安全等级A+仅支持TLS 1.2及以上版本和安全强度更高的加密套件。等级A+适用于要求PCI DSS级别安全合规的业务场景，例如金融支付业务。
各安全等级的协议和加密套件的详细定义，见“配置HTTPS服务”中的说明。
使用硬件方案（HSM: Hardware Security Module）在硬件内部创建及保存私钥是最安全的方案。这种方案中涉及私钥相关的计算操作，由HSM硬件直接完成。私钥永远无法脱离HSM，也无法通过物理方式来提取。
如果不具备使用硬件的场景下，可以对密钥进行加密保护并定期更换密钥，在一定程度控制密钥泄漏的风险及影响。目前，CA厂商开始缩短签发证书的有效期，不再签发2年及以上有效期证书。
BFE支持根据ClientHello消息中特征，计算TLS/SSL客户端的指纹。BFE采用了JA3算法，可简单高效的识别客户端程序，并与业务层联动进行反爬取或反作弊。
在BFE中可以通过mod_header模块，在请求头部中携带JA3指纹传递给下游。具体用法参见开源BFE用户手册mod_header模块相关说明。
HTTPS化对旁路式流量攻击检测以及复杂网络问题诊断带来了挑战。旁路式攻击检测系统由于无法处理密文流量将无法有效工作。另外，研发运维人员有时依赖于对密文形式的网络抓包文件进行解密及分析。BFE可与旁路式攻击检测系统配合，通过安全共享会话密钥支撑其实现传输层、安全层、应用层等攻击特征分析。同时，在BFE还可选择性将TLS会话主密钥写入到key.log日志文件中，并供wireshark软件分析加密网络报文。
由于HTTPS改造的复杂性，从HTTP迁移到HTTPS需要一套灵活的灰度机制来控制跳转。BFE支持实现细粒度的策略，例如区分域名、客户端、用户地域等，设置灰度跳转策略。
证书变更是一个高风险的操作。证书链配置错误、证书链中级CA证书发送变化、证书中缺失必要扩展、证书格式不规范等，都可能触发兼容性问题，并导致证书更新后部分用户访问异常。可靠控制变更风险、快速发现潜在问题，对普通运维人员而言不可或缺。
BFE支持按用户抽样灰度更新证书，并支持实时统计新旧证书握手成功率变化，可以快速拦截在小流量阶段，难以通过总流量波动发现的异常。
CA成为HTTPS网站稳定性风险的一个新的来源。CA厂商的选型是一个关键的问题。除了考量CA厂商的证书成本，还需考量CA厂商的根证书兼容性、OCSP服务稳定性、安全合规历史记录、是否是核心主营业务等。
随着HTTPS的大规模普及推广，近年来主流CA厂商引发的HTTPS重大故障并不罕见。例如，2016年GlobalSign由于OCSP服务故障影响了多个知名的大型网站。2018年全球最大的CA厂商Verisign由于安全违规，Chrome/Firefox/Safari等浏览器开始停止信任Symantec签发证书。
HTTPS站点在有条件情况下可以通过签发多个CA厂商的证书实现冗余互备。当某个CA厂商证书访问连通率异常时，可以快速切换迁移至其它CA证书止损。