Difference between revisions of "Protocol Encryption"

From TMB Wiki
Jump to: navigation, search
(Protocol Exchange)
m
 
Line 5: Line 5:
 
<ul>
 
<ul>
 
<li>uTorrent
 
<li>uTorrent
−
<li>Azureus
 
−
<li>BitComet
 
−
<li>BitTornado
 
 
<li>rTorrent
 
<li>rTorrent
 
<li>kTorrent
 
<li>kTorrent
Line 31: Line 28:
  
 
It is '''not''' recommended to turn off "Allow legacy incoming connections", unless you cannot have any non-encrypted connections (typically in conjunction with Forced).
 
It is '''not''' recommended to turn off "Allow legacy incoming connections", unless you cannot have any non-encrypted connections (typically in conjunction with Forced).
−
 
−
==Azureus==
 
−
To enable the encryption you have to switch to intermediate user mode and go to ''Tools -> Options -> Connection -> Transport Encryption'' and enable the Require encrypted transport checkbox.
 
−
 
−
Enabling this feature instructs to establish connections with the crypto handshake, which will consume more CPU time due to the D-H key exchange. If it is disabled Azureus will only use the obfuscation header for peers that either require that via PEX/DHT or when a remote peer initiates a crypto connection.
 
−
 
−
Further details are controlled by the following settings:
 
−
 
−
<ul>
 
−
<li>'''Minimum encryption level'''
 
−
:This will specify the minimal encryption level you will choose when establish encrypted connections, currently available are
 
−
<ol>
 
−
<li>'''Plain:''' This only uses the obfuscation header and transmits the entire payload unencrypted. It's still easy to identify but might be enough to confuse simple traffic shapers
 
−
<li>'''RC4:''' This mode uses strong cryptography to obfuscate the traffic and is only attackable with very sophisticated and expensive attacks but it consumes more CPU time than the Plain method.
 
−
</ol>
 
−
 
−
<li>'''Allow non-encrypted outgoing connections if encrypted connection attempt fails:'''
 
−
:This option ensures compatibility with legacy clients that don't support the traffic obfuscation but makes it easier for the ISP to identify users that engage in BitTorrent activity.
 
−
 
−
<li>'''Allow non-encrypted incoming connections:'''
 
−
:Disabling this option will prevent any peer from connecting to you unless he uses the obfuscation header. Thus it even prevents peers from connecting to you when they support encryption but don't know that you require it. But as stated in the implementation specs, Azureus' PEX and Distributed tracker is obfuscation aware and thus tells other peers to use it even when they default encryption to off. Enabling this option may be necessary when the ISP limits ports instead of single connections.
 

Latest revision as of 20:42, 13 November 2017

Protocol Encryption (PE) is a joint specification between Azureus and µTorrent. It is designed to bypass throttling and/or blocking of BitTorrent traffic by an ISP. PE is not the same as PEX, which is Peer Exchange!

The following clients support PE

  • uTorrent
  • rTorrent
  • kTorrent
  • Mainline (Incoming only)


Instructions on configuring these clients to utilize PE can be found below.


Contents

uTorrent

You can choose Protocol Encryption's mode of operation in BitTorrent. Here is an explanation of the various options you can choose from:

  • Disabled: Does not encrypt outgoing connections, but will accept encrypted incoming connections.
  • Enabled: Attempts to encrypt outgoing connections, but will fall back to an unencrypted mode if the connection fails.
  • Force: Attempts to encrypt outgoing connections, and will NOT fall back to an unencrypted mode if the connection fails.
  • Allow legacy incoming connections enables or disables incoming legacy (non-encrypted) connections.

All modes will accept incoming encrypted connections (and the encryption is 2-way)!

It is not recommended to turn off "Allow legacy incoming connections", unless you cannot have any non-encrypted connections (typically in conjunction with Forced).

Retrieved from "https://wiki.themixingbowl.org/index.php?title=Protocol_Encryption&oldid=4559"