2014-04-19 10:00:12 +08:00
|
|
|
The TCP client and TCP server part are in a state that can be considered
|
|
|
|
|
feature complete. Why doesn't Tox support TCP yet even if those parts are
|
|
|
|
|
complete?
|
|
|
|
|
|
|
|
|
|
The answer is that a way to ensure a smooth switchover between the TCP and UDP
|
|
|
|
|
needs to be added. If Tox first connects to the other user using TCP but then
|
|
|
|
|
due to pure chance manages to connect using the faster direct UDP connection
|
|
|
|
|
Tox must switch seamlessly from the TCP to the UDP connection without there
|
|
|
|
|
being any data loss or the other user going offline and then back online. The
|
|
|
|
|
transition must be seamless whatever both connected users are doing be it
|
|
|
|
|
transferring files or simply chatting together.
|
|
|
|
|
|
|
|
|
|
Possible evil/bad or simply TCP relays going offline must not impact the
|
|
|
|
|
connection between both clients.
|
|
|
|
|
|
|
|
|
|
Typically Tox will use more than one TCP relay to connect to other peers for
|
|
|
|
|
maximum connection stability which means there must be a way for Tox to take
|
|
|
|
|
advantage of multiple relays in a way that the user will never be aware if one
|
|
|
|
|
of them goes offline/tries to slow down the connection/decides to corrupt
|
|
|
|
|
packets/etc..
|
|
|
|
|
|
|
|
|
|
To accomplish this Tox needs something between the low level protocol (TCP) and
|
|
|
|
|
high level Tox messaging protocol hence the name middle level.
|
|
|
|
|
|
|
|
|
|
The plan is to move some functionality from lossless_UDP to a higher level:
|
|
|
|
|
more specifically the functionality for detecting which packets a peer is
|
|
|
|
|
missing and the ability to request and send them again. lossless UDP uses plain
|
|
|
|
|
text packets to request missing packets from the other peer while Tox is
|
|
|
|
|
currently designed to kill the connection if any packet tampering is detected.
|
|
|
|
|
This works very well when connecting directly with someone because if the
|
|
|
|
|
attacker can modify packets it means he can kill your connection anyways. With
|
|
|
|
|
TCP relays however that is not the case as such the packets used to request
|
|
|
|
|
missing packets must be encrypted. If it is detected that a packet has been
|
|
|
|
|
tampered, the connection must stay intact while the evil relay must be
|
|
|
|
|
disconnected from and replaced with a good relay, the behavior must be the same
|
|
|
|
|
as if the relay had just suddenly gone online. Of course something to protect
|
|
|
|
|
from evil "friends" framing relays must also be implemented.
|
|
|
|
|
|
|
|
|
|
Detailed implementation details:
|
|
|
|
|
|
2014-04-23 08:28:40 +08:00
|
|
|
cookie request packet:
|
|
|
|
|
[uint8_t 24][Senders DHT Public key (32 bytes)][Random nonce (24
|
|
|
|
|
bytes)][Encrypted message containing: [Senders real public key (32
|
|
|
|
|
bytes)][Recievers real public key (32 bytes)]]
|
|
|
|
|
Encrypted message is encrypted with sender DHT private key, recievers DHT public
|
|
|
|
|
key and the nonce.
|
|
|
|
|
|
|
|
|
|
cookie response packet:
|
|
|
|
|
[uint8_t 25][Random nonce (24 bytes)][Encrypted message containing: [Cookie]]
|
|
|
|
|
Encrypted message is encrypted with sender DHT private key, recievers DHT public
|
|
|
|
|
key and the nonce.
|
|
|
|
|
|
|
|
|
|
The Cookie should be basically:
|
|
|
|
|
[nonce][encrypted data:[uint64_t time][Senders real public key (32
|
|
|
|
|
bytes)][Recievers real public key (32 bytes)]]
|
|
|
|
|
|
|
|
|
|
Handshake packet:
|
|
|
|
|
[uint8_t 26][Cookie][nonce][Encrypted message containing: [random 24 bytes base
|
|
|
|
|
nonce][session public key of the peer (32 bytes)]]
|
|
|
|
|
|
|
|
|
|
The handshake packet is encrypted using the real private key of the sender, the
|
|
|
|
|
real private key of the reciever and the nonce.
|
|
|
|
|
|
