It's not that I normally lie in bed worrying about presence leaks,
but as it happens, there's been much mention of presence leakage
recently, and I agree it's a fairly important issue. Aside from
anything else, if presence leaks badly enough, it can leave a nasty
stain on the carpet.
I'd like to open a discussion on this, because I'm pretty sure that I
don't know all the ways that presence can be leaked, and I'm not
convinced that we know good ways to avoid it, yet.
I'd also like to focus on non-random resources.
This is for two reasons. First, solving this case also solves the
random-resource-name case, especially important in those
circumstances where random turns out to be "utterly predictable".
Second, even if you do have a random resource, there are lots of
cases whereby we disclose it quite intentionally, such as joining a
chatroom, or engaging in transient conversation, etc. Such disclosure
does not apply for the entire session, or at least should not - we
assume sessions to be long-lived, in some cases very long lived.
So whilst I understand that random resource names are a form of
defense against presence leaks, I'd like to consider other methods of
avoiding these leaks.
My goal would be a document that describes best practises for both
server and client developers to avoid disclosure of the existence of
a client connection without the user's intent.
In as much as I can determine, presence leak happens when a stanza
generates different behaviour depending on whether the user is online
or not. There seem to be two broad divisions of presence leak.
I see four cases:
a) Attacker knows bare jid, and can determine that one or more full
jids is online.
I note that servers which don't implement offline messaging would
typically bounce messages received when the user is offline with
<service-unavailable/>, whereas no error would be forthcoming from an
online, but silent, user.
Mitigation for this might be that unless the user has sent presence
(directed or otherwise) to the sender, the message should be bounced
anyway. (It being a relatively simple situation to sort out between
humans, who can simply say "No, it's okay, I got that").
The alternative is that messages sent to offline users (or resources,
see below) do not emit errors at all.
b) Attacker knows bare jid, and can discover a full jid that is
online.
I don't know any cases of this. Anyone else?
c) Attacker knows full jid, and can determine if it is online.
In principle, this is the simplest case. Aside from the above
<message/> attack - messages to offline full jids are processed just
like those to bare jids - there is also the <iq/> case - send an
<iq/> and you will receive either a result (user online), or an
error, and by sending the same <iq/> to the server, one might
distinguish between online and offline.
The solution to the <iq/> case would seem to be best handled by the
client issuing an error, which is intercepted by its server and
essentially rewritten. I note that given that the initial request may
or may not be included, neither server or client should include it to
avoid distinction. (Since otherwise, if the server habitually
includes the original request, but the client does not, then the
server is unlikely to remember what it was).
d) Attacker knows full jid, knows that it is now online, and can
detirmine that it has been online at a point in the past.
Complicated point, so let's assume that you talk to someone, then -
perhaps much later - enter a non-anonymous chatroom, which the
attacker is also present in. The question is, can the attacker derive
knowledge about whether you've been online the whole time?
I see this as being entirely possible, and in fact unavoidable, with
server-assigned resources. Otherwise I don't see that it helps - if
I'm always [EMAIL PROTECTED]/Home, then the attacker cannot tell
if I've been offline.
So, am I missing any cases, or possible attacks?
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
