2 Replies Latest reply on Jun 10, 2005 1:26 AM by Tom Elrod

    security issues

    mazz Master

      I delivered a presentation on JBoss/Remoting tonight at the Philly JBUG, and received a question that I didn't know the answer. I figured I post it here since I promised to find the answer :-)

      It involves security. We know that today JBoss/Remoting supports SSL, thus providing security at the low-level transport layer.

      But how does JBoss/Remoting plan to provide security against things such as denial-of-service or man-in-the-middle type attacks. Can JBoss/Remoting even combat these attacks or does something have to be built on top of it?

      I'm no security expert and don't understand all the nuances of these types of problems - hopefully, some one else does.

        • 1. Re: security issues
          Scott Stark Master

          The remoting layer is not responsible for dealing with man in the middle attacks. Its a function of the authentication layer, and ssl is not imune to such an attack as described here:

          http://www.sans.org/rr/whitepapers/threats/480.php
          and
          http://www-128.ibm.com/developerworks/linux/library/l-openssl2.html?ca=dgr-lnxw06SecureHandshake

          It all comes down to can you really trust the cert. You can certainly use other protocols like SRP which have good MITM proof characteristics.

          Denial of service can occur at many levels from the network routers, os network stack, java vm network stack, application layer handlers, etc. The basic theme is what happens when there is a flood of connections, at least as far as the remoting layer is concerned. Control of resources via pooling is essentially all remoting can do to avoid problems.

          • 2. Re: security issues
            Tom Elrod Master

            Uh, what he said...

            But to add a little more detail, the man in the middle is all up to network and authentication. If using SSL, can be somewhat restrictive as to what cert you will trust based on the ip that the cert says it is for vs. the ip that it actually came from (and a few other little tricks like this). For the most part, hard to be absolute.

            For denial of service, as Scott said, is usually more of an issue at the network level (and plenty of ways to configure routers, firewalls, etc. to combat this). For the jvm layer, the transports do provide configuration for at least putting controls around this. The socket transport is probably the best example where can set the connection pool size, backlog, etc.

            If the person that raised the question has any particular concerns, have them post here. Just to make sure I have all the angles covered. :)

            -Tom