SSL“不良记录MAC"如何排查例外 [英] How to troubleshoot SSL "bad record MAC" exception

问题描述

我正在使用 Apache CXF 客户端，在 Windows Java 1.6.0_29-b11 VM 中运行以连接到 IBM 大型机(我相信它是 zSeries)，并调用在那里运行的 SOAP Web 服务.连接是通过 SSL/TLS 完成的，大部分时间都可以正常工作.

I am using an Apache CXF client, running in a Windows Java 1.6.0_29-b11 VM to connect to an IBM mainframe (I believe it is zSeries), and invoking a SOAP Web Service running there. The connection is done through SSL/TLS, and most of the time works fine.

但是，有时我会遇到带有 bad record MAC 消息的 SSL 异常.这是使用 javax.net.debug 属性的程序的输出.

However, from time to time I have SSL Exceptions with a bad record MAC message. Here is the output of the program using with the javax.net.debug property.

2011-11-16 12:32:37,731 INFO  LoggingOutInterceptor: Outbound Message
---------------------------
ID: 29
Address: https://1.2.3.4/access/servlet/blabla.atk123
Encoding: UTF-8
Content-Type: text/xml
Headers: {Accept=[*/*], SOAPAction=["Blablaaction/ATK123.Execute"]}
Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ATK123.Execute xmlns="Blabla"><Usrid>WA</Usrid><Usrpwd>54321</Usrpwd><Ultautid>9999</Ultautid></ATK123.Execute></soap:Body></soap:Envelope>
--------------------------------------
pool-1-thread-1, setSoTimeout(30000) called
pool-1-thread-1, WRITE: TLSv1 Application Data, length = 321
pool-1-thread-1, WRITE: TLSv1 Application Data, length = 262
pool-1-thread-1, READ: TLSv1 Application Data, length = 483
pool-1-thread-1, READ: TLSv1 Application Data, length = 16148
pool-1-thread-1, READ: TLSv1 Application Data, length = 282
%% Invalidated:  [Session-1, SSL_RSA_WITH_RC4_128_SHA]
pool-1-thread-1, SEND TLSv1 ALERT:  fatal, description = bad_record_mac
pool-1-thread-1, WRITE: TLSv1 Alert, length = 22
pool-1-thread-1, called closeSocket()
pool-1-thread-1, handling exception: javax.net.ssl.SSLException: bad record MAC
2011-11-16 12:32:38,511 WARN  PhaseInterceptorChain: Interceptor for {Blabla}ATK123#{Blabla}Execute has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: bad record MAC
    at org.apache.cxf.interceptor.LoggingInInterceptor.logging(LoggingInInterceptor.java:144)
    at org.apache.cxf.interceptor.LoggingInInterceptor.handleMessage(LoggingInInterceptor.java:73)
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
    at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:797)
.... (more stuff)

不幸的是，我无法在服务器上修改或调试端点.

Unfortunately, I don't have possibilities to modify or debug the endpoint at the server.

这可能是什么原因造成的?

What could be causing this?

如何隔离并修复此行为?

How can I isolate and fix this behavior?

推荐答案

如果您由于网络中的某些故障而收到大量坏包，则可能会发生坏包随机通过 32 位 TCP 校验和而幸存下来的情况.大约 40 亿个坏包中就有 1 个会被 TCP 漏掉.一旦这个数据包被传送到 SSL，它肯定会生成一个坏记录 MAC，因为 SSL Mac 的大小是 96 位.

If you are getting a lot of bad packets due to some fault in your network it can happen that a bad packet will at random survive the 32-bit TCP checksum. About 1 in 4 billion bad packets will slip by TCP. Once this packet is delivered to SSL it will generate a bad record MAC for sure, because the SSL Mac is 96 bits in size.

如果是这个原因，唯一的解决办法就是改善网络.

If this is the cause, the only solution is improve the network.

请注意，一般来说，这是导致 MAC 记录不良的不太可能原因.即使是硬件有缺陷的网络也不太可能生成带有正确 IP 和 TCP 元数据的错误数据包，这样数据包实际上会传递到与 TLS 连接对应的套接字.

Note that, in general, this is a very unlikely cause of a bad record MAC. Even a network with faulty hardware that generates bad packets is unlikely to generate them with correct IP and TCP metadata such that the packets are actually passed to the socket corresponding to the TLS connection.

这篇关于SSL“不良记录MAC"如何排查例外的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！