ReQrypt

ReQrypt is a tool for bypassing ISP-level censorship systems. ReQrypt is also an anti ISP-level traffic sniffing/logging tool.

ReQrypt:

• is free. ReQrypt is 100% open source and free.
• is fast. ReQrypt is based on one-way packet routing rather than proxy servers.
• keeps your IP address. ReQrypt does not use proxy servers and thus will never change your IP address.

ReQrypt works by rerouting web browser requests via encrypted tunnels. This hides web browser requests from any ISP-level censorship system.

Unlike proxy servers, VPN, Tor, etc., ReQrypt simply reroutes web browser requests without changing your IP address. Web pages are sent directly to your computer from the web server, and not through an encrypted tunnel. This means lower latencies and higher bandwidth compared to other technologies.

Simply:

1. Run the ReQrypt executable.
2. Check the "TUNNELS" tab to ensure that at least one tunnel is open.
3. Check the "OPTIONS" tab to tune ReQrypt to suit your needs.

To download and display a page, a web browser will open a TCP port 80 connection to a web server. It then sends a HTTP GET request to the web server, and the web server responds by sending a HTTP OK reply. The HTTP GET request contains the URL and the HTTP OK reply contains the web page.

The HTTP GET request is send upstream, and the HTTP OK reply is sent downstream. ReQrypt works by tunnelling upstream HTTP GET requests to a special server that forwards the request to the web server. ReQrypt does not tunnel the downstream replies, these are sent directly from the web server to your computer via the normal route.

This is an effective technology because most ISP-level censorship check upstream HTTP GET request only. These systems never check downstream replies. This is because only upstream requests contain the URL, and because upstream requests are generally smaller (think URL size vs. web page size.) It is generally infeasible to inspect all downstream web browser traffic at the ISP-level.

This is also the motivation behind ReQrypt. By only tunnelling upstream requests a single ReQrypt server can support significantly more users than a traditional proxy server with the same bandwidth constraints. The savings are then passed on to all ReQrypt users.

No. ReQrypt does not hide your IP address from web servers nor anybody inspecting downstream traffic.

If you desire anonymous browsing, then ReQrypt is not for you. For this we recommend using a proxy server, VPN, or Tor.

The HOME tab displays the client home page from the ReQrypt website. This page is periodically updated with the latest news, releases, and tunnel lists.

The log messages display what is going on. The types of log messages are:

• warnings indicate some kind of problem.
• errors indicate a serious problem that will cause ReQrypt to exit.
• packets indicate a tunneled packet.
• trace very verbose messages (debugging.)
• log Any other kind message.

This controls which kinds of messages are printed. The options are:

• All Messages: Prints every kind of message.
• Packets & Warnings: Prints every kind of message except trace messages.
• Warnings: Prints warning and error messages only.
• No Messages: Does not print any message.

This controls whether or not ReQrypt tunnels packets. The options are:

• Enabled: ReQrypt will tunnel packets
• Disabled: ReQrypt will not tunnel packets

When disabled, ReQrypt offers no protection against ISP-level censorship systems.

This decides which upstreams packets are tunneled. The options are:

1. Hide all HTTP traffic: Tunnels all upstream TCP port 80 (HTTP) packets.
2. Hide HTTP data traffic only: Tunnels all upstream TCP port 80 packets that contain data. TCP control packets such as SYNs, ACKs, etc., are not tunneled.
3. Hide HTTP URL traffic only: Like above, except will split upstream TCP port 80 packets into two parts. The first part containing the URL is tunneled, and the part containing non-URL data (e.g. other HTTP headers) is sent via the normal route.
4. Hide partial HTTP URL traffic only: Like above, except will split the URL itself into two parts. This means that only part of the URL is sent via the normal route.
5. Do not hide HTTP traffic: Do not tunnel any traffic.

NOTE: Whether or not an option is effective depends on the ISP-level censorship technology you wish to bypass. In a nutshell, the "Hide all HTTP traffic" is the most conservative mode that is most likely to work, but is the slowest because it tunnels the most packets. The "Hide partial HTTP URL traffic only" mode is the fastest but is only effective against inspection/logging systems, and some kinds of non-proxying censorship systems. It is recommended you use the least conservative mode that works.

This tunnels DNS requests in addition to HTTP requests. This may be useful against ISP-level censorship systems that use DNS Cache Poisoning. To use this option, you must first configure your operating system to use an external DNS server such as Google public DNS or OpenDNS. Do NOT use the DNS provided by your ISP. Once correctly configured:

• Enabled: Enables DNS request tunneling
• Disabled: Disables DNS request tunneling

Most home router/modems use Network Address Translation (NAT) to allow multiple computers to share a single broadband connection. Because ReQrypt tunnels TCP packets, a NAT traversal method is required. The options are:

• Never: Never use NAT traversal.
• Automatic: Use NAT traversal only if a NAT is detected. NAT detection works by checking whether your computer's IP address is private or public. A private address is assumed to indicate a NAT.
• Always: Always use NAT traversal.

There are two NAT traversal methods that are currently supported by ReQrypt. The methods are:

• Low time-to-live method: This method substitutes a "ghost" packet for every packet that is sent via the tunnel. The ghost packet is given a low time-to-live (TTL) value to ensure it reaches the NAT but never reaches the destination web server.
• Bad checksum method: This method substitutes a "ghost" packet with a bad TCP (or UDP) checksum. The ghost packet will reach the destination web server, however it will be dropped because of the invalid checksum.
• Combination method: This combines both the low TTL and bad checksum methods.

NOTE: Ghost packets carry randomized HTTP (or DNS) payloads. The tunneled payload is never revealed by a ghost packet.

NOTE: Only select the "Bad checksum method" if the "Low time-to-live method" does not work. The bad checksum method causes the web server to consume extra bandwidth.

NOTE: Some NAT implementations are incompatible with both traversal methods. In this case the only solution is to remove the NAT altogether.

If ReQrypt is using the "Low time-to-live method" or "Combination method" for NAT traversal, this option controls how many hops the ghost packets live for. In other words, this option sets the IPv4 time-to-live (TTL) value for ghost packets. This should be the number of hops to your NAT plus 1. For a typical home network configuration this value should be 2.

If ReQrypt is using the "Hide HTTP URL traffic only" or "Hide partial HTTP URL traffic only" methods, this option decides how the packet splitting is implemented. The options are:

• Network layer: Split packets at the network layer using IPv4 fragmentation.
• Transport layer: Split packets at the transport (TCP) layer.

NOTE: Splitting packets on the network layer is problematic. Some home routers attempt to reassemble fragmented packets which breaks packet splitting altogether. Splitting packets at the transport layer appears to work much better.

Each tunnel is represented by a URL. The URL tells ReQrypt how to connect to and use the tunnel. The URL syntax is:

    URL := TRANSPORT://HOST:PORT?ENCODINGS
   

• TRANSPORT: is the transport protocol used by the tunnel. Currently the supported transport protocols are:
  • udp: uses UDP transport
  • ip: uses RAW IP packets as transport
  • ping: uses ICMP echo request/reply as transport
• HOST: is either the host name or IP address of the server.
• PORT: is the port number associated with the TRANSPORT protocol. For ip tunnels the port number is the IP protocol number.
• ENCODINGS: specifies how the tunneled packets are encoded. The format for the ENCODINGS is

            ENCODINGS := ENCODING=OPTIONS+...+ENCODING=OPTIONS
            OPTIONS := OPTION.VALUE,...,OPTION.VALUE
           

  Currently the supported encodings are crypt and pad. Multiple encodings can be chained together using the + token. For such tunnels encodings are applied sequentially from the left-to-right.

    udp://reqrypt.org:58000?crypt=cipher.xxtea,cert.rQHEq2ky32DOaCopEMFVR0,sec.2888
    ip://tunnel2.reqrypt.org:99?pad=min.0,max.16
    udp://tunnel3.reqrypt.org:57000
    ip://tunnel.reqrypt.org:99?pad=min.0,max.32+crypt=cipher.xxtea,cert.rQHEq2ky32DOaCopEMFVR0
   

NOTE: Only tunnels that use the crypt encoding are encrypted. See below for more information.

The crypt encoding encrypts all tunneled packets. The options for the crypt encoding are:

• cert: The tunnel's certificate hash value. This is used to authenticate the server ReQrypt connects to.
• cipher: The cipher used for encryption. Currently supported ciphers are aes and xxtea (128-bit blocks).
• handshakepad: Adds randomized padding to crypt handshake packets to make traffic analysis more difficult.
• sec: The 4 digit security setting. The digits are:
  • Handshake asymmetric key size: 2 = 1024 bits.
  • Key ID size: 5-8 bytes.
  • Initialization Vector (IV) size: 4-8 bytes.
  • Message Authentication Code (MAC) size: 2-8 bytes.
  The minimum security setting is 2542, the maximum is 2888, and the default is 2653.

NOTE: The handshakepad option only applies to crypt handshake packets. To add padding to non-handshake packets use the pad encoding in addition to crypt.

The pad encoding adds randomized padding to the front of every tunnelled packet. The options are:

• min: The minimum pad size between 0-255 bytes. The default is 0.
• max: The maximum pad size between 0-255 bytes. The default is 16.
• size: Fixed size padding between 0-255 bytes.

NOTE: The pad encoding has two distinct modes. When min and/or max is specified, the length of the padding for each packet is randomly chosen from this range. When size is specified, the length of the padding is always fixed to the specified size. The size option is incompatible with min/max.

The set of "OPEN" tunnels are those that are currently available for tunneling packets. The set of "AVAILABLE" tunnels include all URLs that are known by the client, but are not necessarily open. You need at least one open tunnel for ReQrypt to work.

This allows you to add new tunnel URLs or to delete existing tunnels. Any added tunnel is immediately opened for use.