C-toxcore: Documente perguntas e respostas relacionadas a redes criptográficas e p2p

Você está enganado. Os nós de bootstrap do DHT existem para facilitar a adesão ao DHT. Se desejar mais explicações, consulte este artigo: https://en.wikipedia.org/wiki/Distributed_hash_table. Alternativamente, você pode se juntar a nós no IRC, no canal #tox no Freenode, e tentaremos explicar as coisas da melhor maneira possível.

Seu tráfego pode passar por nós de bootstrap atuando como retransmissores TCP enquanto o tox usa o TCP para a conexão amiga. É semelhante ao TURN . Seu tráfego ainda é criptografado de ponta a ponta, para que a confidencialidade e a autenticidade de suas mensagens nunca sejam comprometidas. Essa retransmissão TCP é provavelmente o que você viu em sua análise de tráfego. Ele é descrito em detalhes na especificação do protocolo tox .

É um tráfego de voz. Está criptografado e agora terceiros não podem descriptografar isso, mas isso não significa que seja impossível no futuro.

Eu tenho endereço IPv4/IPv6 direto. Por que devo enviar meus dados para nós?
Você diz - 'nós bootstrap DHT existem para facilitar a adesão ao DHT.', mas não é verdade. Na captura de tela anexada, o tráfego passa por nós, não diretamente para mim.

'Tox é um software fácil de usar que conecta você com amigos e familiares sem que ninguém mais o escute. ' - é mentira? Tráfego criptografado, ok. Mas está usando nós para entrega? Eu não sei, quem manteve esses nós. E se um ou mais nós for falso?

Entendo como esse ponto pode parecer incorreto, por isso registrei um problema de documentação para melhorar nossa apresentação disso. Obrigado por explicar seus pensamentos.

Para explicar rapidamente sua preocupação específica, vou parafraseá-la. Por favor, deixe-me saber se eu entendi errado:

P: _Estou preocupado com o fato de que os pacotes de dados vindos do meu computador não são entregues diretamente ao computador do meu amigo, mas às vezes (ou o tempo todo, dependendo das condições da rede) são retransmitidos por computadores de terceiros._

R: Primeiro, considere um pacote indo diretamente do seu computador para o computador do seu amigo, supondo que você esteja em um wifi local:

• Seu computador cria um pacote Tox criptografado (consulte os detalhes de criptografia ), que ele envolve em um pacote UDP contendo as portas de origem/destino (aleatório/33445) e, em seguida, em um pacote IP contendo os endereços IP de origem/destino (você e seu amigo) , em seguida, um quadro sem fio contendo os endereços MAC de origem/destino (você e os pontos de acesso).
• Este quadro sem fio é enviado por um canal criptografado AES (assumindo WPA2).
• O ponto de acesso sem fio, assim como qualquer outro usuário da rede, o recebe. Outros usuários geralmente ignoram o pacote, mas não precisam. Ler pacotes que não são feitos para você é chamado de sniffing. Este é o primeiro ponto em que outros podem ler o pacote.
• O ponto de acesso sem fio está conectado a um roteador WAN (internet) que estabelece uma conexão com os roteadores do seu provedor de serviços de Internet por alguns meios (acoplamento acústico, ISDN, ADSL, Cabo, Satélite, fibra, ...). Esta conexão pode ser criptografada (alguns satélites), mas geralmente não é. Neste ponto, o roteador WAN para o qual você enviou seu pacote criará um quadro Ethernet contendo seu próprio endereço MAC e o endereço MAC do próximo roteador ao qual ele se conectar, que é o roteador ISP. Em trânsito, os endereços IP e MAC provavelmente não são criptografados e podem ser lidos por qualquer pessoa que fareja a fibra óptica entre você e o ISP. Este é o segundo ponto em que outros podem ler o pacote.
• Assim que o pacote chegar ao ISP, ele passará por vários sistemas internos em seus data centers, possivelmente criptografados ou não criptografados em vários momentos. O roteador ISP decidirá então o próximo roteador para o qual deve enviar o pacote, determinado pelo endereço IP. Para fazer isso, ele desempacotará o quadro Ethernet recebido e o envolverá em um novo e o enviará para o próximo roteador. A qualquer momento durante o processamento no ISP, os funcionários do data center ou da administração do sistema desse ISP podem acessar seu pacote. Terceiro ponto de acesso.
• Agora seu pacote estará pulando de roteador para roteador (tente traceroute $your_friend_ip para ver para onde ele vai), cada um dos quais tem acesso livre ao quadro Ethernet, ao pacote IP e ao pacote UDP, bem como ao seu conteúdo. Muitos pontos de acesso, vamos chamá-lo de 4º.
• Então seu amigo pode estar em uma situação parecida, em um wifi local em um lugar diferente. Novamente, o roteador e os membros da rede sem fio podem ler o pacote. Quinto ponto de acesso.
• Só agora, finalmente, seu pacote chega ao computador do seu amigo. Ele recebe um quadro sem fio, o desembrulha para encontrar um pacote IP, o desembrulha para encontrar um pacote UDP, o desembrulha para encontrar um pacote Tox, que é então processado pela implementação do protocolo Tox. Esse processamento envolve descriptografar e decodificar o pacote e agir sobre ele, geralmente resultando no cliente do seu amigo exibindo a mensagem, reproduzindo áudio ou vídeo ou realizando alguma outra atividade no nível do aplicativo.

Como você vê, há muitos pontos durante a transmissão "direta" de você para seu amigo onde o pacote pode ser inspecionado por pessoas arbitrárias. A criptografia de ponta a ponta significa que em nenhum momento entre você e seu amigo alguém pode ler o conteúdo real que você pretendia transmitir. Eles sempre podem ver apenas os dados criptografados.

Agora, adicionar um relé TCP no meio simplesmente alongará a rota (teoricamente poderia encurtá-la, mas isso não é provável). Qualquer pessoa executando o relé pode ler o pacote, assim como qualquer outra pessoa entre você e seu amigo. O protocolo de criptografia Tox garante que sua comunicação seja segura.

Agora, também vejo uma segunda preocupação:

P: _O que acontece se um dos nós que estão transmitindo meus dados for maligno?_
R: O Tox seleciona vários relés TCP que ele pode usar para se comunicar caso as conexões UDP diretas não sejam possíveis (por exemplo, devido a NAT ou firewall). Relés do mal podem fazer muito poucas coisas para fazer o mal:

• Eles podem optar por não enviar o pacote. Nesse caso, o Tox tentará novamente por meio de um relé diferente. Somente se todos os nós de bootstrap forem ruins, uma transmissão falhará.
• Eles podem enviar um pacote modificado. Graças aos códigos de autenticação de mensagens, é provável que qualquer adulteração dos dados seja detectada. Se o remetente conseguir adulterar de uma forma que não seja detectada pelo software, o pacote descriptografado será lixo e a camada de aplicação (o decodificador do protocolo Tox) o descartará. Isso, portanto, tem o mesmo efeito de não retransmitir o pacote.

É basicamente isso. Em nenhum caso o relé malvado pode ler seus dados. Ele só pode optar por não retransmitir, e somente se cada nó de bootstrap for mau, você não poderá se comunicar. Isso seria muito chato e ficaríamos descontentes com isso, mas as informações de ninguém são comprometidas em nenhum momento.

Espero que isso esclareça algumas coisas. Não revisei esta resposta, mas me certificarei de que ela esteja devidamente representada no site para referência futura. Deixe-me saber se você tiver outras preocupações. Obrigado novamente por trazer isso à tona.

Acabei de ler sua mensagem novamente e descobri que perdi mais uma preocupação:

P: Embora os dados sejam criptografados agora, o que garante que eles não serão descriptografados no futuro?
R: O protocolo Tox implementa sigilo de encaminhamento perfeito por meio do uso de chaves efêmeras. Isso significa que, se uma dessas chaves for comprometida, algumas mensagens poderão ser descriptografadas, mas não todo o seu histórico de comunicação. A parte "algumas mensagens" desta frase será reduzida a "uma mensagem" no futuro. Se sua chave secreta de longo prazo for comprometida, nenhuma comunicação anterior poderá ser descriptografada.

Se as primitivas criptográficas que usamos estiverem quebradas, perdemos. Depende de como eles são quebrados, estes são os piores cenários possíveis:

• A cifra ( salsa20 ) pode ser facilmente revertida sem uma chave. Nesse caso, toda a comunicação anterior fica comprometida.
• A primitiva de troca de chave ( curve25519 ) é quebrada de forma que a chave secreta pode ser facilmente recuperada com uma chave pública. Neste caso, também toda a comunicação passada fica comprometida.

É muito improvável que esses cenários se tornem realidade em um futuro próximo, ou possivelmente para sempre. Pelo entendimento atual na comunidade de criptografia, apenas a computação quântica poderia fazer o segundo cenário acontecer. O primeiro cenário é considerado impossível.

Dito isso, também notei que você disse que tem um endereço IPv4 direto. O que isto significa? Se você tiver um endereço IPv4 público atribuído ao seu computador e a porta 33445 estiver aberta, o Tox deve estabelecer conexões diretas muito rapidamente. Se isso não acontecer, isso é um bug e devemos trabalhar juntos para descobrir por que ele escolhe usar o TCP.

Muito obrigado por esta explicação. Agora entendi um pouco mais.
Não tenho certeza sobre o endereço IPv4 direto... Estou usando o WireGuard VPN. WireGuard instalado no servidor virtual, que possui endereço IPv4 e IPv6 direto. Todo o tráfego é encapsulado no namespace.
Informações de rede do laptop: https://gist.github.com/DebugReport/1268e15c3bd1c99b56929d645d99392b
Se eu estava enganado, me desculpe.
Talvez o IPv4 não seja direto, mas e o IPv6? Posso usar conexões diretas se outro cliente tiver IPv6 também?

Sim, se ambas as partes tiverem IPv6 e a configuração do firewall não bloquear a porta 33445 (ou alguma outra porta próxima a ela, algo entre 33445 e 33545), deve funcionar. Seu amigo está na mesma VPN?

Não.
Hum... Pergunta. Precisamos usar nós sempre? Ou apenas se um de nós não tiver IP direto (somente IPv4?)?
Para IPv6 (me) <-> IPv6 (amigo) se os nós são necessários? Se sim - por quê?

(Mantendo este problema em aberto até que todas essas perguntas sejam respondidas na documentação)

Se um de vocês tiver um IP público, o outro pode inicializar usando o IP e a porta do outro. Isso requer suporte ao cliente que não acho que nenhum cliente tenha atualmente:

• Obtenha a chave pública DHT do cliente com IP público e porta aberta ( tox_self_get_dht_id ) e sua porta ( tox_self_get_udp_port ).
• Envie essa chave para o outro de alguma forma (dite via telefone ou mensagem no Skype ou algo assim).
• O outro agora precisa inicializar usando a tupla (key, ip, port) .

Depois disso, você tem uma rede Tox pessoal de 2 pessoas. Então, em teoria, você não precisa de outros nós. Eles tornam as coisas mais fáceis, no entanto.

Se um de vocês tiver um IP público e uma porta aberta, a conexão com nós de bootstrap também deve permitir que você estabeleça uma conexão direta. Os nós de bootstrap DHT têm pouco a ver com se você pode se conectar ou não. Uma conexão direta deve ser possível mesmo se apenas um de vocês tiver um IP público e uma porta aberta. O outro se conectaria a ele, o que criaria uma rota no roteador local e forneceria ao cliente uma porta pública aleatória temporária.

Apenas uma observação: notei o mesmo comportamento com o C-Toxcore. Uma das partes está em um VPS com um endereço IP público e sem firewall, a outra está atrás do NAT, mas tem a porta Tox encaminhada - portanto, devem ser mutuamente alcançáveis. O tráfego ainda era roteado via TCP.

Não vejo isso como um problema de segurança, mas certamente é um problema de escalabilidade se uma rede P2P estiver retransmitindo todo o tráfego por meio de retransmissões.