Protocol obfuscation

From EMule Wiki
(Difference between revisions)
Jump to: navigation, search
(created)
 
(Undo revision 3007 by Izegiwera (Talk))
 
(13 intermediate revisions by 7 users not shown)
Line 1: Line 1:
Some providers are throttling eMule traffic (decreasing the allowed bandwidth). They do this by detecting the eMule protocol and allowing a very limited amount of the total bandwidth to be used by eMule. The best reaction against this is to change ISP.
+
Some providers are throttling eMule traffic (decreasing the allowed bandwidth). They do this by detecting the eMule protocol and allowing a very limited amount of the total bandwidth to be used by eMule. Obfuscation makes it harder to identify the eMule protocol.
  
* Before you are changing your ISP, please verify on the eMule under Options-> Security-> Protocol Obfuscation, that Enable Protocol Obfusaction is checked, otherwise you are unable to work with the Protocol Obfusaction on eMule.
+
== Settings ==
  
However, by encrypting the eMule protocol, the provider cannot detect eMule easy and might allow more bandwidth to be used by encrypted traffic.
+
http://wiki.emule-web.de/image/howtoenableobfuscation.png
  
* Encryption (obfuscation) is only possible if both sides use encryption.
+
*Enable Protocol Obfuscation: Ask other clients to use obfuscated communications.
* It only protects (limited) against man-in-the-middle attacks.
+
*Allow obfuscated connections only: If the other client doesn't understand obfuscation, any communication with it gets canceled. Use this setting only in extreme situations!
* It does not increase your privacy since your data is still visible to other eMule clients that use the same encryption.
+
*Disable support for obfuscated connections: The client behaves like it would be an older version which doesn't understand obfuscation.
  
=== neomule ===
+
== Limitations ==
  
Neomule supported a different kind of obfuscation before official supported obfuscation. THis has become mostly obsolete since official emule supportes it.
+
* Obfuscation only works if both sides of the transfer support it. If one side doesn't support it, the communication is done the "old" way, unless this is disabled (see ''Settings'' section).
 +
* Obfuscation is not perfect, it is still possible to detect the eMule protocol.
 +
* Obfuscation does not increase anonymity or hide which files are shared.
 +
* If the provider doesn't try to detect the eMule protocol but rather blocks/limits every user which uses lots of bandwidth, obfuscation can't help at all.
 +
 
 +
== Earlier version ==
 +
 
 +
Neomule supported a different kind of obfuscation before official supported obfuscation. This has become mostly obsolete since the official client supports it.
  
  
 
== Technical implementation ==
 
== Technical implementation ==
<verse>
+
===Encrypted UDP===
encrypted UDP
+
  
 
   Basic Obfusicated Handshake Protocol UDP:
 
   Basic Obfusicated Handshake Protocol UDP:
 
     see EncryptedStreamSocket.h
 
     see EncryptedStreamSocket.h
 
+
  :
 
     -Keycreation Client <-> Client:
 
     -Keycreation Client <-> Client:
 
     - Client A (Outgoing connection):
 
     - Client A (Outgoing connection):
Line 27: Line 33:
 
                 Receivekey: Md5(<UserHashClientB 16><IPClientA 4><MagicValue91 1><RandomKeyPartClientA 2>)  23
 
                 Receivekey: Md5(<UserHashClientB 16><IPClientA 4><MagicValue91 1><RandomKeyPartClientA 2>)  23
 
     - Note: The first 1024 Bytes will be _NOT_ discarded for UDP keys to save CPU time
 
     - Note: The first 1024 Bytes will be _NOT_ discarded for UDP keys to save CPU time
 
+
  :
 
     -Keycreation Client <-> Server:
 
     -Keycreation Client <-> Server:
 
     - Client A (Outgoing connection client -> server):
 
     - Client A (Outgoing connection client -> server):
Line 34: Line 40:
 
                 Receivekey: Md5(<BaseKey 4><MagicValueServerClient 1><RandomKeyPartClientA 2>)  7
 
                 Receivekey: Md5(<BaseKey 4><MagicValueServerClient 1><RandomKeyPartClientA 2>)  7
 
     - Note: The first 1024 Bytes will be _NOT_ discarded for UDP keys to save CPU time
 
     - Note: The first 1024 Bytes will be _NOT_ discarded for UDP keys to save CPU time
 
+
:
 
     - Handshake
 
     - Handshake
 
             -> The handshake is encrypted - except otherwise noted - by the Keys created above
 
             -> The handshake is encrypted - except otherwise noted - by the Keys created above
 
             -> Padding is cucrently not used for UDP meaning that PaddingLen will be 0, using PaddingLens up to 16 Bytes is acceptable however
 
             -> Padding is cucrently not used for UDP meaning that PaddingLen will be 0, using PaddingLens up to 16 Bytes is acceptable however
 
         Client A: <SemiRandomNotProtocolMarker 1[Unencrypted]><RandomKeyPart 2[Unencrypted]><MagicValue 4><PaddingLen 1><RandomBytes PaddingLen%16>     
 
         Client A: <SemiRandomNotProtocolMarker 1[Unencrypted]><RandomKeyPart 2[Unencrypted]><MagicValue 4><PaddingLen 1><RandomBytes PaddingLen%16>     
 
+
:
 
     - Overhead: 8 Bytes per UDP Packet
 
     - Overhead: 8 Bytes per UDP Packet
   
+
 
     - Security for Basic Obfuscation:
 
     - Security for Basic Obfuscation:
 
             - Random looking packets, very limited protection against passive eavesdropping single packets
 
             - Random looking packets, very limited protection against passive eavesdropping single packets
   
+
 
     - Additional Comments:
 
     - Additional Comments:
 
             - For obvious reasons the UDP handshake is actually no handshake. If a different Encryption method (or better a different Key) is to be used this has to be negotiated in a TCP connection
 
             - For obvious reasons the UDP handshake is actually no handshake. If a different Encryption method (or better a different Key) is to be used this has to be negotiated in a TCP connection
Line 50: Line 56:
 
               a lower CPU usage
 
               a lower CPU usage
  
Encrypted tcp
+
=== Encrypted TCP ===
  
 
  Basic Obfuscated Handshake Protocol Client <-> Client:
 
  Basic Obfuscated Handshake Protocol Client <-> Client:
Line 61: Line 67:
 
                 Receivekey: Md5(<UserHashClientB 16><MagicValue34 1><RandomKeyPartClientA 4>)  21
 
                 Receivekey: Md5(<UserHashClientB 16><MagicValue34 1><RandomKeyPartClientA 4>)  21
 
         NOTE: First 1024 Bytes are discarded
 
         NOTE: First 1024 Bytes are discarded
 
+
  :
 
     - Handshake
 
     - Handshake
 
             -> The handshake is encrypted - except otherwise noted - by the Keys created above
 
             -> The handshake is encrypted - except otherwise noted - by the Keys created above
Line 72: Line 78:
 
     - Security for Basic Obfusication:
 
     - Security for Basic Obfusication:
 
             - Random looking stream, very limited protection against passive eavesdropping single connections
 
             - Random looking stream, very limited protection against passive eavesdropping single connections
   
+
  : 
 
     - Additional Comments:
 
     - Additional Comments:
 
             - RandomKeyPart is needed to make multiple connections between two clients look different (but still random), since otherwise the same key
 
             - RandomKeyPart is needed to make multiple connections between two clients look different (but still random), since otherwise the same key
Line 88: Line 94:
 
                 <nowiki>Sendkey:    Md5(<S 96><MagicValue203 1>)  97</nowiki>
 
                 <nowiki>Sendkey:    Md5(<S 96><MagicValue203 1>)  97</nowiki>
 
                 <nowiki>Receivekey: Md5(<S 96><MagicValue34 1>) 97</nowiki>
 
                 <nowiki>Receivekey: Md5(<S 96><MagicValue34 1>) 97</nowiki>
   
+
  :   
 
     NOTE: First 1024 Bytes are discarded
 
     NOTE: First 1024 Bytes are discarded
 
+
  :
 
     - Handshake
 
     - Handshake
 
             -> The handshake is encrypted - except otherwise noted - by the Keys created above
 
             -> The handshake is encrypted - except otherwise noted - by the Keys created above
 
             -> Handshake is blocking - do not start sending an answer before the request is completly received (this includes the random bytes)
 
             -> Handshake is blocking - do not start sending an answer before the request is completly received (this includes the random bytes)
 
             -> EncryptionMethod = 0 is Obfusication and the only supported right now
 
             -> EncryptionMethod = 0 is Obfusication and the only supported right now
       
+
  :   
 
         Client: <SemiRandomNotProtocolMarker 1[Unencrypted]><G^A 96 [Unencrypted]><RandomBytes 0-15 [Unencrypted]>     
 
         Client: <SemiRandomNotProtocolMarker 1[Unencrypted]><G^A 96 [Unencrypted]><RandomBytes 0-15 [Unencrypted]>     
 
         Server: \<G^B 96 [Unencrypted]><MagicValue 4><EncryptionMethodsSupported 1><EncryptionMethodPreferred 1><PaddingLen 1><RandomBytes PaddingLen>
 
         Server: \<G^B 96 [Unencrypted]><MagicValue 4><EncryptionMethodsSupported 1><EncryptionMethodPreferred 1><PaddingLen 1><RandomBytes PaddingLen>
 
         Client: <MagicValue 4><EncryptionMethodsSelected 1><PaddingLen 1><RandomBytes PaddingLen> (Answer delayed till first payload to save a frame)
 
         Client: <MagicValue 4><EncryptionMethodsSelected 1><PaddingLen 1><RandomBytes PaddingLen> (Answer delayed till first payload to save a frame)
       
+
    :     
           
+
 
             -> The basic handshake is finished here, if an additional/different EncryptionMethod was selected it may continue negotiating details for this one
 
             -> The basic handshake is finished here, if an additional/different EncryptionMethod was selected it may continue negotiating details for this one
 
+
  :
 
     - Overhead: 206-251 (~229) Bytes + 2 * IP/TCP Headers Headers per Connectionon
 
     - Overhead: 206-251 (~229) Bytes + 2 * IP/TCP Headers Headers per Connectionon
 
+
  :
 
     - DH Agreement Specifics: sizeof(a) and sizeof(b) = 128 Bits, g = 2, p = dh768_p (see below), sizeof p, s, etc. = 768 bits
 
     - DH Agreement Specifics: sizeof(a) and sizeof(b) = 128 Bits, g = 2, p = dh768_p (see below), sizeof p, s, etc. = 768 bits
</verse>
+
 
== see also ==
+
== See also ==
*[[http://www.azureuswiki.com/index.php/Bad_ISPs List of throttling bittorrent isp]]
+
*[http://www.azureuswiki.com/index.php/Bad_ISPs List of providers which are throttling '''Bittorrent''']
*[[http://www.emule-project.net/home/perl/help.cgi?l=1&rm=show_topic&topic_id=848 Obfuscation of emule docs]]
+
*[http://www.emule-project.net/home/perl/help.cgi?l=1&rm=show_topic&topic_id=848 Obfuscation at the eMule docs]
 +
 
 +
 
 +
[[category:features]]

Latest revision as of 09:06, 24 November 2010

Some providers are throttling eMule traffic (decreasing the allowed bandwidth). They do this by detecting the eMule protocol and allowing a very limited amount of the total bandwidth to be used by eMule. Obfuscation makes it harder to identify the eMule protocol.

Contents

[edit] Settings

howtoenableobfuscation.png

  • Enable Protocol Obfuscation: Ask other clients to use obfuscated communications.
  • Allow obfuscated connections only: If the other client doesn't understand obfuscation, any communication with it gets canceled. Use this setting only in extreme situations!
  • Disable support for obfuscated connections: The client behaves like it would be an older version which doesn't understand obfuscation.

[edit] Limitations

  • Obfuscation only works if both sides of the transfer support it. If one side doesn't support it, the communication is done the "old" way, unless this is disabled (see Settings section).
  • Obfuscation is not perfect, it is still possible to detect the eMule protocol.
  • Obfuscation does not increase anonymity or hide which files are shared.
  • If the provider doesn't try to detect the eMule protocol but rather blocks/limits every user which uses lots of bandwidth, obfuscation can't help at all.

[edit] Earlier version

Neomule supported a different kind of obfuscation before official supported obfuscation. This has become mostly obsolete since the official client supports it.


[edit] Technical implementation

[edit] Encrypted UDP

 Basic Obfusicated Handshake Protocol UDP:
    see EncryptedStreamSocket.h
 :
   -Keycreation Client <-> Client:
    - Client A (Outgoing connection):
               Sendkey:    Md5(<UserHashClientB 16><IPClientA 4><MagicValue91 1><RandomKeyPartClientA 2>)  23
    - Client B (Incoming connection):
               Receivekey: Md5(<UserHashClientB 16><IPClientA 4><MagicValue91 1><RandomKeyPartClientA 2>)  23
    - Note: The first 1024 Bytes will be _NOT_ discarded for UDP keys to save CPU time
 :
   -Keycreation Client <-> Server:
    - Client A (Outgoing connection client -> server):
               Sendkey:    Md5(<BaseKey 4><MagicValueClientServer 1><RandomKeyPartClientA 2>)  7
    - Client B (Incoming connection):
               Receivekey: Md5(<BaseKey 4><MagicValueServerClient 1><RandomKeyPartClientA 2>)  7
    - Note: The first 1024 Bytes will be _NOT_ discarded for UDP keys to save CPU time
:
   - Handshake
           -> The handshake is encrypted - except otherwise noted - by the Keys created above
           -> Padding is cucrently not used for UDP meaning that PaddingLen will be 0, using PaddingLens up to 16 Bytes is acceptable however
       Client A: <SemiRandomNotProtocolMarker 1[Unencrypted]><RandomKeyPart 2[Unencrypted]><MagicValue 4><PaddingLen 1><RandomBytes PaddingLen%16>    
:
   - Overhead: 8 Bytes per UDP Packet
:   
   - Security for Basic Obfuscation:
           - Random looking packets, very limited protection against passive eavesdropping single packets
:   
   - Additional Comments:
           - For obvious reasons the UDP handshake is actually no handshake. If a different Encryption method (or better a different Key) is to be used this has to be negotiated in a TCP connection
           - SemiRandomNotProtocolMarker is a Byte which has a value unequal any Protocol header byte. This is a compromiss, turning in complete randomness (and nice design) but gaining
             a lower CPU usage

[edit] Encrypted TCP

Basic Obfuscated Handshake Protocol Client <-> Client:
   -Keycreation:
    - Client A (Outgoing connection):
               Sendkey:    Md5(<UserHashClientB 16><MagicValue34 1><RandomKeyPartClientA 4>)  21
               Receivekey: Md5(<UserHashClientB 16><MagicValue203 1><RandomKeyPartClientA 4>) 21
    - Client B (Incomming connection):
               Sendkey:    Md5(<UserHashClientB 16><MagicValue203 1><RandomKeyPartClientA 4>) 21
               Receivekey: Md5(<UserHashClientB 16><MagicValue34 1><RandomKeyPartClientA 4>)  21
       NOTE: First 1024 Bytes are discarded
 :
   - Handshake
           -> The handshake is encrypted - except otherwise noted - by the Keys created above
           -> Handshake is blocking - do not start sending an answer before the request is completly received (this includes the random bytes)
           -> EncryptionMethod = 0 is Obfusication and the only supported right now
       Client A: <SemiRandomNotProtocolMarker 1[Unencrypted]><RandomKeyPart 4[Unencrypted]><MagicValue 4><EncryptionMethodsSupported 1><EncryptionMethodPreferred 1><PaddingLen 1><RandomBytes PaddingLen%16>    
       Client B: <MagicValue 4><EncryptionMethodsSelected 1><PaddingLen 1><RandomBytes PaddingLen%16>
           -> The basic handshake is finished here, if an additional/different EncryptionMethod was selected it may continue negotiating details for this one
   - Overhead: 18-48 (~33) Bytes + 2 * IP/TCP Headers per Connection
   - Security for Basic Obfusication:
           - Random looking stream, very limited protection against passive eavesdropping single connections
 :  
   - Additional Comments:
           - RandomKeyPart is needed to make multiple connections between two clients look different (but still random), since otherwise the same key
             would be used and RC4 would create the same output. Since the key is a MD5 hash it doesnt weakens the key if that part is known
           - Why DH-KeyAgreement isn't used as basic obfusication key: It doesn't offers substantial more protection against passive connection based protocol identification, it has about 200 bytes more overhead,
             needs more CPU time, we cannot say if the received data is junk, unencrypted or part of the keyagreement before the handshake is finished without loosing the complete randomness,
             it doesn't offers substantial protection against eavesdropping without added authentification

Basic Obfuscated Handshake Protocol Client <-> Server:

   - RC4 Keycreation:
    - Client (Outgoing connection):
               Sendkey:    Md5(<S 96><MagicValue34 1>)  97
               Receivekey: Md5(<S 96><MagicValue203 1>) 97
    - Server (Incomming connection):
               Sendkey:    Md5(<S 96><MagicValue203 1>)  97
               Receivekey: Md5(<S 96><MagicValue34 1>) 97
 :    
    NOTE: First 1024 Bytes are discarded
 :
   - Handshake
           -> The handshake is encrypted - except otherwise noted - by the Keys created above
           -> Handshake is blocking - do not start sending an answer before the request is completly received (this includes the random bytes)
           -> EncryptionMethod = 0 is Obfusication and the only supported right now
  :     
       Client: <SemiRandomNotProtocolMarker 1[Unencrypted]><G^A 96 [Unencrypted]><RandomBytes 0-15 [Unencrypted]>    
       Server: \<G^B 96 [Unencrypted]><MagicValue 4><EncryptionMethodsSupported 1><EncryptionMethodPreferred 1><PaddingLen 1><RandomBytes PaddingLen>
       Client: <MagicValue 4><EncryptionMethodsSelected 1><PaddingLen 1><RandomBytes PaddingLen> (Answer delayed till first payload to save a frame)
   :       
           -> The basic handshake is finished here, if an additional/different EncryptionMethod was selected it may continue negotiating details for this one
 :
   - Overhead: 206-251 (~229) Bytes + 2 * IP/TCP Headers Headers per Connectionon
 :
   - DH Agreement Specifics: sizeof(a) and sizeof(b) = 128 Bits, g = 2, p = dh768_p (see below), sizeof p, s, etc. = 768 bits

[edit] See also

Personal tools