HTTPS原理及实践(by 林坤潮）
一、背景
1、网络劫持的危害
2、网络劫持的分类
3、到底是谁在劫持
二、防范网络劫持的最佳方案——HTTPS
三、HTTPS 简介
四、HTTPS 是如何提供安全保障
1、HTTPS 协议交互过程
2、三大安全机制
1）身份认证
2）数据加密
3）完整性校验
五、HTTPS 的普及为何困难重重
1、难 -> 易
2、贵 -> 廉
3、慢 -> 快
六、HTTPS 的发展趋势
更广
更强
更快
更开放
参考资料
一、背景
1、网络劫持的危害
1）隐私泄露
- 登录态窃取：也就是账号被盗用，如果登录态没有设置隔离，一个应用的账号被盗用，可导致多个应用同时沦陷。
- 个人敏感信息：未经过加密处理的敏感信息如手机、邮箱、银行卡、身份证等，被监听窃取后，将会在黑市中贩卖，然后用于广告或诈骗之类的，对用户导致伤害也是很大的。
2）内容劫持
- 广告：有些劫持是直接在网页中插入广告，对于用户来说影响了用户体验，另外有些还可能是诈骗网站。如果网站本身是电商，那用户被引流到其他电商去，还会造成经济损失。
- 木马：网站如果直接插入了恶意的代码，那么用户受到的危害则更大，结合其他漏洞，黑客可以在用户的电脑上为所欲为。
2、网络劫持的分类
1）按劫持路径分类
- 客户端劫持：通过在客户端系统层植入木马，或者在浏览器中植入恶意插件，都属于客户端的劫持
- 链路劫持：通过路由器，分光器等在网络传输劫持的都属于链路劫持
- 服务端劫持：顾名思义是入侵服务器之后，在服务器上监听流量，此类监听更倾向于获取内网信息，而不是业务用户的信息。
2）按劫持内容分类
- DNS劫持：直接将用户的访问解析到非官方的服务器，所以用户看到的服务都是假的
- 页面内容篡改：用户访问的还是官方的服务，但页面多了些奇奇怪怪的内容，一般是插入广告
- URL篡改：用户访问的是官方内容，而且页面也是正常的，仅仅是修改了URL的参数，这种场景是有些广告商使用一个参数指定流量方，而流量劫持方篡改了这个参数，使得流量提供方的收益到了劫持方的口袋。
3、到底是谁在劫持
1）ISP与流量广告商
监守自盗，本来ISP就有义务保护用户不受网络劫持，然而有些小运营商还是会铤而走险，赚取这些不义之财。用户如果发现被运营商劫持，可以打电话投诉，一般就会把你加白，下次不敢骚扰你。
2）公共wifi
天下没有免费午餐的道理大家都懂，然而就是容易管不住自己的手。由于wifi ssid不是唯一的，无法保证服务提供的身份真实性。例如一个用户访问过CMCC，然后黑客伪造一个同名wifi，用户在黑客的wifi信号下，就会自动连接，因为wifi协议会认为这两个是同一个网络。
3）路由器和其他终端设备厂商
这类更可恶了，拿你设备的钱还不够，还要榨干你其他价值，例如某些厂商路由器就有这种行为，一般是篡改页面内容，插入广告。
二、防范网络劫持的最佳方案——HTTPS
由于网络劫持的普遍性和危害，所以非常有必要采取些防范措施，而HTTPS则是公认的最佳方案，互联网的各大巨头也纷纷采取了各个措施，鼓励大家使用HTTPS，而放弃HTTP。
- Chrome V68/FireFox V59：HTTP 标记为不安全网站
- IOS ATS：要求所有APP使用HTTPS（不过延期了，后面会介绍改造https的困难）
- 各大搜索引擎：HTTPS网站排序优先，利于网站SEO
另外，诸多公司和产品也已切换HTTPS：Google、Facebook、阿里、百度等，所以全面使用HTTPS是未来的趋势。
下图是全球HTTPS覆盖的进展（样本100万URL,From：http://httparchive.org）
从2016年1月到2018年底，花了将近3年的时候，艰难地从24%到77%（手机端趋势也相近）
三、HTTPS 简介
HTTPS是在HTTP的基础上，加上了TLS/SSL 层，从而来实现身份验证、信息加密、完整性校验等安全性。
TLS/SSL 目前已有多个版本，但TLS 1.0 及之前的版本，由于存在漏洞，已被认为是不安全版本，业内现在主流使用的是TLS1.2。而1.3 版本是2018年下半年发布的，目前各大浏览器还在处于兼容阶段，暂未开始普及。
1.3 版本不仅提高了安全性，还是提高了传输效率，主要变化如下：
- 废弃了RSA密钥交换算法；3DES、RC4、AES-CBC等加密组件；废弃了SHA1、MD5等哈希算法。
- 支持0-RTT数据传输 。
- 不再允许对加密报文进行压缩、不再允许双方发起重协商，密钥的改变不再需要发送change_cipher_spec报文给对方。
- 握手阶段的报文可见明文大大减少。
四、HTTPS 是如何提供安全保障
1、HTTPS 协议交互过程
1、协议版本、密码套件协商
- 期望协议版本
- 可供采用的密码套件
- 客户端随机数
2.1、协议版本、密码套件协商
- 采取的协议版本
- 采用的密码套件
- 服务端随机数
- 用于恢复会话的会话ID
2.2、发送证书链（含CA证书）
2.3、密钥生成参数（由算法决定）
2.4、通知客户端完成
3.0、校验服务器证书
- 是否“受信任的根证书颁发机构”颁发
- 是否吊销（证书吊销列表）
- 是否过期
- 域名是否一致
3.1、证书公钥加密“密钥参数”
3.2、生成对称密钥，声明后续是加密信息
3.3、发送消息签名，防篡改
4.1、生成对称密钥，声明后续是加密信息
4.2、发送消息签名，防篡改
2、三大安全机制
身份认证 —— 防伪造（非对称加密）：确保正确的用户访问正确的网站
数据加密 —— 防窃听（对称加密） ：使第三方无法查看明文内容
完整性校验 —— 防篡改（哈希算法）：内容被篡改能及时发现
1）身份认证
1.1） 证书内容
关键字段：公钥及其算法、签名及其算法（保障证书有效性的关键）
主要字段：使用者、颁发者、有效期、证书路径、证书状态
1.2） 证书类型
不同类型证书提供的安全性是一致的，这个是由HTTPS原理决定的。
而主要差异则是其他的增值服务，例如审核的严格程度、证书失效的赔偿保险金、浏览器地址栏图标显示等。
1.3） 证书什么情况会无效？
国内知名的网站12306，就由于证书在浏览器显示不受信任，引起了很多讨论，而原因是它的证书是自签名的，也就自家给自己发的证书，自己当自己的CA，而它这个CA没获得浏览器的默认认可。
这样就需要用户手工将12306的证书安装到浏览器，体验非常差，而且给人一种很不专业的感觉。
不过在2018年10月，他们终于改过自新，在有公信力的CA申请了证书，改变了这个囧况。
而原本就是可信的证书，在哪些场景会失效呢？
- 证书到期：有些业务由于对证书管理不到位，未及时更新证书，这会导致业务无法正常访问。
- 证书注销：如果一个证书的私钥泄露了，那么就需要将证书注销，单从证书上无法看到是否注销，而是需要通过查询CRL（证书注销列表）来判断。
- CA变更（证书链变化、CA根证书变为不可信）：如果CA主动调整了证书链，那原有的证书就会失效，这种场景CA会提前通知用户更新证书。如果CA机构被黑客攻击，导致证书私钥泄露，从而黑客可以使用该私钥来伪造证书，那么CA就会失去公信力，然后浏览器就不会默认信任该CA的证书。严重的情况，CA可能会倒闭，而相关的用户也会由于证书失效而获得保险赔偿。
2）数据加密
数据加密的算法有2类，对称加密和非对称加密，两者的区分是通过加解密的密钥来区别，
对称加密的加密和解密使用的是同个密钥，常见算法有DES、AES。
非对称加密和解密使用的密钥是不同的，一个是公钥（公开给其他人用于加密），一个是私钥（用于解密数据），常见算法有RSA、ECC。
对称加密示意图
非对称加密示意图
问题：两种加密算法都可以达到加密的效果，但为什么实际应用中往往同时使用两种加密方式？
这是由于两种加密算法都有其不足，而两种同时使用可以弥补其不足
- 对称加密：加解密前，需要双方都需要知道密钥，而对称加密无法实现交换密钥的功能，因为它的密钥如果通过不可信网络直接传输，那就会被监听到了。而非对称加密，由于公钥是可以公开的，不用担心被监听窃取的问题。
- 非对称加密：只采用非对称加密其实就可以实现在不可信网络中加密信息传输，但是由于非对称加密算法比较消耗计算资源，比对称加密高2个数量级，所以非对称加密就只用于加密“对称加密的密钥”，然后具体数据加密的时候，就采用对称加密。未来随着硬件计算能力的提高，或者有更低计算资源的非对称加密算法，使得两者的性能差别可以忽略不计，那么可能就只需要非对称加密，而不需要两种混用了。
3）完整性校验
完整性的校验是通过验证Hash值来验证的，Hash就是把任意长度的输入，通过散列算法，变换成固定长度的输出，该输出就是散列值。这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，而不可能从散列值来唯一的确定输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。
而为了进一步提高安全性，HTTPS使用MAC（消息认证码，即带密钥的Hash函数）。
验证过程如下：
1）发送方计算出要传输的信息对应的MAC，然后和信息一起发送给接收方
2）接收方使用同样的方式计算出对应的MAC，然后和接收到的MAC对比，如果一致则说明未被篡改
五、HTTPS 的普及为何困难重重
因为HTTPS 有以下这些不足：“难贵慢”，有种为了安全牺牲一切的感觉。
当然，有不足我们应该优化，让它在保护我们的同时，更好地为我们服务。
1、难 -> 易
- 证书申请&管理 —— 流程简化
前面也介绍了申请证书需要提供较多的资料证明域名所有权以及企业相关证明，这些繁琐的手续会降低证书申请的效率。所以为流程简化，搭建证书管理平台是一个比较好的方式，对于业务侧，只需要输入域名和证书类型，即可申请证书。
另外一个问题是关于证书管理，众所周知，证书是有有效期的，如果超过了有效期，证书将无法使用，轻则访问网站提示网站不安全，重则业务出现故障无法访问（客户端容易出现这类问题），有时候申请证书之后，一般没有人会去专门记住证书的有效期，而且由于人员流动问题，当初申请证书人员已不在职，证书更加是个无人管理的状态。
正因为此，所以证书管理平台在证书到期前，设置自动提醒机制，也方便管理员统一申请新证书，并更换证书，确保业务能持续正确运行，而业务无需关注有效期问题。
- 服务器配置 —— 接入层统一
配置SSL时，需要考虑SSL版本、加密算法、openssl 版本等，这些如果选择错误，就会导致安全问题，所以这里使用会有一定门槛，即需要知道怎么配置才是安全的，同时能够与用户环境的兼容。
通过统一的接入层平台，可以对配置进行统一管理，业务侧无需关注配置细节，在平台上只需要在“接入协议”选择https即可，减少误配置的情况。
- 客户端兼容 —— 提供HTTP日志
在改造整个域名为HTTPS的过程，最大的阻力就是在客户端的兼容性问题。对于纯网站的域名改造，也许只需要配置HTTP 302跳转到HTTPS即可，非常方便（当然部分页面可以需要调整一下兼容性）。
而对于客户端（业务侧相应的APP或服务，而非浏览器），则会比较困难，改造过程需要逐个URL确认。而有时由于一些客观原因，导致对调用方服务了解不全面，会有遗漏的改造点。
这种情况，平台统一提供了相应的日志，可以方便快捷地查询改造遗漏点。（由于全量域名日志比较大，域名需要主动开启日志才会保存，在平台为可配置项，并且日志为抽样数据）
2、贵 -> 廉
2.1 证书费用
证书是需要花钱买的，域名多了，价格也是不菲，下面是2018年的不同提供商的价格参考列表
证书合理的规划和申请，也是可以节省不少费用，一般是遵循以下两个小原则
- 通配符域名：共用一张通配符证书
- 其它的单域名：共用一张多域名证书
2.2 设备资源 —— 优化性能
对数据加密需要消耗大量的计算资源，特别是非对称加密的算法，在无任何优化的情况下，HTTPS 比HTTP 消耗资源多了好几倍，所以优化性能可以减少较多的成本，使用HTTPS资源成本在可接受范围内。
关于性能优化的细节，我们在下一节“慢 -> 快”里详细介绍我们是如何又快又省。
3、慢 -> 快
HTTPS 慢的原因有2方面：
- 网络耗时高：最坏情况增加7个RTT（round trip time）
- 计算耗时高：客户端50ms以上，服务端15ms以上
3.1 网络耗时 —— 减少RTT
各个网络环境RTT耗时如下：可以看到在2G、3G时代下，使用HTTPS是非常影响用户体验的，这也是企业使用HTTPS的重要阻力。
下图是使用HTTPS 对应的RTT，我们来看看哪些环节是可优化的
HTTPS 交互过程：
（1）一个普通用户使用HTTP访问服务器，首先是TCP握手，默认是80端口
（2）然后客户端正式发送数据给服务器，服务器返回302，告诉用户，不好意思，80端口不接客，请从443端口过来
（3）于是用户使用HTTPS访问服务器，由于换了个端口，默认是443端口，所以得重新握手
（4）终于进入了正题，开始了TLS的握手，服务器也返回了相应的证书
（5）-（7）客户端为了验证证书是否正确，得去CA机构求证，于是，解析CA域名、tcp握手、OCSP请求及响应，这里足足增加了3个RTT。不过客户端是有一定缓存，不需要每次都向CA校验证书
（8）确认对方是个好人，进行入TLS握手第二阶段，完成秘钥交换
（9）双方开始说悄悄话
双方交互过程如此繁琐，可优化的点很多，各个层面可优化项如下：
- TCP层
- TCP fast open
- SSL层
- session cache
- TLS false start
- 动态recode size
- OCSP stapling
- TLS 1.3
- 应用层
- HSTS
- HTTP2
- 多路复用
- 头部压缩
- QUIC
- 无TCP队头阻塞
- 0 RTT
下面对各项优化进行具体介绍
- TCP层
TFO(TCP fast open)：是TCP协议的experimental update，它允许服务器和客户端在连接建立握手阶段交换数据，从而使应用节省了一个RTT的时延。
但是TFO会引起一些问题，因此协议要求TCP实现必须默认禁止TFO。需要在某个服务端口上启用TFO功能的时候需要应用程序显示启用。TCP 需要客户端操作系统层支持，这点使它的兼容性差。
开启TFO之后，交互过程的（1）和（2）、（3）和（4）就可以合并发送，从而减少2个RTT。
- SSL层
- session cache：每次新的TLS连续都需要握手，以便创建共享的加密密钥，在TCP三次握手之上还需要两个RTT。如果使用了cache，那么就不需要重新交换密钥了。
即交互过程的（4）-（8），最多可以减少5个RTT
-
- TLS False Start：是Google提出来的优化方法，其做法是：在TLS协商第二阶段，浏 览器发送ChangeCipherSpec和Finished后，立即发送加密的应用层数据，而无需等待服务器端的确认。
即交互过程的（8）和（9）合并，节省一个RTT
-
- 动态recode size：TLS协议又由两层协议构成 ：TLS记录协议 (TISRecord)以及 TLS握手协议 ，较低的一层 为 TLS Record协议。
所有通过 TLS 交付的应用数据都会根据TLS Record协议传输。每条记录大小叫TLS Record size, 上限 为 16 KB。Size值如果过小，头部负载比重就会过大，最高可达6%。Size值如果过大，那单个Record在TCP层会被分成多个包发送。浏览器必须等待这些全部达到后，才能解密，一旦出现丢包、拥塞、重传、甚至重新建立的情况，时延就会被相应增加。
动态recode size就是根据 TCP 连接速度的提升（或者收到拥塞控制而下降）动态调整记录大小。在每个连接刚开始时，使用较小的记录大小，使之能与 TCP 能够发送的大小相匹配。一旦连接运行起来，就可以增加记录大小。
这种方式不直接减少RTT，而是优化了交互过程（9）在传输过程的吞吐率和时延。
-
- OCSP Stapling：OCSP 是一个在线证书查询接口，它建立一个可实时响应的机制，让 浏览器可以实时查询每一张证书的有效性，解决了 CRL 的实时性问题，但是 OCSP 也引入了一个性能问题，某些客户端会在 SSL 握手时去实时查询 OCSP 接口，并在得到结果前会阻塞后续流程。
OCSP Stapling 就是为了解决 OCSP 性能问题而生的，其原理是：在 SSL 握手时，服 务器去证书 CA 查询 OCSP 接口，并将 OCSP 查询结果通过 Certificate Status 消息发送给浏览器，从而让浏览器跳过自己去验证的过程而直接拿到结果，OCSP 响应本身有了签名，无法伪造，所以 OCSP Stapling 既提高了效率也不会影响安全性。另外服务器有更好的网络，能更快地获取到 OCSP 结果，同时也可以将结果缓存起来，极大的提高了性能、效率和用户体验。
即交互过程的（5）-（7），可以减少3个RTT
-
- TLS 1.3：首次访问的时候，由于使用ECDH密钥交换算法，只需要一个RTT完成密钥交换，即（4）和（8）可以合并为一个。另外，在后续的交互过程中，由于客户端会保存server加密密钥，下次通信直接加密，即（4）和（8）两个RTT都可以节省。
- 应用层
- HSTS：HTTP Strict Transport Security 的作用是只要客户端曾经与服务器创建过一次安全连接，后续就会强制客户端（如浏览器）使用HTTPS与服务器创建连接，即浏览器会自动将HTTP改为HTTPS，而不需要等服务器302告知，再改为HTTPS，从而可以减少302跳转。一方面是降低被劫持风险，另一方面是减少了交互过程（1）和（2）的两个RTT
- HTTP2：它在传输层解决了以前HTTP1.x中一直存在的问题。使用它可以优化我们的应用。HTTP2的首要目标是通过完全的请求，响应多路复用，头部的压缩头部域来减小头部的体积，添加了请求优先级，服务端推送。
- 多路复用：在HTTP 1.x中,用户想要多个并行的请求来提高性能,但是这样必须得使用多个TCP连接.这样的操作是属于HTTP 1.x 发送模型的直接序列.它能保证在每次连接中在一个时间点只有一个响应被发送出去.更糟糕的是,它使得队头阻塞和重要TCP连接的低效使用.
在HTTP2中,新的二进制帧层,解除了这个限制.使得所有的请求和响应多路复用.通过允许客户端和服务端把HTTP消息分解成独立的帧,交错传输,然后在另一端组装.
-
-
- 头部压缩：每个HTTP传输都包含一组描述传输资源及其属性的标题。在HTTP / 1.x中，此元数据始终以纯文本形式发送，并且每次传输的开销都会在任何位置增加500-800字节，如果使用HTTP Cookie，则会增加数千字节。为了减少这种开销并提高性能，HTTP 2使用HPACK压缩格式来压缩请求和响应头元数据：
-
通过静态霍夫曼编码对传输的头部字段进行编码，从而减少它们各自的传输大小。
客户端和服务器都维护和更新先前看到的标题字段的索引列表
霍夫曼编码允许单个值在传输时被压缩，并且先前传输值的索引列表允许我们通过传输索引值来编码重复值，索引值可用于有效地查找和重建完整头部键和值。
-
- QUIC：Quick UDP Internet Connection 是谷歌制定的一种基于UDP的低时延的互联网传输层协议。
- 无TCP队头阻塞：由于使用UDP而非TCP，所以就不存在TCP队头阻塞的问题
- QUIC：Quick UDP Internet Connection 是谷歌制定的一种基于UDP的低时延的互联网传输层协议。
不使用TCP，减少了交互过程的（1）和（3）
-
-
- 0 RTT：QUIC只需要1RTT的延迟就可以建立可靠安全的连接,相对于TCP+TLS的3个RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息，在再次与服务器建立连接时可以实现0-RTT的连接建立延迟。
-
即首次（4）和（8）可以合并为一个。在后续的交互过程中，（4）和（8）两个RTT都可以节省。
3.2 计算耗时 —— 分离计算
HTTPS 相对于HTTP 多出来的4个主要计算过程如下：
- 证书签名校验：这项是计算耗时是微秒级，相对于数据加解密是低频环节，优化空间相对不大
- 完整性校验：这项也是计算耗时是微秒级，优化空间相对不大
- 对称加解密：这项也是计算耗时是微秒级，但是高频环节
- 硬件加速：CPU提供了AES-NI指令，相对软件计算更快
- 非对称密钥交换（未优化情况下：占整体耗时75%）
- 算法分离：将最消耗CPU计算的过程分离出来，释放本地CPU，提升整体吞吐性能
- 异步处理：算法分离和计算的过程是异步的，不需要同步等待SSL加速计算的结果返回
- 并行计算：使用空闲CPU并行计算，提升计算效率
- 硬件加速：使用专用的SSL硬件加速卡，从而提高速度
六、HTTPS 的发展趋势
更广
- HTTP2 强制HTTPS：HTTP2目前在实际使用中，只用于HTTPS协议场景下，通过握手阶段ClientHello与ServerHello的extension字段协商而来，所以目前HTTP2的使用场景，都是默认安全加密的
- IOS ATS，Chrome，FireFox：各大互联网公司也在积极推广HTTPS
更强
- RSA1024->2048->4096：随着计算成本的降低，攻击成本也会降低，所以密钥也需要加长
- RSA->ECC：椭圆曲线实际上是一个集合，并且定义了一套计算规则。使用较小的数字就能实现RSA同样的安全强度。同样安全级别，ECC密钥比RSA短（160==1024、224==2048、521==15360）。随着安全性的提高，ECC密钥长度是线性增长，而RSA是指数增长。
更快
- TLS1.3，QUIC：前面在性能优化部分介绍了这两个协议，HTTPS 性能问题的影响将会越来越小
更开放
- Let's Encrypt 开源项目：也是一个 CA 机构，但这个 CA 机构是免费的，也就是说签发证书不需要任何费用。旨在以自动化流程消除手动创建和安装证书的复杂流程，并推广使万维网服务器的加密连接无所不在，为安全网站提供免费的SSL/TLS证书。它通过ACME 协议规范化了证书申请、更新、撤销等流程，完全自动化操作的（例如根据“DNS TXT 记录”判断）
参考资料
- 《HTTPS原理及最佳实践》 （鹅厂内部学习平台培训视频 by lancelotluo）
- 《HTTPS加密协议详解》http://www.wosign.com/faq/faq2016-0309-01.htm
- 《HTTPS 与 HTTP2 协议分析》https://blog.csdn.net/zhangzq86/article/details/64907340
- 《HTTP 2 新特性总结》https://www.jianshu.com/p/67c541a421f9
- 《让互联网更快的“快”---QUIC协议原理分析》https://zhuanlan.zhihu.com/p/32630510
- 《让互联网更快的“快”---QUIC协议在腾讯的实践和优化》https://zhuanlan.zhihu.com/p/32630738
- 《常见的几种SSL/TLS漏洞及攻击方式》https://www.infinisign.com/faq/any-ssl-tls-attach-hack
- 《阿里云CDN HTTPS最佳实践汇总》https://yq.aliyun.com/articles/288066
- 《TLS：更快，更安全的TLS1.3》https://www.simcf.cc/3273.html/
- 《HTTP与HTTPS对访问速度（性能）的影响》https://www.cnblogs.com/mylanguage/p/5635524.html
204
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
