Protocol obfuscation

From EMule Wiki
(Difference between revisions)
Jump to: navigation, search
(Technical implementation)
Line 17: Line 17:
  
 
== 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 29: Line 28:
 
                 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 36: Line 35:
 
                 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 52: Line 51:
 
               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 63: Line 62:
 
                 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 74: Line 73:
 
     - 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 90: Line 89:
 
                 <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 throttling bittorrent isp]]
 
*[[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 of emule docs]]

Revision as of 12:30, 26 March 2007

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.

  • 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.

However, by encrypting the eMule protocol, the provider cannot detect eMule easy and might allow more bandwidth to be used by encrypted traffic.

  • Encryption (obfuscation) is only possible if both sides use encryption.
  • It only protects (limited) against man-in-the-middle attacks.
  • It does not increase your privacy since your data is still visible to other eMule clients that use the same encryption.

[image:howtoenableobfuscation.png]

Contents

neomule

Neomule supported a different kind of obfuscation before official supported obfuscation. THis has become mostly obsolete since official emule supportes it.


Technical implementation

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

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

see also

Personal tools