Discussions

News: SSL for JMS: A sledgehammer to crack a nut?

  1. SSL for JMS: A sledgehammer to crack a nut? (21 messages)

    SSL is frequently used to secure messaging communications, including JMS. But is this using a sledgehammer to crack a nut? One of the main concerns of any middleware security solution is encryption. A new article on JDJ discusses different encryption technologies to secure JMS and how to find the best compromise between security and performance.

    Read SSL for JMS: A sledgehammer to crack a nut?.

    Threaded Messages (21)

  2. Is seems to me that article focuses on a niche MOM. As far as I know the biggest MOM market share by far belongs to MQ Series (I recall reading about 70% or so) ... and yet almost nothing in the article is applicable to it (at least up to 5.2 version). MQ seems to be mostly server to server messaging (distributed servers) vs described in the article central one. Also MQ is written mostly in C with JMS classes using JNI ... that would definetely help encryption performance .. if MQ had any ;)
    Does it mean that a secure messaging is not that important in most scenarios? Or people use 3rd party ad-ons (Candle?) to provide some?
    The way we've been using MQ so far, the whole security was provided by firewalls.

    Cheers,
    Krzysztof
  3. <Krzysztof>
    Is seems to me that article focuses on a niche MOM. As far as I know the biggest MOM market share by far belongs to MQ Series (I recall reading about 70% or so)
    </Krzysztof>

    Websphere MQ actually owns much more of the market than this. Most analyst state that they have in excess of 80%. However, much of this comes from mainframe sales which is a market unaddressable by the other vendors.

    <Krzysztof>
     ... and yet almost nothing in the article is applicable to it (at least up to 5.2 version).
    </Krzysztof>

    Websphere MQ 5.3 includes SSL for channel level encryption. All of the other major vendors also use this technique (Tibco E4JMS, Sonic, SpiritSoft, Fiorano, ...)

    <Krzysztof>
     MQ seems to be mostly server to server messaging (distributed servers) vs described in the article central one.
    </Krzysztof>

    The principles are identical whether it is client to server or server to server. You either encrypt the channel or the body of the message.

    <Krzysztof>
    Does it mean that a secure messaging is not that important in most scenarios?
    </Krzysztof>

    In the many implementation projects I have been involved with, roughly 50% have found encryption to be irrelevant. For the other 50% it has been a been a critical business requirement that they are obsessed with.

    <Krzysztof>
    The way we've been using MQ so far, the whole security was provided by firewalls.
    </Krzysztof>

    Firewalls solve a different security problem to encryption - they are enforcing perimeter access control rather than preventing unauthorised viewing of business-critical data.

    Steve
  4. Guns to kill Ants ...[ Go to top ]

    I guess its common these days that people use guns to kill ants.
       Over design / making unnecessary complex designs resulting in highly unmanagable systems.
       Its all bcoz a lot of the population doesnt know whats OOP and why use OOP. They just know that they have to someohow use OOP.
      My comments may be generic and little out of context with the thread here, but there is a great need to really make people understand "Simple Designs" or "Simple Patterns".
      I wish I can call "Java has a high learning curve" a joke.
    I think java is simple, but people make it complex most of the time.
      The "Bitter XXX" is a good series and I would love to see more Architects come forward with nice articles on how to use OOP for better & managable systems.
  5. I think the article gives a fair representation of the some of the disadvantages of using SSL. It correctly identifies SSL as being more than just an encryption mechanism. It is a security protocol which provides for two way authentication (where required) and for the establishment of a one time secret key. Both of these can also be advantages.

    The article glosses over the fact that authentication and key distribution remain issues whether SSL is used or not. The problem in the case of SSL is that the entire protocol is executed every time a connection is established. (Actually the SSL spec. allows for secret keys to be re-used. However I'm not sure if this is implemented in practise.) If SSL is not used then authentication and key distribution must be performed by a third party, possibly increasing compexity and cost.

    In many circumstances, where long term connections are established and prolonged high volume messaging is not anticipated then SSL represents the easiest and cheapest means of establishing secure communications. If much of the data is not sensitive then separate connections can be used for secure and insecure communications.

    I would take the warnings of the article on board. Don't use SSL unthinkingly, but likewise don't automatically reject it.
  6. I think the article gives a fair representation of the some of the disadvantages of using SSL.


    Thank you :-)

    >
    > The article glosses over the fact that authentication and key distribution
    >remain issues whether SSL is used or not.

    In most of the projects I have been involved with, they were eager not to do key distribution and suffer the pains that widespread key mgmt would inflict. Instead they are happy to have the server authenticate itself with the client using its certificate but allow the client to employ name / password to authenticate itself.

    >
    > In many circumstances, where long term connections are established and
    >prolonged high volume messaging is not anticipated then SSL represents the ?
    >easiest and cheapest means of establishing secure communications.

    Actually I think that message body encryption is the best solution. The vendors that support this allow it to be administratively defined and so it is very easy and cheap.

    Steve
  7. Frankly, I don't really understand the raison d'etre for the article. The main purpose of a MOM system, including JMS, is to deliver messages in sorta-realtime manner between components in an uncoupled manner. Any coupling that exists is a temporary association within the MOM infrastructure - there's no direct connection between a publish and subscriber(s) or a queue sender and receiver.

    MOM stuff is also typically asynchronous in nature on the receiver side. In short, the receiver never knows when a message is going to come in. So an asynchronous callback is invoked when a message does in fact come in.

    Given the above - a typical usage for JMS is that you keep your JMS connections & sessions open. On the pub/sender side, this is for convenience as well as for a small performance boost. On the receiver side, it's a must - you have to keep your connection open because you don't know when messages are coming in.

    If you're using queues, or durable subscribers, you can code a receiver which comes up periodically to suck up messages and then closes down its connection, but this I believe is more of an exception than the rule.

    And using JMS over the Internet? I don't see that being common at all. JMS is intended to be an Enterprise messaging system, not an Internet messaging system. Indeed, most MOM implementations I've seen have either no Internet support, or extremely poor support (like using HTTP to tunnel through firewalls - slow and quirky). On top of this, JMS does not mandate a standard protocol, and as a result almost no MOMs can interoperate without some sort of gateway (and some can't interoperate at all).

    The net effect - most people are keeping their connections open, and if they want encyption the SSL open and tear down costs will be insignificant. As for the Internet side, I see that as mostly a red herring - the article is looking to patch a flawed architecture - e.g. the problem isn't SSL costs using JMS over the Internet, the problem is trying to use JMS over the Internet at all.

    Even if you tried this route all of your "partners" would need to use the exact same JMS provider because there's no standard JMS protocol. How likely is that?

    As a side note - SSL encryption costs are easily amortized by using multiple cheap servers.

         -Mike
  8. I forgot to mention the most obvious thing - if you have a true "partner" situation and you can somehow agree upon a common MOM implementation (perhaps you share a common application infrastructure for certain usages), then probably the best way to go is with VPN.

        -Mike
  9. some things bridge more easily then others[ Go to top ]

    at least of MOM. MQSeries to MSMQ bridge (questionable but it exists), and vendor specific to generic bridge (Sonic is a good example of this). But if you were in a true semi-trusted partner environment, most likely for moms one side or the other will be using MQSeries, for which many bridges exist.
  10. some things bridge more easily then others[ Go to top ]

    In my experience most bridge solutions don't bridge very well. They typically support only limited, specific functionality, there are corner cases where two MOM's don't quite "fit", performance can be significantly degraded, and you're adding an extra point of failure into your architecture.

    Sometimes you have no choice but to bridge, but I tend to avoid it when I can, because bridges so often get the hard cases wrong. For example - consider the JMS acking model, and propogating ACKs and redelivers properly from a publisher on one MOM and a subscriber on the other. Then roll in XA transactions on either side for a really hair-raising ride.....

    For simple applications none of the above may matter...but at the same time simple applications have an annoying tendency to grow beyond their initial scope. Or worse - someone sees the small system working and takes it as proof that they can use the same infrastructure in a complex multi-partner Enterprise application, and it's 4 months into the Uber project before anyone notices that messages get dropped every once in a blue moon by the bridge...

         -Mike
  11. Sometimes you have no choice but to bridge, but I tend to avoid it when I

    >can, because bridges so often get the hard cases wrong. For example -
    >consider the JMS acking model, and propogating ACKs and redelivers properly
    >from a publisher on one MOM and a subscriber on the other. Then roll in XA
    >transactions on either side for a really hair-raising ride.....
    >

    I don't understand your point here. The producer interacts with the server using acks and XA. The messages get into the server. The bridge reliably delivers the messages into the other MOM's server (no need to use XA for this). The consumer then interacts with server #2 to retrieve messages using acks and XA. Where are the bridge issues?

    Steve
  12. \Tyrthall\
    I don't understand your point here. The producer interacts with the server using acks and XA. The messages get into the server. The bridge reliably delivers the messages into the other MOM's server (no need to use XA for this). The consumer then interacts with server #2 to retrieve messages using acks and XA. Where are the bridge issues?
    \Trythall\

    My point wasn't on the theory of how to get it right, but the reality of real bridging products available today. They often get many of the details plain _wrong_ when hooking two or more messaging products together. They drop messages, or crash, or perform badly, or don't pass proprietary properties along properly, or mis-translate certain message types....or any number of other issues.

         -Mike
  13. Common protocols[ Go to top ]

    Even if you tried this route all of your "partners" would need to use the exact same JMS provider because there's no standard JMS protocol. How likely is that?


    Very interesting comment. It very much reminds me of the early days of CORBA. Standard was defined on an API level, not on a protocol level. Only later one discovered that systems based on different ORB implementations might indeed want to work together.

    I assume this subject is once and for all solved by webservices, n'est-ce pas ?

    Matthias
  14. Common protocols[ Go to top ]

    <Ernst>
    Very interesting comment. It very much reminds me of the early days of CORBA. Standard was defined on an API level, not on a protocol level. Only later one discovered that systems based on different ORB implementations might indeed want to work together.
    </Ernst>

    Yes, that's a pretty accurate observation. And generally JMS is still a very immature standard in my opinion. In particular it covers too much ground - queues, pub/sub, message persistence vs. durable subscribers vs. total non-persistence, the acking model, loose definitions of "administered destination" with no explicit mention of dynamic destination creation, weird XA interaction
    compared to JDBC (well, at least the last is getting better
    with JCA). Plus mandated single-threaded sessions, a very inefficient spec for ServerSessionPools etc.

    The net sum is that each JMS vendor feels obligated to implement everything in the spec, even when it doesn't match their original MOM technology - like MQ doing pub sub, high speed/low latency market middleware bolting on persistence, etc. And even when a part of the spec is in their sweet spot, another aspect will scuttle their performance, like the acking model and single-threaded sessions.

    Given all this it's little wonder that many app servers would only work with their own in-house JMS implementation, and it's only recently that interoperation has become common. And that's just interfacing at the Java Interface level via initial JNDI lookups. Interoperating at the protocol level is many, many years away.

    <Ernst>
    I assume this subject is once and for all solved by webservices, n'est-ce pas ?
    </Ernst>

    Yep - it matches the "partners communicating" scenarios pretty well. But I think there's a way to go there to get XML messaging to scale well to high volumes, and the definitions around failure & recovery seem way too light for serious applications.

        -Mike
  15. single-threaded sessions[ Go to top ]

    <Ernst>

    > Very interesting comment. It very much reminds me of the early days of CORBA. Standard was defined on an API level, not on a protocol level. Only later one discovered that systems based on different ORB implementations might indeed want to work together.
    > </Ernst>
    >
    > Yes, that's a pretty accurate observation. And generally JMS is still a very immature standard in my opinion. In particular it covers too much ground - queues, pub/sub, message persistence vs. durable subscribers vs. total non-persistence, the acking model, loose definitions of "administered destination" with no explicit mention of dynamic destination creation, weird XA interaction
    > compared to JDBC (well, at least the last is getting better
    > with JCA).

    >Plus mandated single-threaded sessions,

    I am in violent agreement with you on this point. The single-thread constraint was there in order to placate some of the proprietary MOM vendors who were involved in writing the spec. There is at least one JMS vendor which allows multi-threaded sessions but had to include a proprietary extension to sort out the ack'ing issues (ie ack on this thread does not ack messages on other thread in the session).

    I was on the Sun JMS expert group last year and desperately tried to get them to open up the spec process again to include multi-threaded sessions. However, the whole JMS 1.1 process was a fiasco and they fought it off ;-(

    >Interoperating at the protocol level is many, many years away.

    I doubt if this will ever happen. There would be too much resistance from the vendors and not enough demand in the market. Much of the demand is met by bridges (warts and all)

    Steve
  16. single-threaded sessions[ Go to top ]

    Plus mandated single-threaded sessions,


    \Trythall\
    I am in violent agreement with you on this point. The single-thread constraint was there in order to placate some of the proprietary MOM vendors who were involved in writing the spec. There is at least one JMS vendor which allows multi-threaded sessions but had to include a proprietary extension to sort out the ack'ing issues (ie ack on this thread does not ack messages on other thread in the session).
    \Trythall\

    This doesn't make a lot of sense to me. The spec itself states that mandated single-threading was for the convenience of JMS _clients_, not the MOM vendors. And I don't see the value MOM vendors get out of this either - I'd say "assume onMessage() _can_ be hit in a multi-threaded manner". This means a single-threaded session interface is perfectly valid, and at the same time a multi-threaded one can be a quality of implementation issue. This is an area where a spec is superfluously over-constraining implementations for no good reason, and shoots the MOM vendors themselves in the foot (because apps can legally have non-thred-safe code in onMessage(), and therefore _no_ vendor can have a multi-threaded session implementation and expect it to work on legal app code).

    \Trythall\
    I was on the Sun JMS expert group last year and desperately tried to get them to open up the spec process again to include multi-threaded sessions. However, the whole JMS 1.1 process was a fiasco and they fought it off ;-(
    \Trythall\

    Well, that point it was probably too late. Allowing it could easily break alot of existing code. Although, if people wanted it badly enough it could be a new option to the session factories (e.g. SESSION_ALLOW_MULTI_THREADS or some such).

    But, in any case, I think we'll see a brand new MOM-oriented spec (perhaps grassroots :-) before JMS changes significantly (or perhaps JCA will lead the way).

        -Mike
  17. single-threaded sessions[ Go to top ]


    > This doesn't make a lot of sense to me. The spec itself states that
    > mandated single-threading was for the convenience of JMS _clients_, not the
    > MOM vendors. And I don't see the value MOM vendors get out of this either -
    > I'd say "assume onMessage() _can_ be hit in a multi-threaded manner". This
    > means a single-threaded session interface is perfectly valid, and at the
    > same time a multi-threaded one can be a quality of implementation issue.
    > This is an area where a spec is superfluously over-constraining
    > implementations for no good reason, and shoots the MOM vendors themselves in
    > the foot (because apps can legally have non-thred-safe code in onMessage(),
    > and therefore _no_ vendor can have a multi-threaded session implementation
    > and expect it to work on legal app code).

    The spec does not say this "was for the convenience of JMS _clients_". It says:

    1. To make transaction implementation less complex (ie help the vendors)

    2. To make async receipt handlers simpler. (ie help the client writer)

    If I have understood your onMessage point, you are suggesting that the vendor implementation manages the threads and creates them and calls onMessage as messages arrive. The alternative is that the client writer manages these threads and then the JMS implementation needs to be enhanced to deal with the change in ack semantics.

    Steve
  18. Frankly, I don't really understand the raison d'etre for the article. The

    >main purpose of a MOM system, including JMS, is to deliver messages in sorta-
    >realtime manner between components in an uncoupled manner. Any coupling that
    >exists is a temporary association within the MOM infrastructure - there's no
    >direct connection between a publish and subscriber(s) or a queue sender and
    >receiver.
    >

    Hey - I'm the high priest of async, loosely-coupled architectures; there was therefore no attempt to suggest direct coupling between producer and consumer.
     
    >
    > Given the above - a typical usage for JMS is that you keep your JMS
    >connections & sessions open.

    Long-lived connections are more prevalent but I have also seen a lot of architectures where ephemeral connections made most sense. In such scenarios the connections are being continually brought up and down.

    > And using JMS over the Internet? I don't see that being common at all. JMS
    >is intended to be an Enterprise messaging system, not an Internet messaging
    >system. Indeed, most MOM implementations I've seen have either no Internet >support, or extremely poor support (like using HTTP to tunnel through
    >firewalls - slow and quirky). On top of this, JMS does not mandate a >standard protocol, and as a result almost no MOMs can interoperate without >some sort of gateway (and some can't interoperate at all).
    >

    This is the part that I disagree with most strongly. I have seen JMS products used in many Internet deployments. Using JMS over the Internet I've seen:

      o Global manufacturers link their sites world-wide.
      o Stock trading platforms link to customers
      o B2B trading exchanges integrate partners
      o Air cargo terminals communicate with their customers

    The list could go on and on. Although the majority of MOM implementations are done within the confines of the firewall, there are many many implementations that span multiple departments, business units and companies for whom communication beyond their firewall is key.

    >
    > Even if you tried this route all of your "partners" would need to use the
    >exact same JMS provider because there's no standard JMS protocol. How likely >is that?

    Quite likely. For example, a JMS product is built into both the partner trading platforms from GE Exchange and Commerce One. Where imposing a JMS vendor's product is a problem, a number of vendors support SOAP or HTTP access into their brokers.

    >
    > As a side note - SSL encryption costs are easily amortized by using multiple
    >cheap servers.

    There is no free lunch here. Agreed that commodity servers is a great way to go - however you still need to buy more servers, more licenses and manage it all. Also to succeed you need a JMS product that clusters well - for example are the durable subscriptions available everywhere in the cluster.

    Steve

  19. > Given the above - a typical usage for JMS is that you keep your JMS
    >connections & sessions open.

    \Trythall\
    Long-lived connections are more prevalent but I have also seen a lot of architectures where ephemeral connections made most sense. In such scenarios the connections are being continually brought up and down.
    \Trythall\

    On the publishing side, this only makes sense if you're sending very, very few messages. Otherwise, the cost of creating a connection significantly increases your latency and throughput.

    On the subscription side, it doesn't make much sense to me at all. The entire point of MOM systems is to deliver data as it becomes available to interested parties (sort of an enterprise-level, cross process event system :-). With that sort of viewpoint, subsribers typically don't "pull" data when they feel like it, instead it is pushed to them when something's there. If subscribers only connect once in awhile, process some stuff, then disconnect, then you don't really _need_ MOM to begin with - a request/response system will more than suffice.

    \Trythall\
    This is the part that I disagree with most strongly. I have seen JMS products used in many Internet deployments. Using JMS over the Internet I've seen:

      o Global manufacturers link their sites world-wide.
      o Stock trading platforms link to customers
      o B2B trading exchanges integrate partners
      o Air cargo terminals communicate with their customers

    The list could go on and on. Although the majority of MOM implementations are done within the confines of the firewall, there are many many implementations that span multiple departments, business units and companies for whom communication beyond their firewall is key.
    \Trythall\

    I suppose our experience has differed widely - I've never seen or heard of an Internet JMS deployment up until now (and still believe it's a bad idea). I can say with fair confidence that deployments behind firewalls are not simply a majority, but an overwhelming majority.

    \Tyrthall\
    [On SSL servers and server farms]
    There is no free lunch here. Agreed that commodity servers is a great way to go - however you still need to buy more servers, more licenses and manage it all. Also to succeed you need a JMS product that clusters well - for example are the durable subscriptions available everywhere in the cluster.
    \Trythall\

    This is true. But the original article made SSL costs appear to be insurrmountable, when in fact they are not.

         -Mike
  20. Other Usage scenarios[ Go to top ]


    > On the subscription side, it doesn't make much sense to me at all. The
    > entire point of MOM systems is to deliver data as it becomes available to
    > interested parties (sort of an enterprise-level, cross process event
    > system :-).

    I think this is too much of a generalisation. There are other characteristics of a MOM that lead people to chose them over simple "request/response". In fact "delivering data when it becomes available" could easily be done with an RPC. Here are some other use cases

    0. Where reliable delivery is key (arguably the prime reason people chose a MOM)
    1. Where you want to totally decouple producer from consumer. Producer does a fire and forget and has no knowledge of consumer. This is used both as an architecture principle and as a way of structuring development teams. For example, in banks where the various application teams are relatively independent and focus on processing message types.
    2. Where the MOM is front-ending some processing components (eg EJBs) and is used to store up requests when the request rate temporarily exceeds the processing rate.
    3. Where you want to do async request/reply. If the request processing may take some time (or require human input) the reply can come back as an async message.
    4. Where you want consumers to be able to filter the data being produced. Organising by topic hierarchy or message selectors are useful tools during architecturing.
    5. and many more

    I'm sure this is "teaching Grandmother to suck eggs" but it was cathartic for me to write ;-)

    Steve
  21. Other Usage scenarios[ Go to top ]

    \Trythall\
    I think this is too much of a generalisation. There are other characteristics of a MOM that lead people to chose them over simple "request/response". In fact "delivering data when it becomes available" could easily be done with an RPC. Here are some other use cases
    \Trythall\

    OK, here we go :-) Incidentally - how does an RPC work asynchronously?



    0. Where reliable delivery is key (arguably the prime reason people chose a MOM)



    In a case where connections are ephemeral, a "pull" via a request is just as reliable as a "push" from a MOM, and with far less infrastructure to boot.

    MOMs aren't about reliable delivery, really. They're about _fast_ delivery, decoupling, and async notification. The "reliable" part is, in fact, completely optional and often not used in high performance cases (or where message loss is acceptable).

    If you don't want it fast and async, use a database, or a network-based service on top of a database. You'll get the same exact reliability. You are somewhat more coupled, yes, but not very much (because you're hitting a service, not linking/calling a specific piece of code).

    \Trythall\
    1. Where you want to totally decouple producer from consumer. Producer does a fire and forget and has no knowledge of consumer. This is used both as an architecture principle and as a way of structuring development teams. For example, in banks where the various application teams are relatively independent and focus on processing message types.
    \Trythall\

    This is generally true. But keep in mind that connecting to a provider and subscribing to a topic is not _that_ much more decoupled than connecting to a network service and asking for data. In both cases, code coupling is non-existent.

    \Trythall\
    2. Where the MOM is front-ending some processing components (eg EJBs) and is used to store up requests when the request rate temporarily exceeds the processing rate.
    \Trythall\

    Not applicable - in this case the receiver damn well better always be connected to the MOM to receive new requests in a timely manner.



    3. Where you want to do async request/reply. If the request processing may take some time (or require human input) the reply can come back as an async message.



    Using JMS for async request/reply is a, in my opinion, an incredibly bad idea. Everytime I've seen it used there have been much cleaner ways to accomplish the same thing.



    4. Where you want consumers to be able to filter the data being produced. Organising by topic hierarchy or message selectors are useful tools during architecturing.



    MOMs need to do this, obviously. But you seem to be saying that no other technology allows for data filtering. This is obviously very, very incorrect.

         -Mike
  22. Mikeeeeeeee boy![ Go to top ]

    Mike,
       
      This has nothing to do with JMS and SSL, sorry. I posted a message in another thread but you probably missed it. I'd like to catch up with you; it's been a long time since we spoke. Shoot me an email, my man, I'd like to know what you've been up to.

    To everyone that's reading this, I'd like you to know that Mike Spille is a "legend". This guy can write systems in his head while doing circles around all of us put together. I worked for him a few years ago while I was interning for a company in New York City. Nice guy, cocky as hell too :-P


    soundfactory_ at hotmail dot com

    Raffi