HTTP/2笔记之错误处理和安全

标签: http 笔记 错误 | 发表时间:2015-03-24 07:27 | 作者:nieyong
出处:http://www.blogjava.net/

零。前言

这里整理了一下错误和安全相关部分简单记录。

一。HTTP/2错误

1. 错误定义

HTTP/2定义了两种类型错误:

  • 导致整个连接不可使用的错误为连接错误(connection error)
  • 单独出现在单个连接上的错误为流错误(stream error)

2. 错误代码

错误代码,32位正整数表示错误原因,RST_STREAM和GOAWAY帧中包含。

未知或不支持的错误代码可以选择忽略,或作为INTERNAL_ERROR错误对待都可以。

3. 连接错误处理

一般来讲连接错误很严重,会导致处理进程无法进行下去,或影响到整个连接的状态。

  • 终端一旦遇上连接错误,需第一时间在最后一个可用流上发送包含错误原因GOAWAY帧过去,然后关闭连接
  • GOAWAY有可能不被对端成功接收到,若成功接收可获得连接被终止的原因
  • 终端可在任何时间终止连接,也可以把流错误作为连接错误对待。但都应该在关闭连接之前发送一个GOAWAY帧告知对方

4. 流错误

一般来讲具体流上的流错误不会影响到其它流的处理。

  • 终端检测到流错误,需要发送一个RST_STREAM帧,其包含了操作到错误流标识符
  • RST_STREAM应当是发送错误流最后一个帧,内含错误原因。
  • 发送方在发送之后,需要准备接收对端将要或即将发送过来的帧数据,处理方式就是忽略之,除非是可以修改连接状态帧
  • 一般来讲,终端不应该发送多个RST_STREAM帧,但若在一个往返时间之后已关闭的流上能够继续接收帧,则需要发送再次发送一个RST_STREAM帧,处理这种行为不端的实现。
  • 终端在接收到RST_STREAM帧之后,不能响应一个RST_STREAM帧,避免死循环

5. 连接终止

TCP连接被关闭或重置时仍有处于"open"或"half closed"的流将不能自动重试。

二。HTTP/2安全注意事项

1. 跨协议攻击

跨协议攻击,字面上理解就很简单,比如攻击者构建HTTP/1.1请求直接转发给仅仅支持HTTP/2的服务器,以期待获取攻击效果。

这里有一篇讲解跨协议攻击的文章: http://www.freebuf.com/articles/web/19622.html

TLS的加密机制使得攻击者很难获得明文,另外TLS的ALPN协议扩展可以很轻松处理请求是否需要作为HTTP/2请求进行处理,总之可有效阻止对基于TLS的其它协议攻击。

基于标准版TCP没有TLS和ALPN的帮忙,客户端所发送连接序言前缀为PRI字符串用来混淆HTTP/1.1服务器,但对其它协议没有提供保护,仅限于此。但在处理时,若接收到HTTP/1.1的请求,没有包含Upgrade升级字段,则需要认为是一个跨协议攻击。

总之,程序要尽可能的健壮,容错,针对非法的请求,直接关闭对方连接。

2. 中介端数据转换封装的攻击

中介所做的HTTP/1.1和HTTP/2之间转换,会存在攻击点:

  1. HTTP/2头字段名称编码允许使用HTTP/1.1没有使用到的头字段名称,中介在转换HTTP/2到HTTP/1.1时就容易出现包含非法请求头字段HTTP/1.1数据。
  2. HTTP/2允许头字段值可以是非法值,诸如回车(CR, ASCII 0xd), 换行 (LF, ASCII 0xa), 零字符 (NUL, ASCII 0x0),这在逐字解析实现时是一个风险。

解决方式,一旦发现非法头字段名称,以及非法头字段值,都作为不完整、残缺数据对待,或丢弃,或忽略。

3. 推送内容的缓存

推送内容有保证的服务器提供,是否缓存由头字段Cache-Control控制。

但若服务器上多租户形式(SAAS),每一个租户使用一小部分URL空间,比如 tenant1.domain.com,tenant2.domain.com,服务器需要确保没有授权的租户不能够推送超于预期的资源,覆盖已有内容。

原始服务器没有被授权使用推送,既不能够违规发送推送,也不能够被缓存。

4. 拒绝服务攻击注意事项

  • HTTP/2因为要为流、报头压缩、流量控制等特性占用资源较多,因此针对每一个连接的内存分配要设置限额,否则很少的连接占满内存,无法正常服务
  • 针对单个连接,规范对PUSH_PROMISE帧数量没有约束,但客户端需要设置一个上限值,这也是确定需要维护的"reserved (remote)"状态的数量,超出限额需要报ENHANCE_YOUR_CALM类型流错误
  • SETTINGS帧有可能会被滥用导致对端需要花费时间解析处理设置限制等,滥用情况包括包含未定义的参数,以及同一个参数多次出现等,类似于WINDOW_UPDATE和PRIORITY帧都会存在滥用的情况;这些帧被滥用导致资源耗费情况严重
  • 大量小帧或空帧一样会被滥用,但又符合逻辑,耗费服务器资源在处理报文头部上面。比如空负载DATA帧,以及用于携带报文头部数据的CONTINUATION帧,都属于安全隐患
  • 报头压缩存在潜在风险,也会被滥用,详情可参考HPACK协议第七章: http://http2.github.io/http2-spec/compression.html#Security
  • 终端中途发送的SETTINGS帧所定义参数不是立即可以生效的,这会导致对端在实际操作时可能会超过最新的限制。建议直接在连接建立时在连接序言内包含设置值,就算如此,客户端也会存在超出服务器端连接序言中所设置的最新限定值。

总之,诸如SETTINGS帧、小帧或空帧,报头压缩被合理滥用时,表明上看符合逻辑,会造成资源过度消耗。这需要服务器端监控跟踪到此种行为,并且设置使用数量的上限,一旦发现直接报ENHANCE_YOUR_CALM类型连接错误。

5. 报头块大小限制

报头块过大导致实现需要维护大量的状态开销。另外,根据报头字段进行路由的情况,若此报头字段出现在一系列报头块帧的最后一个帧里面,可能会导致无法正常路由到目的地。若被缓存会导致耗费大量的内存。这需要设置SETTINGS_MAX_HEADER_LIST_SIZE参数限制报头最大值,以尽可能的避免出现以上情况。

服务器一旦接收到超过报头限制请求,需要响应一个431(请求头过大) HTTP状态码,客户端呢可直接丢掉响应。

6. 压缩使用的安全隐患

  • 针对安全通道,不能使用同一个压缩字典压缩保密的关键数据和易受攻击者控制的数据
  • 来源数据不能确定为完全可靠,就不应该使用压缩机制
  • 通用流的压缩不能在基于TLS的HTTP/2上使用这一部分,可参考 http://http2.github.io/http2-spec/compression.html#Security

7. 填充使用的安全隐患

一般来讲,填充可用来混淆帧的真实负载长度,稍加保护,降低攻击的可能性。但若不当的填充策略:固定填充数、可轻松推导出填充规则等情况都会降低保护的力度,都有可能会被攻击者破解。

中介设备应该保留DATA帧的填充(需要避免如上所述一些情况),但可丢弃HEADERS和PUSH_PROMISE帧的填充。

三。TLS

HTTP/2加密建立在TLS基础,关于TLS,维基百科上有解释: http://zh.wikipedia.org/wiki/%E5%82%B3%E8%BC%B8%E5%B1%A4%E5%AE%89%E5%85%A8%E5%8D%94%E8%AD%B0

摘取一张图,可说明基于ALPN协议扩展定义的协商流程:

其它要求:

  • 只能基于TLS >= 1.2版本。目前TLS 1.3为草案版本,正式版本目前尚未可知。目前只有TLS 1.2可选。
  • 必须支持Server Name Indication (SNI) [TLS-EXT]扩展,客户端在连接协商阶段需要携带上域名
  • 基于TLS 1.3或更高版本构建,仅需要支持SNI扩展。TLS 1.2要求较多
  • 基于TLS 1.2构建
    • 必须禁用压缩机制。不恰当压缩机制会导致信息外露,HTTP/2报头有压缩机制
    • 必须禁用重新协商机制。终端对待TLS 1.2重新协商作为PROTOCOL_ERROR类型连接错误对待;密码套件加密次数限制导致连接一直挂起等待不可用
    • 终端可以通过重新协商提供对客户端凭证保护功能在握手期间,重新协商必须发生在发送连接序言之前进行。服务器当看到重新协商请求时应该请求客户端证书在连接建立后
    • 当客户端请求受保护的特定资源时,服务器可以响应HTTP_1_1_REQUIRED错误,可有效阻止重新协商机制

四。小结

这里简单记录HTTP/2错误和安全相关事项,本系列规范学习到此告一段落。



nieyong 2015-03-24 15:27 发表评论

相关 [http 笔记 错误] 推荐:

HTTP/2笔记之错误处理和安全

- - BlogJava-首页技术区
这里整理了一下错误和安全相关部分简单记录. HTTP/2定义了两种类型错误:. 导致整个连接不可使用的错误为连接错误(connection error). 单独出现在单个连接上的错误为流错误(stream error). 错误代码,32位正整数表示错误原因,RST_STREAM和GOAWAY帧中包含.

HTTP/2笔记之开篇

- - BlogJava-首页技术区
本系列基于HTTP/2第17个草案文档,地址就是: https://tools.ietf.org/html/draft-ietf-httpbis-http2-17. HTTP/2规范已经通过发布批准,下面等待分配具体的RFC号码,不会有所较大的变动了. 一张图可以很较为全面的概括了HTTP/1.*存在缺陷:.

Nginx+ffmpeg搭建Apple Http Live Streaming笔记

- - 移动开发 - ITeye博客
起始Nginx来搭建HLS步骤非常少. 安装好Nginx,然后跑起来. 把切片好的视频和m3u8文件放到部署目录,直接访问就可以了. 网上国内国外的找了好多博客. 这里一定注意一点,不要用VLC播放器来测试,最好用iPad或者iPhone,再么用Safari 开发模式下模拟iPad、iPhone的浏览器模式播放.

HTTP/2笔记之消息交换

- - BlogJava-首页技术区
无论是HTTP/1.*还是HTTP/2,HTTP的基本语义是不变的,比如方法语义(GET/PUST/PUT/DELETE),状态码(200/404/500等),Range Request,Cacheing,Authentication、URL路径. 以前纯文本形式作为传输的载体,HTTP/2带来了与之不同的二进制传输语法语义.

在小饭馆看到的 HTTP 502 错误实例

- TualatriX - python.cn(jobs, news)
周五拉着 wincss  去蓟门里的螺蛳粉先生吃饭,期间见到了一个场景,颇像当年 5D6D 网站遭遇的 502 错误. 我和 wincss 到饭馆的时候,屋里已经没有座位了. 但是既然来了也不能轻易放弃啊,于是要求店家在外面支了桌子. 其实瓶颈主要在于厨房(数据库),厨房做饭太慢,外面的客户只好先排着.

HTTP Headers 入门

- johnny - Time Machine
非常感谢 @ytzong 同学在twitter上推荐这篇文章,原文在此. 本文系统的对HTTP Headers进行了简明易懂的阐述,我仅稍作笔记. 什么是HTTP Headers. HTTP是“Hypertext Transfer Protocol”的所写,整个万维网都在使用这种协议,几乎你在浏览器里看到的大部分内容都是通过http协议来传输的,比如这篇文章.

HTTP基础

- - ITeye博客
HTTP的结构主要包括下面几个要点:. HTTP的版本主要有1.0,1.1 和更高版本.    1.1 及以上版本允许在一个TCP连接上传送多个HTTP协议,1.0能 .    1.1 及以上版本多个请求和响应可以重叠,1.0不能.    1.1 增加了很多的请求头和响应头.     一个请求行,若干小心头,以及实体内容,其中的一些消息头和实体内容是可选的,消息头和实体内容需要空行隔开.

HTTP Header 详解

- - 博客园_Ruby's Louvre
HTTP(HyperTextTransferProtocol)即超文本传输协议,目前网页传输的的通用协议. HTTP协议采用了请求/响应模型,浏览器或其他客户端发出请求,服务器给与响应. 就整个网络资源传输而言,包括message-header和message-body两部分. 首先传递message- header,即 http header消息.

HTTP负载测试

- - 博客 - 伯乐在线
英文原文: ON HTTP LOAD TESTING 来源: oschina. 有很多人在谈论HTTP服务器软件的性能测试,也许是因为现在有太多的服务器选择. 这很好,但是我看到有人很多基本相同的问题,使得测试结果的推论值得怀疑. 在日常工作中花费了很多时间在高性能代理缓存和源站性能测试方面之后,这里有我认为比较重要的一些方面来分享.

HTTP断点续传

- - CSDN博客互联网推荐文章
要实现断点续传的功能,通常都需要客户端记录下当前的下载进度,并在需要续传的时候通知服务端本次需要下载的内容片段. HTTP1.1协议(RFC2616)中定义了断点续传相关的HTTP头 Range和Content-Range字段,一个最简单的断点续传实现大概如下:.   1.客户端下载一个1024K的文件,已经下载了其中512K.