Thanks Mathew, I will take your comments on board.
I'm currently reading about remote service dialback. I think Openfire allows for it to happen over TLS. Thanks for letting me know about Prosody. Have a safe trip, Paddy. On Tue, Jun 15, 2010 at 11:13 AM, Matthew Wild <[email protected]> wrote: > On 15 June 2010 10:49, paddy joesoap <[email protected]> wrote: >> Hi Paul, >> >> Thanks for responding. >> >> If I understand both Matthew and yourself correctly, XMPP servers and >> client interactions are all TLS/SSL based (or should be) and thus deep >> packet inspection would need to be handled either at the application >> layer either by the XMPP server or perhaps some other form of XML >> based inspection. >> > > Correct. > >> Have you any opinions on how such XMPP servers are deployed in >> practice? What I mean is that, is TLS used all the time. I presume >> there are legacy systems that don't benefit from the SASL options and >> TLS, that if combined with a firewall would mimic such advanced >> features. I see from the Openfire administration page that c2s can be >> either encrypted or plain-text over port 5222. The s2s communication >> is over port 5269. I am not sure if s2s MUST be encrypted. >> > > It's not required to use it (yet?) but support for TLS is required. In > fact most servers will probably let you turn it off entirely. However > for the reasons of relying on DNS I mentioned earlier, that's the > wrong direction you'd be going in. Personally I'd rather TLS with > verified identity than no TLS and the ability to inspect packets > before they reached the XMPP server. > >> Consider a enterprise scenario where remote communication to an XMPP >> server either c2s or s2s is over a VPN. In this case, one may not want >> to consider a hardened XMPP server that uses TLS (but may use in >> conjunction to the firewall a whitelist). In this case, a firewall >> could inspect the XMPP stanza's. For example, find the string that >> matches a certain JID or a known malware signature. >> > > Sure, if there's no TLS this is possible. > >> Presumably if the solution is TLS end-to-end then one could argue that >> a firewall is not required except to prevent DoS and protect other >> services hosted on the XMPP server that cannot protect themselves. > > I think I'd argue that, yes. > >> However, I presume there is a management issue with handling the >> TLS-based certificates each time you create a new XMPP service and/or >> connect to another XMPP server. >> > > Yes, which is probably one reason TLS with real certificates isn't as > common as we want it to be. Discussions are often happening about how > we can achieve security in spite of this, or how we can aid adoption. > I suspect that simply once spam and rogue servers start appearing, a > few services will start to require verified certificates before > allowing an s2s connection with a peer. > > The situation for clients doesn't look so positive... requiring > everyday users to get their own certificates would be asking for quite > a lot :) > >> Also, what happens in the case of some malicious Web URL that is doing >> the rounds that may be contained within IM messages. While a firewall >> can act as a single chokepoint and thus a single point of management, >> I presume that each XMPP service would require individual management >> to filter the malicious URL from XMPP stanza's. >> > > Afraid so. > >> There is also the situation where some enterprise environments want to >> be able to filter all packets on its local subnet at least, either by >> firewall, IDS, network-based anti-virus and so forth. In these >> situations, would XMPP still operate over TLS pipes? What happens in >> your experience in practice? >> > > I've yet to know of anyone who rathered external filtering than TLS, > but it's early days perhaps. As an example Google are probably (one > of?) the largest XMPP deployments... they use TLS for clients quite > happily (require it in fact if I recall). They used to use TLS for s2s > as well, but don't at the moment (I don't think for reasons of > filtering) but I believe they are working on bringing it back. > >> I notice when I look at the Openfire administration GUI that there is >> an option for file transfer proxy over port 7777. I presume such >> traffic is unencrypted. My understanding is this proxy is used as a >> sort of relay/router between two clients, because the XMPP stanz'a are >> intended for small payloads. A firewall could inspect traffic over >> port 7777 to ensure no sensitive data is being leaked. Again, this >> out-of-band communication is not specific to XMPP (but does use the >> XMPP server in this case). >> > > Yes, that's correct. The proxy can be used to set up a (bidirectional > in fact) pipe between two XMPP entities. Usually this is for > transferring files, and there is no standard on encrypting file > transfers (though there is nothing to stop clients doing this). > >> Regardless of encrypted layer-7, there are some synergies between XMPP >> and iptables firewall when providing security in-depth. >> 1) XMPP IP address whilelist, firewall source IP address filtering > > I'd be surprised if there aren't any XMPP servers that can already do > this, but yet I'd agree it's a job best done by the firewall. > >> 2) XMPP requires certain ports to be open, firewall open required >> ports for required protocols (application alignment with >> infrastructure) > > Yes, external firewall. > >> 3) XMPP does not perform DoS filtering, firewall filters connection rates > > XMPP servers actually do allow for these kind of things. For example: > http://xmpp.org/extensions/xep-0205.html > >> 4) XMPP does not perform IP address anti-spoofing, firewall >> prevents/reduces anti-spoofing attempts. > > For s2s connections (clients already authenticate with credentials, so > it's not as much of an issue) XMPP uses dialback to prevent spoofing: > http://xmpp.org/extensions/xep-0220.html > > Obviously as I noted before, this is dependent on DNS being correct. > Anything you can deploy externally would help make the dialback checks > more secure. > >> 5) XMPP SPIM protection??, if traffic is unencrypted the firewall (or >> IDS) can detect malformed traffic and known SPIM signatures. >> > > SPIM isn't really a problem at the moment, but we know the day will > come. In fact there are a couple of specifications on suggested ways > to help tackle it: http://xmpp.org/extensions/xep-0268.html and > http://xmpp.org/extensions/xep-0275.html > > Both are wanting implementations and experience so they can be > developed further and out of experimental stage. > >> Note, I searched for an Anti-SPIM plugin for Openfire and could not >> find any. What flavour XMPP servers are you using? >> > > I use (and develop) Prosody. I should probably mention that I've been > working on something the past few weeks that might interest you - it's > essentially a Prosody module that handles most of what we've been > discussing. The best way to describe it is probably "iptables for > XMPP", as it lets you define custom rules for handling/routing > stanzas, based on their header, contents, origin and other things. I'm > away this week, but was planning to release it next week when I get > back. > > Matthew >
