• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!
  • 2026 staff recruitment is open! Check it out and consider applying!

TFS vulnerable to CRIME exploit?

Source

Veteran OT User
Joined
May 31, 2020
Messages
295
Reaction score
478
Location
OpenTibia .dev
GitHub
source61
I'd make an issue on github instead, but I've heard TFS on github is toxic, and I'd probably not be welcomed, so I'd rather not get involved there.
Of course OTLand is too, but I don't care because it doesn't affect my github account.

To the topic:
I just "heard about"/looked up myself that TFS has packet compression now, after I had a talk with the developer behind Rust OT/RyOT where he uses compression, and I looked it up to consider using compression myself.

However from my understanding compression + encryption is inherently insecure and vulnerable to CRIME, which is an old well known exploit now, so probably easy to pull off, allowing people to eavesdrop on the client-server communications, defeating the purpose of XTEA.

Thoughts?
 
I may be wrong, but CRIME works when the secret and the attacker's data are compressed together in one context.
This is not the case in TFS, so this particular attack does not apply.
 
Thoughts?
Tibia sends XTEA key (secret) in first packet. It's RSA encrypted 16 random bytes generated by client. It's RSA encrypted before compression - if compression works on first packet, probably not -, so attack that bases on 'compress -> encrypt' size change can't be used to get secret.
To eavesdrop OTS communication you must brute force 1024-bit RSA key (just once) or 128-bit XTEA key (for every player connection, as it's random for each connection).
CRIME targets HTTP protocol, as it sends 'cookies' (secret) in every request ('packet' from client to server in case of Tibia).
 
Tibia sends XTEA key (secret) in first packet. It's RSA encrypted 16 random bytes generated by client. It's RSA encrypted before compression - if compression works on first packet, probably not -, so attack that bases on 'compress -> encrypt' size change can't be used to get secret.
Ok, if it compresses after, then I agree it's fine. But this must also apply to XTEA packets for it to be safe to my understanding (encryption, then decompression).
I'm not a security expert and don't pretend to be, that's just my current understanding.

And yes while CRIME/BREACH only targets the HTTP(S) protocols, that doesn't mean other protocols are not vulnerable - it's the same principle, we don't do session hijacking here, but eavesdropping is apparently still possible through more broad and well known attacks like CPA-2, SCA and LOA.

To eavesdrop OTS communication you must brute force 1024-bit RSA key (just once) or 128-bit XTEA key (for every player connection, as it's random for each connection).
I don't know where you get any of this from, sounds like you're just using the process of elimination on insufficient and incomplete data.
 
Back
Top