You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, running a ReQrypt server requires support for IP spoofing, which is disallowed by most networks due to the potential for abuse. This makes it difficult to set up new ReQrypt servers to help support the network. As such, ReQrypt is vulnerable to ISPs simply blocking traffic to the (currently single) server (#13).
One solution might be to support "tunnel forwarding", where a server acts as a front for another server, as illustrated below:
+-----------+
+---------------| WEB |-------------+
| | SERVER | |
| +-----------+ |
| |
V |
+-----------+ +-----------+ +----------+
| PC |------->| SERVER' |------->| SERVER |
| a.b.c.d |<-------| p.q.r.s |<-------| x.y.z.w |
+-----------+ +-----------+ +----------+
Under this idea, the user connects to the main ReQrypt server (SERVER) by tunneling through another server (SERVER'). Control messages (from SERVER to PC) are also sent via SERVER', meaning that there is no direct communication with the main server (SERVER).
This has some big advantages:
To the end user, SERVER' behaves just like a regular ReQrypt server, so no change to the user experience.
SERVER' does not need to support IP spoofing, making it easier to set up "new" servers. Thus if an ISP blocks SERVER' then it is easy to set up SERVER'', etc., making it much easier to support a larger network and play cat-and-mouse games.
The ISP does not see any traffic to the main server (SERVER), so cannot block it.
The main disadvantage is a performance reduction due to extra hops. But this should be minimal if both SERVER and SERVER' are geographically close together.
Implementing this would also require a bit of work.
The text was updated successfully, but these errors were encountered:
Actually when I was thinking about such system before I discovered ReQrypt, I was thinking to set spoofing server on Tor (as a hidden service), and bundle client software with Tor compiled in zero-hop mode (tor2web). This drastically complicate discovery of server's IP address while still maintain sane speed.
Currently, running a ReQrypt server requires support for IP spoofing, which is disallowed by most networks due to the potential for abuse. This makes it difficult to set up new ReQrypt servers to help support the network. As such, ReQrypt is vulnerable to ISPs simply blocking traffic to the (currently single) server (#13).
One solution might be to support "tunnel forwarding", where a server acts as a front for another server, as illustrated below:
Under this idea, the user connects to the main ReQrypt server (
SERVER
) by tunneling through another server (SERVER'
). Control messages (fromSERVER
toPC
) are also sent viaSERVER'
, meaning that there is no direct communication with the main server (SERVER
).This has some big advantages:
SERVER'
behaves just like a regular ReQrypt server, so no change to the user experience.SERVER'
does not need to support IP spoofing, making it easier to set up "new" servers. Thus if an ISP blocksSERVER'
then it is easy to set upSERVER''
, etc., making it much easier to support a larger network and play cat-and-mouse games.SERVER
), so cannot block it.The main disadvantage is a performance reduction due to extra hops. But this should be minimal if both
SERVER
andSERVER'
are geographically close together.Implementing this would also require a bit of work.
The text was updated successfully, but these errors were encountered: