7 Replies Latest reply: Jul 28, 2010 10:04 AM by 843811 RSS

    JDK 1.6 SSL/TLS vulnerability

    843811
      Hi all,

      I read SUN review about this vulnerability (http://java.sun.com/javase/javaseforbusiness/docs/TLSReadme.html).
      How can I set a client application to avoid renegotiation? sun.security.ssl.allowUnsafeRenegotiation=false ?

      Regards
        • 1. Re: JDK 1.6 SSL/TLS vulnerability
          EJP
          How can I set a client application to avoid renegotiation? sun.security.ssl.allowUnsafeRenegotiation=false?
          Read the document you cited. I don't understand why you think you need a second opinion.
          • 2. Re: JDK 1.6 SSL/TLS vulnerability
            843811
            Hi ejp,

            Because I tried with "sun.security.ssl.allowUnsafeRenegotiation=false" and in the server-side, in the apache log, I have something like "Re-negotiation request failed"
            Can you help me?


            Regards
            • 3. Re: JDK 1.6 SSL/TLS vulnerability
              EJP
              I don't understand. You specified no renegotiation and you got it. What's the problem?
              • 4. Re: JDK 1.6 SSL/TLS vulnerability
                843811
                Hi,

                I will try to write a overview of my problem: i want to guarantee the communication between a client and a server through a SSL client-side communication.
                The only way I found to do this was setting "sun.security.ssl.allowUnsafeRenegotiation=true" on client-side application and "SSLInsecureRenegotiation on" on server side (in Apache). This way, I think that the server is exposed to the vulnerability. If I don't set any of the properties that I wrote before, I can't establish the SSL communication. What I have to do to eliminate the vulnerability?

                Regards
                • 5. Re: JDK 1.6 SSL/TLS vulnerability
                  843811
                  You have an Apache problem, not a Java problem. Your apache instance cannot mix server-only authentication for some links with client and server authentication for others. Basically, you have to dedicate a server port to always require client authentication.
                  • 6. Re: JDK 1.6 SSL/TLS vulnerability
                    843811
                    Hi,

                    In the Apache, a virtual host is configured (with an unique public IP, port 443) where all requests are authenticated with a SSL client-side.
                    Does this configuration wrong? If yes, can you give me a sample of what were you talking about?

                    Regards
                    • 7. Re: JDK 1.6 SSL/TLS vulnerability
                      843811
                      Hi,

                      I have found the solution of my problem.
                      As ghstark wrote, the problem can be fix in the apache side.

                      In this URL (https://access.redhat.com/kb/docs/DOC-20491), I found something like this:

                      Server-initiated renegotiations can be avoided by:

                      * Changing the site layout so that a client certificate authentication is required for the whole site, rather than only a part. In other words, so that "SSLVerifyClient" is used only when directly inside a <VirtualHost> section.
                      * Using the same cipher suite for the whole site. The highest cipher strength requirement of all directories and locations should be set in the <VirtualHost> section.

                      This solved my problem.

                      Regards