forked from Green-Sky/tomato
Green Sky
b2ae9530a4
f1df709b87 feat: add ngc events 1b6c907235 refactor: Make event dispatch ordered by receive time. b7f9367f6f test: Upgrade cppcheck, fix some warnings. 766e62bc89 chore: Use `pkg_search_module` directly in cmake. 00ff078f91 cleanup: Use target_link_libraries directly in cmake. c58928cc89 chore: Add `IMPORTED_TARGET` to pkg-config packages. 895a6af122 cleanup: Remove NaCl support. 41dfb1c1c0 fix: unpack enum function names in event impl generator 447666d1a1 chore: Disable targets for cross-compilation. 572924e924 chore: Build a docker image with coverage info in it. 415cb78f5e cleanup: Some portability/warning fixes for Windows builds. 425216d9ec fix: Correct a use-after-free and fix some memory leaks. 4b1cfa3e08 refactor: Change all enum-like `#define` sequences into enums. d3c2704fa9 chore: Fix make_single_file to support core-only. 0ce46b644e refactor: Change the `TCP_PACKET_*` defines into an enum. 22cd38ad50 adopt event impl generation tool to #2392 f31ea1088a add the event impl generation tool 4e603bb613 refactor: Use `enum-from-int` rule from tokstyle. 19d8f180d6 chore: Update github actions `uses`. 6a895be0c7 test: Make esp32 build actually try to instantiate tox. 65d09c9bfb cleanup: Remove test net support. REVERT: e29e185c03 feat: add ngc events git-subtree-dir: external/toxcore/c-toxcore git-subtree-split: f1df709b8792da4c0e946d826b11df77d565064d
155 lines
6.1 KiB
Plaintext
155 lines
6.1 KiB
Plaintext
It has come to our attention that to achieve decent market penetration Tox
|
|
must work behind ALL internet connections, may they be behind enterprise NATs
|
|
or any other bad network conditions.
|
|
|
|
The people who have issues with the UDP direct connection approach seem to be a
|
|
small minority though it is hard to estimate how many.
|
|
|
|
This means that routing their packets using good nodes on the network will
|
|
probably not take a huge toll on the network and will assure that people
|
|
can use Tox regardless of the quality of their internet connection.
|
|
|
|
|
|
How it's going to work:
|
|
1. Alice, a Tox client on a TCP only network generates a temporary public key
|
|
and connects to a bootstrap node.
|
|
|
|
2. Using the bootstrap node she finds and connects to a couple (exact number
|
|
to be determined later) number of random nodes that have TCP relay support.
|
|
|
|
3. She uses the onion through the TCP relay connections to send friend requests
|
|
or tell online friends which TCP nodes she is connected to and her temporary
|
|
public key.
|
|
|
|
4. Bob receives an onion packet from Alice telling him which nodes she is
|
|
connected to. Bob connects to these nodes and establishes a routed connection
|
|
with Alice using that temporary public key.
|
|
|
|
5. That connection is used by both to transmit encrypted Messenger and A/V
|
|
packets.
|
|
|
|
6. If one of the nodes shuts down while it is currently routing traffic, Alice
|
|
and bob just switch to one of the other nodes they are both connected to.
|
|
|
|
|
|
Detailed implementation details:
|
|
|
|
There are two distinct parts for TCP relays, the client part and the server
|
|
part.
|
|
|
|
The server acts as the actual relay. Servers must have fully forwarded TCP
|
|
ports (NAT-PMP and uPNP can help here). The first port the server will try
|
|
binding to is 443 followed by port 3389 and possibly some others. Onion packets
|
|
can be sent/received through the TCP servers.
|
|
|
|
|
|
Server:
|
|
|
|
The public/private key pair the TCP server uses is the same one he uses for the
|
|
DHT.
|
|
|
|
all crypto for communication with the server uses the crypto_box() function of
|
|
libsodium.
|
|
|
|
TCP doesn't have packets so what we will refer to as packets are sent this way:
|
|
[[uint16_t (length of data)][data]]
|
|
|
|
So if you would inspect the TCP stream you would see:
|
|
[[uint16_t (length of data)][data]][[uint16_t (length of
|
|
data)][data]][[uint16_t (length of data)][data]]
|
|
|
|
Note that both handshake packets don't have this format (the length for them is
|
|
always the same so we don't need to specify it.)
|
|
|
|
When the client connects to the server, he sends this packet:
|
|
[public key of client (32 bytes)][nonce for the encrypted data [24
|
|
bytes]][encrypted with the private key of the client and public key of the
|
|
server and the nonce:[public key (32 bytes) and][base nonce we want the server
|
|
to use to encrypt the packets sent to us (24 bytes)]]
|
|
|
|
The server responds with:
|
|
[nonce for the encrypted data [24 bytes]][encrypted with the public key of the
|
|
client and private key of the server and the nonce:[public key (32 bytes)
|
|
and][base nonce we want the client to use to encrypt the packets sent to us (24
|
|
bytes)]]
|
|
|
|
All packets to the server are end to end encrypted with the information
|
|
received
|
|
(and sent) in the handshake.
|
|
|
|
(first packet is encrypted with the base nonce the private key for which the
|
|
client sent the server the public key and the public key we sent to the client,
|
|
the next with base nonce + 1...)
|
|
|
|
The connection is set to an unconfirmed state until a packet is received and
|
|
decrypted correctly using the information in the handshake.
|
|
|
|
each packet sent to/from the server has an id (the first byte of the plain text
|
|
data of the packet.)
|
|
|
|
ids 0 to 15 are reserved for special packets, ids 16 to 255 are used to denote
|
|
who we want the data to be routed to/who the packet is from.
|
|
|
|
special ids and packets:
|
|
0 - Routing request.
|
|
[uint8_t id (0)][public key (32 bytes)]
|
|
1 - Routing request response.
|
|
[uint8_t id (1)][uint8_t (rpid) 0 if refused, packet id if accepted][public key
|
|
(32 bytes)]
|
|
2 - Connect notification:
|
|
[uint8_t id (2)][uint8_t (packet id of connection that got connected)]
|
|
3 - Disconnect notification:
|
|
[uint8_t id (3)][uint8_t (packet id of connection that got disconnected)]
|
|
4 - ping packet
|
|
[uint8_t id (4)][uint64_t ping_id (0 is invalid)]
|
|
5 - ping response (pong)
|
|
[uint8_t id (5)][uint64_t ping_id (0 is invalid)]
|
|
6 - OOB send
|
|
[uint8_t id (6)][destination public key (32 bytes)][data]
|
|
7 - OOB recv
|
|
[uint8_t id (7)][senders public key (32 bytes)][data]
|
|
8 - onion packet (same format as initial onion packet (See: Prevent
|
|
tracking.txt) but packet id is 8 instead of 128)
|
|
9 - onion packet response (same format as onion packet with id 142 but id is 9
|
|
instead.)
|
|
|
|
The rest of the special ids are reserved for possible future usage.
|
|
|
|
If the server receives a routing request he stores server side that the client
|
|
wants to connect to the person with that public key and sends back a Routing
|
|
request response with the rpid along with the public key sent in the request.
|
|
|
|
If for some reason the server must refuse the routing request (too many) he
|
|
sends the response with a rpid of 0.
|
|
|
|
If the person who the client wants to connect to is also online and wants to
|
|
connect to the client a connect notification is sent to both with the
|
|
appropriate packet id.
|
|
|
|
If either one disconnects, a disconnect notification is sent to the other with
|
|
appropriate packet id.
|
|
|
|
If a client sends a disconnect notification, the entry on the server for that
|
|
routed connection is cleared and a disconnect notification is sent to the peer
|
|
(if he was online)
|
|
|
|
If the server receives an onion packet he handles it the same as he would if it
|
|
was one received normally via UDP, he must also assure himself that any
|
|
responses must be sent to the proper client.
|
|
|
|
Ping responses must have the same ping_id as the request.
|
|
|
|
If the server receives a ping packet he must respond with a ping response.
|
|
|
|
The server will send a ping packet to clients every 30 seconds, they have 30
|
|
seconds to respond, if they don't the connection is deleted.
|
|
|
|
OOB send packets will be sent to the peer connected to the TCP server with the
|
|
destination public key as a OOB recv packet. The client sending this packet has
|
|
no way of knowing if the packet reached its destination.
|
|
|
|
|
|
Client:
|
|
|
|
Implementation details coming soon.
|