[Juser] [cryptography] Preventing Timing Correlation Attacks on XMPP chats?
rdohm321 at gmail.com
Sun Jan 5 12:23:45 UTC 2014
- a "scrambler" could send out from time to time fake messages.
- an "impersonator" could record your own chat behaviour and generate
random time and lenght and content data, so it looks like your own chat
- the main problem remains that from an external analysis you can always
see, that User A is sending (a messge) to User B. This can only be solved
with sending the Message (originally addressed to A) to all connected
people, so as well to B, C, D, E and F. A kind of "echo" would solve this.
EMPP (library: http://spot-on.sf.net, echoed message and presence protocol)
has this all and XMPP could benefit from it or - as some discuss - why not
merge EMPP and XMPP or even send echo over an xmpp acccount? Would a XMPP
connection allow a selfsigned SSL connection over/through it ?
I still wounder, why XMPP is not adding end-to-end encryption and it must
be done over a plugin (OTR).
D/H key exchange / TLS can be attacked by a man in the middle, especially
if you use :
User A -> TLS -> Own Webserver <- MITM / - Maybe: TLS - <- Own
Webserver <- TLS <- User B
User A does not know, if the cert between two Webservers is compromised. Or
elsewhere in the chain. Only End to End proves, that you have full
continuity in your TLS chains. And: Is a D/H key exchange for OTR secure
over a broken TLS?
But: The problem is not securing xmpp, the problem with XMPP is, that you
easily know, who is talking with whoom. This makes no sense to think about
adding a scrambler to it, especially if you are not interested in the
content, but in the social network one maintains.
>From the kids on the block perspective, XMPP is the glorification of open
source. Nothing else has to be there. But is this a differentiating view?
Form the developer side there are different views:
If adding fancy helper tools like encryption or scramblers makes this more
Some Dinos have still homework to do and must be regarded outdated until
not a native (and not only plugged) end to end encryption is in.
This is not liked, we know, but us as XMPP server admins need to be taken
away the possibility to read plaintext. And this is a
transformation we after occurances of the last year have to bear.
Jabber Servers without Plaintext is the Vision of 2014. And this becomes
real Feb. 22 ?
2014/1/5 Fabio Pietrosanti (naif) <lists at infosecurity.ch>
> XMPP networks are now going to be default secured with TLS in their
> client-to-server and server-to-server communications by 22th Feb.
> Most IM client support end-to-end encryption with OTR by default.
> The "Federated Architecture" make it very scalable and distributed.
> With all that "goods of COMSEC" in place, we are missing a timing
> correlation protection schema for XMPP traffic, to avoid an adversary
> "monitoring your internet communication line" to know "when" you have
> written something.
> POND is a super technology to prevent timing correlation attacks
> (https://pond.imperialviolet.org/tech.html), unfortunately it's a closed
> network so i don't think it would ever get diffused (it's also written
> in GO and my religion does not let me use anything written in GO).
> So i've been thinking that we need "a method" to achieve protection
> against time traffic correlation attacks on XMPP chat.
> It's possible that, by having a traffic-generator-robot (behaving like
> an XMPP buddy you connect to), and an XMPP client plug-in it would be
> possible to create some kind of "constant traffic timing pattern" to
> avoid an adversary being able to make timing correlation attacks.
> Something like that would be "relatively easy" to be implemented.
> This would bring "timing correlation attack protection" to the already
> existing security stack of XMPP:
> - Client TLS encrypted login
> - Server-to-Server TLS encrypted communication
> - end-to-end encrypted communication with OTR
> - Federated architecture
> Fabio Pietrosanti (naif)
> HERMES - Center for Transparency and Digital Human Rights
> http://logioshermes.org - http://globaleaks.org - http://tor2web.org
> cryptography mailing list
> cryptography at randombit.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the JUser