如何解决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.

但是，我有时会使用进行SSL异常坏记录MAC 消息。以下是使用 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校验和。 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屋！