-
Bug
-
Resolution: Cannot Reproduce
-
P4
-
None
-
1.4.2
-
None
-
sparc
-
solaris_8
We have encountered a problem with using java 1.4.2 to make an SSL
connection to a program running on an IBM OS/390 2.10 operating system.
The same programs work successfully on an IBM z/OS system. The java
program is used widely to connect to a variety of other platforms, and
this error has not been observed. Likewise, the IBM server program has
been used to make SSL connection against a number of non-java clients
without incident.
The error appears to be thrown on the java side of the connection:
javax.naming.CommunicationException: bad record MAC. Root exception is
javax.net.ssl.SSLException: bad record MAC
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:220)
at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
at com.sun.jndi.ldap.Connection.run(Connection.java:837)
at java.lang.Thread.run(Thread.java:536)
However the 'bad record MAC' indicates an SSL incompatibility somewhere
between the two systems, and it is not immediately clear where the
problem lies. The bad MAC occurs many packets into the data exchange and
not at the beginning of the exchange.
A search of the Sun bug database shows a similar error (bug 4513263
(Fixed) "TLS handshake fails when default character encoding is not
ASCII compatible") also on an OS/390 system, however this is in an old
version of java (1.2.2) and has been long fixed.
This issue is also being raised with IBM, but since it might equally be
a problem on the java side, we need to make sure that Sun has reviewed
the error traces and that this is not a known problem. We are able to
run further diagnostics if required, but we cannot allow a direct
connection to the client's system which is a secure environment.
Logs for working and failing cases forwarded from CA on 7/30/03
###@###.### 2003-08-04
connection to a program running on an IBM OS/390 2.10 operating system.
The same programs work successfully on an IBM z/OS system. The java
program is used widely to connect to a variety of other platforms, and
this error has not been observed. Likewise, the IBM server program has
been used to make SSL connection against a number of non-java clients
without incident.
The error appears to be thrown on the java side of the connection:
javax.naming.CommunicationException: bad record MAC. Root exception is
javax.net.ssl.SSLException: bad record MAC
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:220)
at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
at com.sun.jndi.ldap.Connection.run(Connection.java:837)
at java.lang.Thread.run(Thread.java:536)
However the 'bad record MAC' indicates an SSL incompatibility somewhere
between the two systems, and it is not immediately clear where the
problem lies. The bad MAC occurs many packets into the data exchange and
not at the beginning of the exchange.
A search of the Sun bug database shows a similar error (bug 4513263
(Fixed) "TLS handshake fails when default character encoding is not
ASCII compatible") also on an OS/390 system, however this is in an old
version of java (1.2.2) and has been long fixed.
This issue is also being raised with IBM, but since it might equally be
a problem on the java side, we need to make sure that Sun has reviewed
the error traces and that this is not a known problem. We are able to
run further diagnostics if required, but we cannot allow a direct
connection to the client's system which is a secure environment.
Logs for working and failing cases forwarded from CA on 7/30/03
###@###.### 2003-08-04
- relates to
-
JDK-4513263 TLS handshake fails when default character encoding is not ASCII compatible
-
- Resolved
-