Does anyone know if the base Connect:Direct protocol ( used between two IBM Sterling secure proxy instances) supports encryption ? Or do you need to enable the Secure+ extension to obtain this feature ?
Thanks,
Ranjit
Connect Direct itself is secure, as no node without having the right information (IP AND NODE NAME) can access.
However the security for data streamed enroute should be done using Secure plus which involves certificate - implementing it would be a viable solution so long as traffic passes over internet and different datacenters.
Related
To be specific I want to check feasibility and direction for my current semester project.
The scenario is ,i have attacker , my system , and victim server.Whatever DDoS traffic i wanna send must go through my system and then forward to victim server. I want to filter the traffic to check whether they are from legitimate users or infected PCS by checking and filtering packets and to allow access to only legitimate users.
Is it possible to design such scenario without routers (which can apply filters for this purpose) by sniffing packets through my system and check them and send request to victim server ? (i am thinking of victim should point or match there nameservers to ours for it)
is it possible to do it on single system by using multiple ips (localhost alike) to simulate this scenario?
Do i have use Winpcap for sniffing packets or there are any better solution or library available?
Regards
You can very easily recreate this scenario with use of virtual machines virtualbox. Simply install it, create a victim VM, couple attackers, configure them on a separate network which will be routed by another virtual machine which will "emulate" the router.
This is as close to replica of your described environment as you can get without additional hardware. It will take a bit of time and research to set up properly, but that is the point of studying.
what's the best way to program a peer-to-peer chat with encryption. is SSL useful for p2p as the clients won't have a certificate signed by verisign,...? is it possible to program such a chat without a master-server that tells the client the ip's of their chat partner?
i'd really like to program such a chat program, because in times of all those privacy issues i want a program i really can trust. i've got some experience with network programming, but only client <-> server.
i don't want any code, just the theory part of a peer-to-peer chat (like skype).
thanks.
First, you can enforce using self signed certificates at both ends OR you can even use 'pre shared key' instead of certificate for authentication. Pre shared key is supposed to be known by all parties involved in advance.
Secondly, SSL is an encryption mechanism so it has no bearing on design of communication model i.e. client/server vs p2p.
Lastly, if both of your p2p nodes have public or live ip's and each of them knows about the other's, then you don't need any kind of central server. The real problem here is that in practice, most of machines are behind firewalls using NAT's and private ip's. So you need some kind of mechanism to traverse through NAT, determine the public ip and port in order to reach the destination machine successfully.
Take a look at the following SO question and it's answer i wrote. It mentions some techniques used by common p2p applications such as skype (knowledge of skype's protocol is limited since it is proprietary), gtalk as well as other XMPP based chat applications.
I want to make a solution where I can use XMPP chat clients connected to gtalk, resolving SOAP web services and REST calls meant for a LAN (behind firewall proxy etc) and transferring over to the other chat client on another different LAN (behind other firewall proxy etc).
I have narrowed down on Smack API, but being a newbie in XMPP and smack, I don't know if is it possible or not with Smack?
Does smack provide for such a functionality? I tried Smack documentation but couldn't understand it in enough depth.
Any other possible alternatives, suggestions too are most welcome.
Start with XEP-72 for a hint at the style of protocol you should use. There are some good reasons to do this, including:
Firewall traversal (as noted)
Don't have to do a TCP connection as often, saving latency
Don't have to authenticate for each request, but can authenticate the stream
No need for a separate XML parser for each request, which means processing can be more efficient
To make things easier start with http://xmpp.org/extensions/xep-0050.html and use command's node attribute in a restfull way
Ok I tried going to jabbers site, and it looks like cisco has acquired them.
Is jabber a server or a client? is it open source?
From what I guess, the steps are:
install the jabber server on your server
for a web application, creating a interface that will insert/select messages from the jabber server. I'm guessing communication will be in some xml format?
Jabber is the same thing as XMPP. The canonical place to find out about jabber is www.xmpp.org. They host all the documentation about the protocol. If you just want to use it, jabber.org hosts a free jabber server you can connect to, and is a great place to try it out. Psi (psi-im.org) is a good free client to try out the system.
The jabber protocol is a bit like smtp for instant messaging (IM). Servers federate (talk to each other) and the protocol is plain text, and defined in several RFCs. There are both client and server pieces of the protocol.
As you discovered, jabber.com (Jabber, Inc) was purchsed by Cisco. Jabber, Inc sold a proprietary jabber server (XCP) with great scalability that used the defined RFC protocols. There are several other servers out there, some free, some not. They all can communicate, which is the cool thing. Or not communicate, which is also cool.
I recommend trying out jabber clients, finding an active chat room (called MUC, multi user chat) and see where that takes you. If you're a developer you can use XMPP for any presence enabled thing. It's very extensible.
Oh, if you've used gtalk, you've used jabber. It's popular, open, and not tied to any one particular company.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
If I have a separate system with its own concept of users and presence, what is the most appropriate architecture for creating a bridge to an XMPP server network? As far as I can tell there are three primary ways:
Act as a server. This creates one touchpoint, but I fear it has implications for compatibility, and potentially creates complexity in my system for emulating a server.
Act as a clients. This seems to imply that I need one connection per user in my system, which just isn't going to scale well.
I've heard of an XMPP gateway protocol, but it's unclear if this is any better than the client solution. I also can't tell if this is standard or not.
Any suggestions or tradeoffs would be appreciated. For example, would any of these solutions require running code inside the target XMPP server (not likely something I can do).
The XMPP gateway protocol you've heard of is most likely to do with transports. A transport is a server that connects to both a XMPP server and a non-XMPP server. By running a transport, I can use my Jabber client to talk to someone using, say, MSN Messenger.
A transport typically connects once to the remote network for each JID that it sees as online. That is, it's your option 2 in reverse. This is because there is no special relationship between the transport and the non-XMPP network; the transport is simply acting as a bunch of regular clients. For this to work, XMPP clients must first register with the transport, giving login credentials for the remote network, and allowing the transport to view their presence.
The only reason this has a chance of scaling better is that there can be many transports for the same remote network. For example, my Jabber server could run a transport to MSN, another Jabber server could run another one, and so on, each one providing connections for a different subset of XMPP users. While this spreads out the load on the Jabber side, and load balancing on your system may spread out the load as well, it still requires many connections between the two systems.
In your case, because (I assume) the non-XMPP side of things is cooperating, putting a XMPP server interface on the non-XMPP server is likely your best bet. That server interface is best suited for managing the mapping between XMPP JIDs and how that JID will appear on its own network, rather than forcing XMPP users to register and so on.
In case you haven't seen these, you might find them useful:
http://www.jabber.org/jabber-for-geeks/technology-overview
http://www.xmpp.org/protocols/
http://www.xmpp.org/extensions/
Hope that helps.
I too am working on a similar system.
I am going with the gateway/component route. I have looked at several options and settled with this one.
The gateway is basically a component with the specific purpose of bridging Jabber/XMPP with another network. You will have to build most of the things you take for granted when using XMPP as a client. Stuff like roster control.
There is very little help online on the actual design and building of a component. Like the above answer I found that the xmpp protocols/extensions to be of help. The main ones being:
Basic Client 2008
Basic Server 2008
Intermediate Client 2008
Intermediate Server 2008
Reading through these will show you what XEPs you will be expected to be able to handle. Ignore the stuff that will be handled by the server that your component will be attched to.
It's a shame that Djabberd has such poor documentation as their system of "everything is a module" gave the possibility of backend of the server could interface directly to the other network. I made no headway on this.
There are basically two types of server to server (s2s) connections. The first is either called a gateway or a transport, but they're the same thing. This is probably the kind you're looking for. I couldn't find specific documentation for the non-XMPP side, but how XMPP thinks about doing translations to legacy servers is at http://xmpp.org/extensions/xep-0100.html. The second kind really isn't explained in any additional XEPs -- it's regular XMPP s2s connections. Look for "Server-to-Server Communication" in RFC 3920 or RFC 3920bis for the latest draft update.
Since you have your own users and presence on your server, and it's not XMPP, the concepts aren't going to map completely to the XMPP model. This is where the work of the transport comes in. You have to do the translation from your model to the XMPP model. While this is some work, you do get to make all the decisions.
Which brings us right to one of the key design choices -- you need to really decide which things you are going to map to XMPP from your service and what you aren't. These feature and use case descriptions will drive the overall structure. For example, is this like a transport to talk to AOL or MSN chat services? Then you'll need a way to map their equivalent of rosters, presence, and keep session information along with logins and passwords from your local users to the remote server. This is because your transport will need to pretend to be those users and will need to login for them.
Or, maybe you're just an s2s bridge to someone else's XMPP based chess game, so you don't need a login on the remote server, and can just act similarly to an email server and pass the information back and forth. (With normal s2s connections the only session that would be stored would be SASL authentication used with the remote server, but at the user level s2s just maintains the connection, and not the login session.)
Other factors are scalability and modularity on your end. You nailed some of the scalability concerns. Take a look at putting in multiple transports to balance the load. For modularity, see where you want to make decisions about what to do with each packet or action. For example, how do you handle and keep track of subscription data? You can put it on your transport, but then that makes using multiple transports harder. Or if you make that decision closer to your core server you can have simpler transports and use some common code if you need to talk to services other than XMPP. The trade off is a more complex core server with more vulnerability potential.
What architecture you should use depends on the non-XMPP system.
Do you operate the non-XMPP system? If yes, you should find a way to add an XMPP-S2S interface to that system, in other words, make it act as an XMPP server. AOL is using this approach for AIM. Unfortunately, they have restricted their gateway to GoogleTalk.
You don't operate the non-XMPP system but it has a federation interface that you can use - i. e. your gateway can talk to the other system as a server and has a namespace of its own. In this case, you can build a gateway that acts as a federated server on both sides. For I don't know of any example of a gateway that uses this approach but you could use it if you want to build a public XMPP-to-SIP bridge.
If the non-XMPP system doesn't give you a federation interface, then you have no other option but acting as a bunch of clients. In the XMPP world, this is called a "transport". The differences between a transport and a normal server are basically:
the JIDs of the transport are mapped from another system (e.g. john.doe\40example.net#msngateway.example.org - really ugly!)
XMPP users who want to use the transport need to create an account on the non-XMPP system and give the login credentials of that account to the transport service. The XMPP protocol even has a protocol extension that allows XMPP users to do transport registrations in-band.
One other approach is to work with your XMPP server vendor. Most have internal APIs that make injecting presence possible from third party applications. For example, Jabber XCP provides an API for this that's really easy to use.
(Disclosure: I work for Jabber, Inc, the company behind Jabber XCP)