Jetty
  1. Jetty
  2. JETTY-1477

Jetty ignores excluded cipher list when using async I/O

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 7.4.2
    • Fix Version/s: None
    • Component/s: Security and SSL
    • Labels:
      None
    • Environment:
      Jetty 3.4.2, Java 1.6.0_26 x86_64, SUSE Linux Enterprise Server 11 SP1 x86_64, kernel version 2.6.32.36-0.5
    • Number of attachments :
      0

      Description

      Using Jetty in a project at my place of work we excluded weak ciphers with a section like the following:

      <Configure id="Server" class="org.eclipse.jetty.server.Server">
      <!-- if NIO is not available, use org.eclipse.jetty.server.ssl.SslSocketConnector -->
      <Call name="addConnector">
      <Arg>
      <New class="org.eclipse.jetty.server.ssl.SslSelectChannelConnector">
      <Set name="Port"><SystemProperty name="webserver.port.https" default="8443"/></Set>
      <Set name="maxIdleTime">30000</Set>
      <Set name="Acceptors">2</Set>
      <Set name="AcceptQueueSize">100</Set>
      <Set name="Keystore"><SystemProperty name="mysecurity.config.home" />/config/.webserverkeystore.jks</Set>
      <Set name="Password">password</Set>
      <Set name="truststore"><SystemProperty name="mysecurity.config.home" />/config/.webserverkeystore.jks</Set>
      <Set name="trustPassword">password</Set>
      <!-- Only enable strong ciphers. -->
      <Set name="ExcludeCipherSuites">
      <Array type="java.lang.String">
      <Item>TLS_RSA_WITH_AES_256_CBC_SHA</Item>
      <Item>TLS_ECDH_ECDSA_WITH_RC4_128_SHA</Item>
      <Item>TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA</Item>
      <Item>TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA</Item>
      <Item>TLS_ECDH_RSA_WITH_RC4_128_SHA</Item>
      <Item>TLS_ECDH_RSA_WITH_AES_128_CBC_SHA</Item>
      snip
      <Item>TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5</Item>
      </Array>
      </Set>
      </New>
      </Arg>
      </Call>
      </Configure>

      In running some tests against the service, though, it appears that all kinds of ciphers are available that are not only medium or low strength, but even the null ciphers are showing up as options (they are also excluded in the snipped out section). I am told by one of the developers that we are using async (NIO) and I see the comment at the top of the XML configuration, but this should be available. Still, switching the fifth line to use org.eclipse.jetty.server.ssl.SslSocketConnector appears to work correctly in that the weak/low/null ciphers are no longer allowed.

      I have searched the changelog for Jetty, as well as open issues, and see nothing for this. The note above makes me think this could be a configuration error, but the developer involved is thorough so I am inclined to trust him. If there are any words of advice to help me narrow this down, or if there are specific tests I can do to verify this one way or another, I'm open to running others' code for that purpose (sadly, I am not a great programmer). The tests of available cipher suites originally came from Nessus but have been verified with tests done using openssl. One result of this issue is that products which should be secure can be tricked to do things insecurely on the wire, including using null ciphers.

      Reproducible: All of our systems implementing Jetty the same way exhibit the symptom of allowing what we believe are excluded cipher suites when using NIO.

      Expected Results: Excluded cipher suites should be excluded.

      Actual Results: Excluded cipher suites list appears to make no difference to the running service's available/used cipher suites.

        Activity

        Hide
        Jan Bartel added a comment -

        Aaron,

        I think this is a duplicate of this bug which was fixed:

        https://bugs.eclipse.org/bugs/show_bug.cgi?id=358674

        I would try the most recent stable release 7.5.4.v20111024, or the most recent release candidate for 7.6.

        Also, the recommended way to configure is to use the SslContextFactory:
        http://wiki.eclipse.org/Jetty/Howto/Configure_SSL

        Although it looks like the page on configuring cipher suites is a bit out of sync with that, so I'll fix it up.

        Jan

        Show
        Jan Bartel added a comment - Aaron, I think this is a duplicate of this bug which was fixed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=358674 I would try the most recent stable release 7.5.4.v20111024, or the most recent release candidate for 7.6. Also, the recommended way to configure is to use the SslContextFactory: http://wiki.eclipse.org/Jetty/Howto/Configure_SSL Although it looks like the page on configuring cipher suites is a bit out of sync with that, so I'll fix it up. Jan
        Hide
        Aaron Burgemeister added a comment -

        Jan,

        Thank-you for the response, and for finding the other bug. I will have the developer review the other bug and post feedback as I receive it. Below is more conversation I had with him that night which may also explain it:

        <quote>
        The select connector uses sslengine and reading the java doc it looks like cipher suites have to be set before this is ever initialized in java, so if some other component uses SSL these cipher suites will never be set properly.

        If something uses SSL before jetty initializes that is, and there are many other things in our product that might use that, like ActiveMQ.

        So, what I can do is take this configuration out of jetty and instead set this in our InitializerComponent which gets run before almost anything else.

        The sslsocket one does not use sslengine. This explains the difference: http://docs.codehaus.org/display/JETTY/Ssl+Connector+Guide so jetty may not actually have a bug but that configuration assumes jetty is running by itself and not embedded in another product that uses SSL elsewhere.
        </quote>

        Show
        Aaron Burgemeister added a comment - Jan, Thank-you for the response, and for finding the other bug. I will have the developer review the other bug and post feedback as I receive it. Below is more conversation I had with him that night which may also explain it: <quote> The select connector uses sslengine and reading the java doc it looks like cipher suites have to be set before this is ever initialized in java, so if some other component uses SSL these cipher suites will never be set properly. If something uses SSL before jetty initializes that is, and there are many other things in our product that might use that, like ActiveMQ. So, what I can do is take this configuration out of jetty and instead set this in our InitializerComponent which gets run before almost anything else. The sslsocket one does not use sslengine. This explains the difference: http://docs.codehaus.org/display/JETTY/Ssl+Connector+Guide so jetty may not actually have a bug but that configuration assumes jetty is running by itself and not embedded in another product that uses SSL elsewhere. </quote>
        Hide
        Aaron Burgemeister added a comment -

        Update: The tests determining which cipher suites were available from Nessus were invalid. The service responds slightly differently depending on the classes used, and it confuses Nessus, but from my manual testing the weak/null cipher suites are not available for use despite this bad report from Nessus. This report is invalid. Sorry for the time wasted.

        Show
        Aaron Burgemeister added a comment - Update: The tests determining which cipher suites were available from Nessus were invalid. The service responds slightly differently depending on the classes used, and it confuses Nessus, but from my manual testing the weak/null cipher suites are not available for use despite this bad report from Nessus. This report is invalid. Sorry for the time wasted.

          People

          • Assignee:
            Unassigned
            Reporter:
            Aaron Burgemeister
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: