64 The HTTP header line [ssl-client-cert:12330x11] does not conform to RFC 7230 and has been ignored
前言
呵呵 最近有一些问题, 某一批用户 突然登录不了了, 然后 抛出的异常信息是 参数异常
他们那边 使用的是 证书登录, 对于这个问题 我也没啥经验, 并且 最后问题 应该怎么处理, 目前也是处于 理论阶段
因为 没在实际的场景中使用解决方式来处理, 来看效果, 并且 自己本身的复现也很麻烦, 没得条件
证书登录报错
对于 "参数异常 " 的这个提示的输出, 发现请求是响应码是 400, 这个 "参数异常 " 不用多想应该是前端这边 异常情况拦截统一输出的
这部分用户 登录报错, 然后 我查看了一下日志
日志错误信息大致如下, 呵呵, 中间省略了一部分证书的具体信息, 呵呵 当时自然是 毫无头绪
奇怪的是 在出事前几天都能够登录?, 但是 出事那天 登录不了了??
然后来看一下 出事情的这块的代码
是在解析请求头 的值的时候出现了问题, 从代码上来看 是请求头的值中 出现了一个不是 制表符[\t], 并且是 控制支付[ascii : 0-31 或者 127] 的字符
但是实际 你看上面打印出来的 请求头, 你会发现 没有啥特殊的字符阿?, 没有空格(这些不可见的字符的输出一般为空格), 呵呵 这个 就让人很奇怪了
输出日志的代码是在 skipLine 里面
0-31的特殊字符的输出
写一段简单的脚本来做这个事情
public static void main(String[] args) {for (int i = 0; i < 32; i++) {System.out.println("the " + i + " output representation : " + ((char) i));}}
输出结果大致如下[下面的 0 真实展示的是一个 矩形框, 其他的为空白]
the 0 output representation :
the 1 output representation :
the 2 output representation :
the 3 output representation :
the 4 output representation :
the 5 output representation :
the 6 output representation :
the 7 output representation :
the 8 output representation :
the 9 output representation :
the 10 output representation : the 11 output representation :
the 12 output representation :
the 13 output representation :
the 14 output representation :
the 15 output representation :
the 16 output representation :
the 17 output representation :
the 18 output representation :
the 19 output representation :
the 20 output representation :
the 21 output representation :
the 22 output representation :
the 23 output representation :
the 24 output representation :
the 25 output representation :
the 26 output representation :
the 27 output representation :
the 28 output representation :
the 29 output representation :
the 30 output representation :
the 31 output representation : 尝试复现
看了上面 tomcat 部分的代码, 我这边首先是 准备复现一下吧, 也就是在 请求头的值 里面放入一个 0-31 的字符进去
public static void main(String[] args) throws Exception {HtmlCrawler crawler = HtmlCrawler.getInstance();HtmlCrawlerConfig config = HtmlCrawlerConfig.post();String sslClientCert = "123" + ((char) 17) + "321";config.addHeader("token", "2440cdef-5120-4076-9776-20a5066abf45");config.addHeader("ssl-client-cert", sslClientCert);
// config.addHeader("ssl/cert", sslClientCert);String url = "http://localhost:8080/api/hello/list/";Page page = crawler.getPage(url, config);System.out.println(" processing : " + specChar + " -- " + page.getContent());}当然 很简单的就复现出来了, 脚本这边的输出为
-- <!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 – Bad Request</h1></body></html>然后 服务器这边的输出 大致是如下
可以看到的是, 这里我传入的特殊字符为 17, 下面日志里面输出的是 0x11, 原来日志里面将一部分字符 特殊处理了的?, 这个 还得 稍微看下代码
另外就是 这部分的日志只会输出一次, 类似的 usage 可以参考 通过容器名称访问不到服务 但是通过ip能够访问服务 里面的日志输出
Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: The HTTP header line [ssl-client-cert:12330x11321] does not conform to RFC 7230 and has been ignored.at org.apache.coyote.http11.Http11InputBuffer.skipLine(Http11InputBuffer.java:1037)at org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:959)at org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:589)at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:284)at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590)at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)at java.lang.Thread.run(Thread.java:748)请求头的这部分内容的输出格式化方法大致如下, 从注释中可以看出 一部分特殊的字符是被处理成为了 十六进制表示(0xNN)
然后我们再来看一下 业务上的错误信息
呵呵 原来这个 0x0a, 0x09 就是被校验住的这部分的特殊字符呀
然后我们看一下 0x0a, 0x09 是什么?, 0x0a 表示的是换行符[LF], 0x09 表示的是 制表符[\t]
我们来看一下 通常的证书大致是什么样子? 下面是 我本地自己 随便生成的一个证书文件
-----BEGIN CERTIFICATE-----
MIIDKzCCAhMCFE9me7RwlXMKw0Dp5kubLuQIswXFMA0GCSqGSIb3DQEBCwUAMFIx
CzAJBgNVBAYTAkNOMQswCQYDVQQIDAJTQzELMAkGA1UEBwwCQ0QxDzANBgNVBAoM
BllPQ09ZVDELMAkGA1UECwwCS0YxCzAJBgNVBAMMAmNhMB4XDTE5MDgwOTAyMTky
MFoXDTE5MDkwODAyMTkyMFowUjELMAkGA1UEBhMCQ04xCzAJBgNVBAgMAlNDMQsw
CQYDVQQHDAJDRDEPMA0GA1UECgwGWU9DT1lUMQswCQYDVQQLDAJLRjELMAkGA1UE
AwwCY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClxUqXdCAj8+13
jDw5j+uOaa+aZKYJMPdsigoFBvOTlS8n26Fcp4Bihhj5glITdCGINTFge1ldNupR
F2AcPdkC+kFpNycz3dsIkFZXrLkxllb0M0aV6qVwhL4LR3dULdCSz2ez/jIEsv8a
ADRDV4DHNehH/yTd98VrviyZqWJtULEdk7mKRlyQgi3t3IOjry1B+f8U0yODrvdC
vDcZc7l0YYhCI7VScP2W+usAwMJ9/tPbrd6NpwvVHrw40nzxVtuias4593YPuRF9
qhQMx10cL7VG9v1PwBX11Zfc/JR0f+HVa4rADTwY6pWhqg4xdYQPl1j2kCmonopf
ITFWxAe/AgMBAAEwDQYJKoZIhvcNAQELBQADggEBAJu6klrALCsOUVkyEo8oSDnu
8Oi6WzMDARmGHh21bBLanahDER3yF78NxI3mkjqf3h0HZyGKUJgbAaJo/vsk9rGB
BpM/Vev4JSk6LyRKAlSYqR0KKKqHzOirS+AghqwhJ3UqIMmKpAvGmg3+RmbPHYjq
TqgGv6jCvE6itRWrxugvftb3uwUAmIwn4nCT0HJnA3xBs00kJAHR6yxE25JgXNy0
Gh8MIjOVbhFHs6hPlDJuuWal/CY0DxSxC6sqru3UpRVHIpDOMsuJZxBkldvUlUQc
YlOpQ5Sy4s6XG5IBPa99wcUN+uD4CVNrl5718seQwfpER2zlOl5ng166NM8m+TU=
-----END CERTIFICATE-----所以这上面传递的请求头的意思就是 整个证书 的数据, 但是 那个制表符是怎么回事呢? [参见下面的 ssl-client-cert 的传递方式]
我们待会儿 再来切换成 类似于 真实场景的请求数据来试试, 看下服务器这边的日志情况
我把传递的请求头 换成类似于上面业务场景中的日志类似的字符串
char specChar = 10, specChar02 = 9;String sslClientCert = "-----BEGIN CERTIFICATE------" + specChar + specChar02;输出结果如下, 呵呵 是不是 看起来 和上面的很相似阿
java.lang.IllegalArgumentException: The HTTP header line [ssl-client-cert:-----BEGIN CERTIFICATE-------0x0a0x09] does not conform to RFC 7230 and has been ignored.at org.apache.coyote.http11.Http11InputBuffer.skipLine(Http11InputBuffer.java:1037)at org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:959)at org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:589)at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:284)at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590)at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)at java.lang.Thread.run(Thread.java:748)
为了效果再逼真一点, 我们吧上面的测试证书放进来
String sslClientCert = "-----BEGIN CERTIFICATE-----\n" +"MIIDKzCCAhMCFE9me7RwlXMKw0Dp5kubLuQIswXFMA0GCSqGSIb3DQEBCwUAMFIx\n" +"CzAJBgNVBAYTAkNOMQswCQYDVQQIDAJTQzELMAkGA1UEBwwCQ0QxDzANBgNVBAoM\n" +"BllPQ09ZVDELMAkGA1UECwwCS0YxCzAJBgNVBAMMAmNhMB4XDTE5MDgwOTAyMTky\n" +"MFoXDTE5MDkwODAyMTkyMFowUjELMAkGA1UEBhMCQ04xCzAJBgNVBAgMAlNDMQsw\n" +"CQYDVQQHDAJDRDEPMA0GA1UECgwGWU9DT1lUMQswCQYDVQQLDAJLRjELMAkGA1UE\n" +"AwwCY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClxUqXdCAj8+13\n" +"jDw5j+uOaa+aZKYJMPdsigoFBvOTlS8n26Fcp4Bihhj5glITdCGINTFge1ldNupR\n" +"F2AcPdkC+kFpNycz3dsIkFZXrLkxllb0M0aV6qVwhL4LR3dULdCSz2ez/jIEsv8a\n" +"ADRDV4DHNehH/yTd98VrviyZqWJtULEdk7mKRlyQgi3t3IOjry1B+f8U0yODrvdC\n" +"vDcZc7l0YYhCI7VScP2W+usAwMJ9/tPbrd6NpwvVHrw40nzxVtuias4593YPuRF9\n" +"qhQMx10cL7VG9v1PwBX11Zfc/JR0f+HVa4rADTwY6pWhqg4xdYQPl1j2kCmonopf\n" +"ITFWxAe/AgMBAAEwDQYJKoZIhvcNAQELBQADggEBAJu6klrALCsOUVkyEo8oSDnu\n" +"8Oi6WzMDARmGHh21bBLanahDER3yF78NxI3mkjqf3h0HZyGKUJgbAaJo/vsk9rGB\n" +"BpM/Vev4JSk6LyRKAlSYqR0KKKqHzOirS+AghqwhJ3UqIMmKpAvGmg3+RmbPHYjq\n" +"TqgGv6jCvE6itRWrxugvftb3uwUAmIwn4nCT0HJnA3xBs00kJAHR6yxE25JgXNy0\n" +"Gh8MIjOVbhFHs6hPlDJuuWal/CY0DxSxC6sqru3UpRVHIpDOMsuJZxBkldvUlUQc\n" +"YlOpQ5Sy4s6XG5IBPa99wcUN+uD4CVNrl5718seQwfpER2zlOl5ng166NM8m+TU=\n" +"-----END CERTIFICATE-----";呵呵 这个就和真实场景的输出的日志, 几乎是一样的了, 不过有一点差别就是 上面的疑问, 制表符 是怎么来的?, 我们待会儿 再解释[参见下面的 ssl-client-cert 的传递方式]
2020-11-12 21:06:01.878 INFO 2590 [http-nio-8080-exec-2] o.a.coyote.http11.Http11InputBuffer : The HTTP header line [ssl-client-cert:-----BEGIN CERTIFICATE------0x0aMIIDKzCCAhMCFE9me7RwlXMKw0Dp5kubLuQIswXFMA0GCSqGSIb3DQEBCwUAMFIx0x0aCzAJBgNVBAYTAkNOMQswCQYDVQQIDAJTQzELMAkGA1UEBwwCQ0QxDzANBgNVBAoM0x0aBllPQ09ZVDELMAkGA1UECwwCS0YxCzAJBgNVBAMMAmNhMB4XDTE5MDgwOTAyMTky0x0aMFoXDTE5MDkwODAyMTkyMFowUjELMAkGA1UEBhMCQ04xCzAJBgNVBAgMAlNDMQsw0x0aCQYDVQQHDAJDRDEPMA0GA1UECgwGWU9DT1lUMQswCQYDVQQLDAJLRjELMAkGA1UE0x0aAwwCY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClxUqXdCAj8+130x0ajDw5j+uOaa+aZKYJMPdsigoFBvOTlS8n26Fcp4Bihhj5glITdCGINTFge1ldNupR0x0aF2AcPdkC+kFpNycz3dsIkFZXrLkxllb0M0aV6qVwhL4LR3dULdCSz2ez/jIEsv8a0x0aADRDV4DHNehH/yTd98VrviyZqWJtULEdk7mKRlyQgi3t3IOjry1B+f8U0yODrvdC0x0avDcZc7l0YYhCI7VScP2W+usAwMJ9/tPbrd6NpwvVHrw40nzxVtuias4593YPuRF90x0aqhQMx10cL7VG9v1PwBX11Zfc/JR0f+HVa4rADTwY6pWhqg4xdYQPl1j2kCmonopf0x0aITFWxAe/AgMBAAEwDQYJKoZIhvcNAQELBQADggEBAJu6klrALCsOUVkyEo8oSDnu0x0a8Oi6WzMDARmGHh21bBLanahDER3yF78NxI3mkjqf3h0HZyGKUJgbAaJo/vsk9rGB0x0aBpM/Vev4JSk6LyRKAlSYqR0KKKqHzOirS+AghqwhJ3UqIMmKpAvGmg3+RmbPHYjq0x0aTqgGv6jCvE6itRWrxugvftb3uwUAmIwn4nCT0HJnA3xBs00kJAHR6yxE25JgXNy00x0aGh8MIjOVbhFHs6hPlDJuuWal/CY0DxSxC6sqru3UpRVHIpDOMsuJZxBkldvUlUQc0x0aYlOpQ5Sy4s6XG5IBPa99wcUN+uD4CVNrl5718seQwfpER2zlOl5ng166NM8m+TU=0x0a-----END CERTIFICATE-----] does not conform to RFC 7230 and has been ignored.这里的问题怎么处理呢?, 抽象的来看 应该是 http 协议约束的 请求头的值 不允许传递 LF 吧
这个还得来看一下 这个 ssl-client-cert 是怎么传递的
ssl-client-cert 的传递方式
在我们的场景下面使用的是 nginx 吧 ssl-client-cert 注入进来的
方式大致是如下, 使用的是占位符 $ssl_client_cert, nginx 运行时再来替换占位符为实际的数据
proxy_set_header SSL-Client-Cert $ssl_client_cert;接着我们来看一下 $ssl_client_cert 的说明文档
需要注意两件事情, 一是 这里的额 ssl_client_cert 的数据传递处理了什么, 二是 这个变量已经过时了, 替代方案是什么, 以及替代方案又有什么不同?
1. 注意这里的 "with each line except the first prepended with the tab character", 呵呵 这里就解释了 为什么 为什么我们生产环境下面的日志 每一行开头有一个 0x0a[制表符]
2. $ssl_client_cert 已经过时了, 使用 $ssl_client_escaped_cert 来替代, $ssl_client_escaped_cert 返回的结果是 客户端证书的 PEM 格式(并且经过了 url 编码)
ssl-client-cert 编码之后发送
然后我们用上面的证书, 然后将其内容 url 编码之后 发送给服务器, 我们看一下 具体的拿到的是什么?
客户端这边发送的数据如下
服务端可以拿到的数据如下
所以 对于这个问题理想的处理方式应该是 使用 $ssl_client_escaped_cert 来替换掉 $ssl_client_cert, 然后看下服务器这边 有没有自动对请求头做 解码, 如果没有 自己手动解码处理一下就行
当然对于 我们这里的测试的情况来说是, 服务器这边自动对 查询字符串是做了 url 解码, 但是 对于请求头 是没有的
Problem with multiline $ssl_client_cert HTTP header in proxy mode
链接如下 : Bug 483795 - Jetty cannot parse multiline query headers, Problem with multiline $ssl_client_cert HTTP header in proxy mode
呵呵 我们再来看一下 对于这个问题, 一些 前辈们的处理
最开始的问题是, Michał Niklas 想过要发送一个 http 请求, 其中的 User-Agent 的头的值是有 两行, 在 apache 2.4 的服务器上面 ok, 但是在 jetty 9.3.6 的场景下面 服务器返回的 400
下面的解释是 在 rfc 7230 中, 之前的 请求头的值的多行折叠为一行 的处理方式已经过时了, jetty 已经实现了 rfc7230, 因此 对于以上的请求 返回的是 400
然后这位大哥的场景似乎是也是 要传递 客户端的 ssl 证书, 然后 因为证书存在多行, 服务器抛出了 400, 然后 这位大哥 跑到 nginx 官方提了一个 问题
nginx 这边的帖子如下
Problem with multiline $ssl_client_cert HTTP header in proxy mode
Maxim Dounin 表示这不算是一个 bug, 文档上面描述的 和 实际处理的方式一致, 至于 后端服务 是否处理, 那是另外一个问题
请求头的多行折叠已经过时, 需要思考一个更好的方式 来传递 客户端证书到服务端
这位大哥的解决方式是, 吧 PEM 文件搞成一行, 具体请参见 跳转的帖子
这位大哥介绍了一下 $ssl_client_escaped_cert 的大致的工作方式
可以使用 $ssl_cient_escaped_cert 变量, 其为 url 编码之后的 ssl 客户端证书, 使用 ngx_escape_uri 进行编码, 可以是用于 请求头, 请求参数 等等
$ssl_client_cert 可以考虑更新为已过时, 期望 $ssl_client_cert 最后完全消除之后, $ssl_cleint_raw_cert 变量最终更新为 $ssl_client_cert
$ssl_client_escaped_cert 变量将会在下一个 nginx 发布可用, nginx 1.13.5
RFC7230 section 3.2.4 FiledParsing
可以看一下 下面的关于 obs-fold 的描述, 描述的正是我们这里碰到的问题, 以及上面这位前辈碰到的问题
最后
当然 最后, 还有一个问题就是 为什么 在出现问题之前 能够登录?? 呵呵 由于缺少一些 直接的证据, 也缺乏复现的条件, 这里 就只有 如果之后有关于这个问题的更多的信息, 再来补充在这里了
呵呵 这个问题的处理?, 还是 缺少条件, 毕竟生产环境 不是你家的
完
参考
Bug 483795 - Jetty cannot parse multiline query headers
Problem with multiline $ssl_client_cert HTTP header in proxy mode
3.2.4. Field Parsing$ssl_client_cert & $ssl_client_escaped_cert64 The HTTP header line [ssl-client-cert:12330x11] does not conform to RFC 7230 and has been ignored相关推荐
- The HTTP header line [connection : Keep-alive] does not conform to RFC 7230 and has been ignored
在测试一个程序的时候,出现了"The HTTP header line [connection : Keep-alive] does not conform to RFC 7230 and ...
- C# webkit 内核浏览器 访问https网站 显示空白或者提示 Problem with the SSL CA cert (path? access rights?)
如题 解决方法: 安装中文路径,经常 出现问题.改下安装路径. 只需要动态链接库所在路径上没有中文字符,webkit内核浏览器就可以访问https网址. 转自:C# webkit 内核浏览器 访问ht ...
- privoxy Invalid header received from client.
今天使用privoxy代理出现如下错误: Invalid header received from client. 解决方法: 在proxy.exe配置文件config.txt中加入如下配置项即可: ...
- http缓存探究Config HTTP Header For Better Client Perfo
文章地址:http://morganchengmo.spaces.live.com/blog/cns!9950CE918939932E!2132.entry Config HTTP Header Fo ...
- Debain8 Tomcat8 JDK8 实现SSL双向验证
先说说环境: 系统:Debain8.Tomcat8.JDK8 实现目标:使用JDK自带的keytool实现SSL双向加密 1.为服务器生成证书 keytool -genkey -v -alias to ...
- locust压测工具：http测试过程与定时停止
locust压测环境描述 本文环境python3.5.2 locust版本0.9.0 locust示例的执行过程 上文大概描述了locust的启动了流程,本文主要是接着上文继续分析,示例代码中的htt ...
- Python requests模块相关接口
2019独角兽企业重金招聘Python工程师标准>>> 主要接口 Requests 所有的功能都可以通过以下 7 个方法访问.它们全部都会返回一个 Response 对象的实例. r ...
- Python requests模块详解
1.模块说明 requests是使用Apache2 licensed 许可证的HTTP库.用python编写.比urllib2模块更简洁. Request支持HTTP连接保持和连接池,支持使用cook ...
- Python中第三方模块requests解析
一.简述 Requests HTTP Library 二.模块框架 '''__version___internal_utilsadaptersapiauthcertscompatcookiesexce ...
- trafficserver records.config参数说明
说明:来源赵永明的ATS-BLOG. 该版本是基于3.2.4的records.config参数整理而来,结合了官网的参数解说进行汉化得来.有很多参数在翻译的过程中可能并不是很准确,或是我的理解有偏差, ...
最新文章
- Laravel 中简约而不简单的 Macroable 宏指令
- KubeMeet 直播 | 现场直击大规模集群、混合环境下的云原生应用交付难题
- SpringBoot:application.properties基本的参数配置
- python启动远端 exe_python打包exe开机自动启动的实例(windows)
- java sleep和wait的区别和联系
- asp毕业设计—— 基于asp+access的图书管理系统设计与实现（毕业论文+程序源码）——图书管理系统
- 南通市城管局推动“数字化城管”向“智慧城管”升级
- 计算机网络ppt背景,教大家使用ppt设计出高逼格的背景图
- 采购很容易，油水又多？那你来啊
- 宝藏级别的负数取模，让你关于负数取模不在陌生 ＞o＜ 进来看看吧
- bns服务器不可用怎么修复,DNS服务器可能不可用怎么办
- 千万不要死于无知——心理状态
- 求两点之间的最短路径
- 史上最全图文精美排版技巧
- 工作中遇到的问题及解决方案
- 爬取电影天堂最新电影（xpath结合lxml）
- html设置表单里面字体格式为中文,html设置字体样式 html怎么设置字体样式 html字体怎么设置...
- PHP获取用户访问IP地址的5种方法
- 【安卓学习之微信抢红包】 微信抢红包 1 - 知识点归纳
- 微服务整合公众号告警系统