The connection managers will use NIO, what about the core server?
Will the connnection manager<-> core server use SASL/TLS?
The connection manger will support SASL/TLS for client communications?
How will clients be allocated a connection manager? this is key as it will impact initial setup.
JM should still work out of the box as is?
Just wanted to get an idea of the general thinking behind the connection managers, (apart from taking the load off the core server).
Conor.
Here initially what I’'m thinking:
Ease of use is always important and clustering for HA has a tendency to go against that. Our goal is to make it very easy to deploy (auto discovery of the CMs, configuration from a central location, etc.)
It is our intention to provide SASL/TLS on the CM so the client is completely unaware they’'re connecting to anything other than a jabber endpoint. More likely than not, Server <-> CM communication will be unencrypted for performance reasons. It may be encoded into a binary stream using FastInfoset or equivalent, but nothing that increase load on the server.
The server code will be reevaluated for performance improvements where it will make an impact on performance. The lessons learned from CM will be incorporated into the Messenger.
Out of the box means that if no CM’'s are present, than messenger should behave has configured…for <5-6k connections. Therefore, CMs will be added, autoconfigured and most likely talk over 10015 (or another port). DNS or a load balancer will determine where the packets go first form external clients (CM or Server).
Does this answer your question?
Noah
Server ↔ CM communication will be
unencrypted for performance reasons.
I understand the performance reasoning but, if the communications between server ↔ CM are not encrypted when client ↔ CM are, you are then completely dismantling the security provided by this encryption and should not be using it at all. The point of encryption is so that no one can sniff packets in transmission and see part of the conversation, right there I can sniff packets between server ↔ CM if there is no encryption.
The core server, for the moment JiveMessenger will be, I think, the first to use this, doesn’'t use java.nio.
The connection manager <-> core server will use SASL/TLS like its explained in the JEP-114.
And then about the client view, My method is to do something like that :
you have a firewall/router which load balance connections, with iptables rules, to each connection manager who regroup all connection who it receive in one socket to the core server.
What do you mean saying JM ?
You’'re absolutely correct. However, any site you go that uses a load balancer or proxy is doing just this. They may encrypt between the load balancer and http server, but I doubt it unless it truly is sensitive information.
IPSec ESP (Encapsulated Security Payload) is another option, but requires the client to have turned on and enabled (and java needs to support it). So that’‘s not an option. It’‘s very cool, because it doesn’‘t encrypt the packet’'s routing information.
Here are some options that might be desirable. Let consider this diagram in our discussion.
C <- internet -> R <- DMZ -> CM <- private network ->S[/code]
where C[/b] is the client, R[/b] is a router, CM[/b] is the connection manager and S[/b] is the server. Also assume that encrypted packets from the client to CM and the Jive server is not hang on the internet.
Option 1. Decrypt at CM (we’'ll do this anyway so we know what to do with the packet) and re-encrypt with pre-establish SSL communication.
Option 2. Decrypt at CM (we have to) and communicate over regular socket using AES and a high performing encryption mode (CBC or a Strem Cipher like RC4) to encrypt the payload (here’'s an argument for the tag). This uses a shared key to encrypt and decrypt the payload.
Option 3. Decrypt at CM (…) and communicate over regular socket with no encryption.
I’'m pretty sure that these are rated in performance, 1 being the slowest and 3 being the fastest.
Now if your private network is secured from outsiders and you trust your insiders, then option 3 is sufficient. If you don’‘t trust ALL your insiders than 2 is an option, if you don’‘t trust anyone…well you got bigger problems :). Actually option 1 and 2 are very similar and 2 is more like IPSec’'s ESP (except uses shared secrets instead of PKI).
For the sake of time and to meet the bigger challenge of 100k connection/concurrent users, I’'d opt for option 3 to begin with. This is common, but your concerns are definitely not unheard.
Noah
Message was edited by:
noahcampbell - fixed my security statements thanks to http://en.wikipedia.org/wiki/Stream_cipherJM == Jive Messenger
Sounds resonable. It could even be configurable from the CM stand point if it could be determined that the CM is in a safe-zone. But as a point to start from without encryption I think is fair.
The problem is the client can be not connect in SSL mode so keep its first encryption can be insecure, then my first idea was to keep client encryption, but it can have a problem on the core server, because it will have to decrypt first the route packet, and then decrypt the client packet which its inside.
So my final idea is to negociate encryption between the connection manager and client, and then negociate and talk through the TLS/SASL encrypted socket, like its explained on JEP 114
Client to CM will be TLS/SASL or unencrypted. As far as the client is concerned, they’'re connected to a XMPP server that adhears to JEP-0114. The question that was raised was regarding CM to JM (Server) and the visibility of the packets passed between the two.
Noah
The JEP 114 says here ( http://www.jabber.org/jeps/jep-0114.html#proto ) that that :
“External components do not use the older Non-SASL Authentication protocol (i.e., the ‘‘jabber:iq:auth’’ namespace), nor do they (yet) use SASL authentication as defined in XMPP Core (although a future component protocol would most likely use SASL). Instead, they use a special element whose XML character data specifies credentials for the component’'s session with the server.”
so it’'s with SASL…
I’‘m not sure what point you’'re trying to make?
The JM with CM connection. You’‘re agree between the JM and CM we’'ll use the JEP 114 like a component ?
So it’'s already encrypted like its explained in the JEP
Oh scuse I’‘m not really experimented with security protocols, I juste viewed that SASL is only an authentication protocol, well so the JEP doesn’'t allow TLS ?
Because I know SASL is generally coupled with TLS no ?
TLS is also known as SSLv3. I think there are some small differences but for the most part, they’'re one in the same thing.
SASL is a protocol for negoiating which authentication mechasim to use. (http://www.answers.com/SASL) TLS can be used together.
Noah
Just wanted to chime in to say that I think Noah is right-on. A default of non-encryption between the CM and JM offers the best performance and is perfectly reasonable given the networking configurations of most organizations.
One stat I’‘d love to see at some point is how much SSL/TLS traffic a standard server box can handle with and without SSL hardware acceleration (I’'ve read that there are JSSE implementations backed by hardware).
Regards,
-Matt
I’‘m not sure, for me this service can be used only on internet, you do not have 100k connections in a building, and not always big companies want to apply it, so they haven’'t generally protected zone. So get it decrypted, for me, is really not secure…
Nahuel, I think you bring up a good point. While I understand that the design goal of Project Pampero is to improve the scalability of Messenger, it would seem to me a large, or depending on your requirements, a larger benefit of the project, will come from increasing the reliability of Messenger. If you’'re someone who is looking to deploy Messenger, and your goals are a high level of security and uptime for say, 10K users, then the overhead of supporting encryption between the CM and JM may be a non-issue.
Ideally, the best solution for everyone would be to make it extremely easy to turn encryption on or off. It’d be interesting to see if people are more interested in sheer numbers or reliability, not to say that they have to be mutually exclusive.
-Ryan
Yes, I’'m agree with you, more option it have more it will be better
It’d be interesting to see if people are more
interested in sheer numbers or reliability, not to
say that they have to be mutually exclusive.
Just wanted to add a note that improved reliability may be achieved with this project, but it’‘s not the main motivating factor. We’‘ll still have a single point of failure in this architecture, which is the core router. We won’'t have true reliability until we add clustering of core routers (another project).
-Matt
Is realiability of the CM desired? i.e. a CM fails, do 10k get broken and half to reestablish? Can this be done in java land?
Noah