Qpid
  1. Qpid
  2. QPID-2518

Qpid C++ broker can easily be blocked by client trying to connect over SSL port

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.17
    • Component/s: C++ Broker
    • Labels:
      None
    • Environment:

      Red Hat Enterprise MRG 1.2

      Description

      We are running a C++ broker as deamon with the following configuration:

      log-enable=info+
      log-to-file=/var/lib/qpidd/op_prod09/data/0097/qpidd.log
      log-to-syslog=no
      auth=yes
      acl-file=qpidd.acl
      realm=QPID0097
      data-dir=/var/lib/qpidd/op_prod09/data/0097
      pid-dir=/var/lib/qpidd/op_prod09/data/0097
      port=20097
      wait=30
      num-jfiles=4
      jfile-size-pgs=1
      wcache-page-size=128
      tpl-num-jfiles=4
      tpl-jfile-size-pgs=1
      tpl-wcache-page-size=128
      ssl-cert-db=/var/lib/qpidd/op_prod09/data/0097
      ssl-port=10097
      ssl-cert-name=RGC001
      ssl-cert-password-file=/var/lib/qpidd/op_prod09/data/0097/amq_cert_db.pwd
      ssl-require-client-authentication=yes
      cluster-name=QPID0097
      cluster-url=amqp:tcp:172.16.45.198:20097
      cluster-username=xxxxx
      cluster-password=xxxxx

      We tried to connect an application to the SSL port which does not "talk" the correct protocol. We simply used telnet:
      $ telnet 172.16.45.198 10097

      The result was (we waited at least 30 min, then killed the process running telnet):
      The broker doesn't react anymore, no more new client connections can be established, the broker even cannot be stopped with "qpidd -p 20097 -q".

      This way anybody in the world could easily block our service provided over a Qpid broker.
      Is there a way to get around this?

      This issue has also been reported as Red Hat service request no. 2014266.

        Issue Links

          Activity

          Justin Ross made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Andrew Stitcher made changes -
          Link This issue is related to QPID-2616 [ QPID-2616 ]
          Andrew Stitcher made changes -
          Link This issue is related to QPID-4021 [ QPID-4021 ]
          Hide
          Andrew Stitcher added a comment -

          Good point - that'll teach me to actually read the words in the bug report, rather than reading the words I expect to be there.

          Show
          Andrew Stitcher added a comment - Good point - that'll teach me to actually read the words in the bug report, rather than reading the words I expect to be there.
          Hide
          Gordon Sim added a comment -

          The bug as originally reported related to broker threads being blocked on SSL handshake. The further 'fix' is for a separate issue preventing idle connections being established (note however that it only handles a particular pattern there anyway).

          Show
          Gordon Sim added a comment - The bug as originally reported related to broker threads being blocked on SSL handshake. The further 'fix' is for a separate issue preventing idle connections being established (note however that it only handles a particular pattern there anyway).
          Hide
          Andrew Stitcher added a comment -

          This change limits the impact of CVE-2012-2145. But doesn't prevent a determined DoS attack on a broker.

          Show
          Andrew Stitcher added a comment - This change limits the impact of CVE-2012-2145. But doesn't prevent a determined DoS attack on a broker.
          Andrew Stitcher made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Fix Version/s 0.17 [ 12320179 ]
          Resolution Fixed [ 1 ]
          Hide
          Andrew Stitcher added a comment -

          These code changes introduce a timer that gets started when a new connection is accepted.

          If the protocol negotiation phases isn't completed within a specified period then connection will be aborted.

          A new option is introduced to control the timer timeout period:
          --max-negotiate-time <time in milliseconds>

          The default timeout is 2000ms (2s) which gives a lot of latitude for network delays.

          Show
          Andrew Stitcher added a comment - These code changes introduce a timer that gets started when a new connection is accepted. If the protocol negotiation phases isn't completed within a specified period then connection will be aborted. A new option is introduced to control the timer timeout period: --max-negotiate-time <time in milliseconds> The default timeout is 2000ms (2s) which gives a lot of latitude for network delays.
          Hide
          Andrew Stitcher added a comment -

          This bug also applies to regular TCP connections

          Show
          Andrew Stitcher added a comment - This bug also applies to regular TCP connections
          Andrew Stitcher made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Assignee Andrew Stitcher [ astitcher ]
          Hide
          Andrew Stitcher added a comment -

          As far as I can tell this bug is still present. Despite any comments above.

          Show
          Andrew Stitcher added a comment - As far as I can tell this bug is still present. Despite any comments above.
          Gordon Sim made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Gordon Sim added a comment -

          See also https://issues.apache.org/jira/browse/QPID-2083 and note that r790291 makes the error handling less meaningful.

          Show
          Gordon Sim added a comment - See also https://issues.apache.org/jira/browse/QPID-2083 and note that r790291 makes the error handling less meaningful.
          Hide
          Gordon Sim added a comment -

          A further measure would be to have a configurable timeout for connections that do not complete the handshake and disconnect them.

          Show
          Gordon Sim added a comment - A further measure would be to have a configurable timeout for connections that do not complete the handshake and disconnect them.
          Hide
          Gordon Sim added a comment -
          Show
          Gordon Sim added a comment - I believe this is addressed by http://svn.apache.org/viewvc?view=revision&revision=790291 .
          Armin Noll created issue -

            People

            • Assignee:
              Andrew Stitcher
              Reporter:
              Armin Noll
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development