阿里云云盾Web应用防火墙（Web Application Firewall, 简称 WAF）是一款网络安全产品，基于云安全大数据能力，用于防御SQL注入、XSS跨站脚本、常见Web服务器插件漏洞、木马上传、非授权核心资源访问等OWASP常见攻击，并过滤海量恶意CC攻击；在本篇文章中，笔者通过两个http2.0业务的接入案例分享，给您后续的业务接入提供参考借鉴的地方。
二、接入案例
2.1 案例1-APP登陆报错
2.1.1 案例背景
该业务属于一款专注于学习技术与教育大数据的APP，经常会遇到小流量CC攻击和网络爬虫的数据爬取，导致业务上受到了较为严重的影响，因此接入WAF进行防护。
2.1.2 问题现象
业务APP通过域名进行业务访问，将域名DSN修改为WAF的cname后，正常用户登录时会出现“服务器错误”的提示，将业务域名切换为源站服务器后问题消失，图1所示：
image
图一
2.1.3 排查过程
通过WAF自身提供的日志服务查询发现APP发起的第一个版本比对请求产生了400错误码，一般400错误码主要产生的原因有两个：http请求头过大或者请求数据不全；通过构造相关环境，针对APP客户端的请求数据进行抓包，从抓包中发现客户端完成证书和秘钥协商后主动关闭了连接，由于客户端主动关闭连接导致产生400错误码；
同时在正常访问时抓包分析发现客户端与服务器之间协商的交互协议为http2.0，于是将WAF的http2.0协议支持开启后观察，APP也能够正常通过WAF访问，将相关情况反馈给客户端开发后确认，由于APP底层使用了某开源框架， 该框架默认情况下启用http2.0进行网络数据交互，在下一版本会进行升级规避该问题。
2.1.4 案例总结
在业务接入WAF的过程中，我们需要充分了解业务使用的协议情况，配置好WAF后可以先进行本地验证测试，测试通过后再进行业务切换；在业务出现异常时，可通过WAF自身提供的日志服务进行日志排查，快速定位问题原因和现象。
2.2 案例2-部分浏览器访问网站异常
2.2.1 案例背景
该业务网站是一款用于渠道管理的后台系统，由于近期需要进行等保测评，从网站安全和合规角度出发，将网站接入WAF进行防护。
2.2.2 问题现象
网站接入WAF访问后，发现部分用户使用chrome和firefox浏览器访问时无法打开网站，但是IE的用户访问没有异常。
2.2.3 排查过程
首先通过本地chrome浏览器进行调试访问，发现浏览器https的请求出现[ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY]的错误提示， 如图2所示：
image
图二
同时，针对错误提示环境下的客户端抓包分析，在server hello的回应报文中加密套件协商为TLS_RSA_WITH_3DES_EDE_CBC_SHA（0x000a），同时采用了http2的交互协议，如图3所示：
image
由于http2在协议启用的情况下只能使用TLS1.2+，而TLS1.3还处于起草阶段，在本案例中协商为TLS1.2，而TLS_RSA_WITH_3DES_EDE_CBC_SHA恰好落在TLS1.2的黑名单列表中，所以导致了浏览器访问交互失败，如图4所示：
image
图四
那同样是浏览器访问，为什么会有部分浏览器能够正常打开网站呢？笔者又通过不同浏览器的抓包，发现每个浏览器发起client hello请求时的可协商加密套件列表是不一样的，加密套件的协商过程是客户端与服务端可支持加密套件列表的取交集过程，客户端与服务端取交集后按照服务器端配置的加密套件列表返回第一个(tengine开启了ssl_prefer_server_ciphers选项)，而在本次问题复现场景中，服务端返回的加密套件为[TLS_RSA_WITH_3DES_EDE_CBC_SHA]导致协商失败。
2.2.4 案例总结
在本案例中从业务角度出发服务端主动开启了http2.0的支持，但是由于服务端的相关配置问题，导致了本次问题的发生；所以在出现业务接入产品后出现异常，需要进行快速回滚恢复业务，同时在问题复现的基础上进行细节排查，找出问题本质原因进行解决。
三、结束语
HTTP 2.0作为HTTP协议的的第二个主要版本，较之1.1相比能够最小化网络延迟，提升网络速度，优化用户的网络使用体验，将会越来越多的使用于主流业务交互；云WAF作为安全防护类的产品，在当前主要采用反向代理的模式下，由于流量都需要经过WAF产品进行转发，或多或少都会遇到业务兼容性问题，所以业务方在接入过程中先了解业务架构和应用协议情况，尽量先进行本地灰度测试，验证通过后再做大规模迁移，保证业务接入顺利；
本文出自快速备案，转载时请注明出处及相应链接。
