Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4615819

"bad_record_mac" when connecting to servers that only support SSL 3.0



    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 1.4.0
    • Fix Version/s: 1.0.3
    • Component/s: security-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:



        I think this may also have been the root cause for 4435711,
        but the problem inadvertantly went away with the
        setEnabledProtocols API addition.

        I think the underlying problem in 4435711 is still there.

        Customer sees problems when doing client authentication
        in JSSE 1.0.2. Problem seen on a SSL v3 server talking
        to JSSE.

        The analysis by Andreas follows:

        The short answer is: this a SSL/TLS versioning problem. It happens only
        if you have SSL 3.0 and TLS 1.0 enabled (the server only support SSL
        3.0). It does not happen if you have only SSL 3.0 enabled (via
        socket.setEnabledProtocols(new String[]{"SSLv3"}); ). This only works
        with 1.4. JSSE 1.0.2 did not have this API and I believe there is no
        other workaround for 1.0.2.

        The server hosting the content identifies itself as
        Netscape-Enterprise/4.1, although from the description of the
        configuration I am not sure this is the server running the SSL code. In
        any case, upgrading the SSL server to a later version may also fix the

        The long answer is: actually, this is a spec compliance bug in JSSE. We
        send a 3.0/3.1 hello, the server selects 3.0. Later, when we send the
        RSA client key exchange message, we set the version in the premaster
        secret to the current protocol version (3.0) although per spec it should
        be the highest supported by the client (3.1) (see RFC2246, section The server detects the mismatch and assumes this is an invalid
        premaster secret. However, due to the Bleichenbacher attack it does not
        complain immediately but instead generates a random premaster secret and
        continues the handshake. When the finished messages are exchanged, the
        handshake fails with a MAC error because different MAC keys are used.

        The reason why we send 3.0 instead of 3.1 is that some early TLS
        implementations (in particular SSLeay/OpenSSL) implemented this
        incorrect behavior. In order to interoperate with them, you have no
        choice but to implement it incorrectly as well. [That is what I assume
        'we' did. At least that's what I did at IAIK] This problem will most
        probably occur with all TLS implementations, unless they have TLS
        disabled (IE default config) or do an automatic retry with a different
        protocol version (Opera AFAIK). For example, I cannot connect with IE6
        and TLS enabled either.

        PS: it might be a good idea to add the setEnabledProcotols() to JSSE
        1.0.3. Should be low risk.

        Jeff is wondering if the code should be fixed to properly
        follow the spec. We're probably not seeing many instances
        of this, as the servers may either be updated to fix this problem,
        or they talk TLS in which case we'll never see this problem.

        Anyway, it's not following the spec, and we should
        at least consider fixing it in hopper/tiger.

        One thing we could do with JSSE on the server side is to
        calculate both values, and use the one that MAC's

        We should look at interop with other toolkits, and see
        what they do, and if we feel there's low enough impact,
        we might want to change the code to be spec-compliant.

        ###@###.### 2001-12-18

        Note, if you try to connect to an openssl toolkit that's
        been configured to use -no_tls1, things crash...

        openssl s_server -debug -state -accept 4338 -cert ../serverkeys -CAfile ../ca.crt -Verify 5 -debug -state -no_tls1

        SSL_accept:SSLv3 read client certificate A
        write to 00174A30 [00173310] (7 bytes => 7 (0x7))
        0000 - 15 03 00 00 02 02 28 ......(
        SSL3 alert write:fatal:handshake failure
        SSL_accept:error in SSLv3 read client key exchange B
        SSL_accept:error in SSLv3 read client key exchange B
        12155:error:1408B074:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:bad protocol version number:s3_srvr.c:1346:
        shutting down SSL
        ###@###.### 2001-12-18

        Being spec compliant may not be that easy. For the client side, as long as we want to interoperate with servers that implement the 'wrong' behavior, we have to send wrong version number in the premaster secret. Otherwise, they will refuse to talk to us. The problem does not occur if the maximum supported version is also the version the server chooses. That means, as more and more servers are upgraded to TLS 1.0 from SSL 3.0, this problem may go away. However, it may resurface when server implementations are upgraded to a later TLS version, if they still implement the incorrect behavior.

        On the other hand, what we should definitely do is change the handling on the server side. We should allow both the current behavior for interoperability but also permit spec compliant version numbers in the premaster secret. That is trivial and should be done for Hopper.

        ###@###.### 2001-12-19

        Agreed on the second paragraph.

        We may want to check to see how many of the
        existing servers do still indeed exhibit this behaviour,
        as if it's a rarity these days, we may want to go back.
        Mr. Maurus did run into this problem. Or maybe
        adding a system property which controls this behaviour...
        the default being false if we find that it's not uncommon
        to be broken.

        One of SQE's tasks was to do some interoperability testing,
        so this would be a good task for them to respond with.

        ###@###.### 2001-12-19


            Issue Links



                andreas Andreas Sterbenz
                wetmore Bradford Wetmore
                0 Vote for this issue
                0 Start watching this issue