Criptografia de tráfego no Direct Connect, Parte 1

Ele lhes disse: os reis dominam as nações, e os benfeitores que os possuem são chamados, e você não é assim; mas qual de vocês é maior, seja como o menor e o governante como o servo. Lx 22: 25.26

A história

Comecei a pecar na Internet em 2004, e a rede local foi a tentação a princípio. Mais precisamente, um programa chamado DC ++ 0.401, que magicamente dava acesso a arquivos compartilhados por outros assinantes da mesma LAN. Para fazer isso, era necessário conectar-se a um ou mais nós da rede de compartilhamento de arquivos, chamados hubs. Os próprios hubs foram mantidos em seus computadores por entusiastas locais.

" DC ++ " é o nome do cliente. O protocolo é chamado "Conexão direta direta". Hubs DC . Clientes DC .

Esse era o seu próprio charme. Aqui você está offline, e agora dentro, entre pessoas que executaram aproximadamente as mesmas ações que você anteriormente. Incrível né?

Logo ficou claro que a mesma coisa poderia, em princípio, ser feita não apenas na rede local, mas também através da Internet ... Comunique-se, faça amigos, jure, negocie, crie seus próprios recursos, promova-os, melhore, tente outros clientes, procure por falhas e vulnerabilidades , participe de espionagem industrial, entre em contato com desenvolvedores etc. etc.


Tubo quente DC ++ v. 0,401

Em geral, o DC, com suas funções simples de comunicação e compartilhamento de arquivos, serviu com sucesso como a rede social da época. E o rosto humano do outro lado da tela parecia tão longe quanto você queria vê-lo.

Anos se passaram. Centros locais foram destruídos e mortos. Sob o ataque do Facebook, VKontakte e o torrent DC, até menos de quinhentos hubs públicos no antigo protocolo NMDC e dez (sic!) Rastreados no protocolo A Advanced Advanced Direct Connect.

Iniciar

Como leitores queridos já sabem, todo o tráfego dos russos é preservado por enquanto. É claro que não é higiênico, mas é isso que os usuários do Direct Connect fazem.

Então, o que é necessário? Primeiro, criptografe a comunicação do cliente DC com o hub. Em segundo lugar, criptografar a comunicação entre os clientes.

E aqui os problemas começam em todos os níveis dessa hierarquia digital simples e tão hierárquica.

Hubs

De repente, nenhum hub adequado é detectado. No antigo protocolo NMDC, eles não estão fisicamente presentes. As ADCs, no entanto, existem desde 2008, mas não resistem, porque permaneceram pequenas. Portanto, esse recurso precisará ser implantado independentemente de um hub ADC existente.

Clientes

Há um suporte de software para TLS em clientes DC há muito tempo, mas como não houve casos de seu aplicativo, ninguém realmente olhou para essa seção de configurações. Mas em vão!

É fácil converter um hub ADC existente em criptografia. Gere um certificado autoassinado, alimente-o com o mecanismo, selecione a "política" do TLS.

Mas o fato é que uma conexão segura com o hub é estabelecida ao usar um link no formato adc s : //hub.address.com: port

Configurar a “política” do TLS é aprovar conexões normais (ou seja, seguir um link no formato adc: //hub.address.com: port) ou redirecionar esse usuário para algum lugar (por exemplo, para o endereço “correto” )

tls_private_key="/etc/uhub/babylon.aab21pro.org.key" tls_certificate="/etc/uhub/babylon.aab21pro.org.crt" tls_enable=yes tls_require=yes tls_require_redirect_addr=adcs://babylon.aab21pro.org:412 

Exemplo de configuração TLS para uHub

A primeira opção deixa a possibilidade de conectar usuários com clientes ao hub que não conhecem a versão TLS maior que 1.0 (ou não sabem como), o que criará problemas ; e o segundo promete uma queda acentuada no atendimento.

*** Conectando a adcs: //babylon.aab21pro.org: 412 ...
*** Erro 1 do SSL: versão do protocolo de alerta tlsv1

Essa mensagem ao tentar se conectar ao hub ADCs exibe um cliente que pode apenas TLS v.1.0

Sim, acontece que o hub, neste caso, atua como uma espécie de censor e garante da possibilidade nominal de conexões seguras.

Admins

O protocolo antigo possui uma falha global: a incapacidade da rede funcionar como uma unidade com o número de hubs mais de um. Sim, para redes locais, um grande hub é a norma, mas, de fato, um usuário em dois hubs diferentes é dois usuários completamente diferentes de todos os pontos de vista possíveis (exceto o próprio usuário, mas isso não é preciso). E se você conseguir se conectar ao hub mais de uma vez, o recheio completo começará.

No momento, os administradores e proprietários de grandes hubs de DC estão interessados ​​apenas no número de usuários on-line e no que pode ser feito sobre isso. Usuários são comprados e vendidos; não há cultura de interação entre administradores e usuários, não há comunidade. Se você quiser, não há moralidade, juntamente com a ética e o conceito da norma, e os problemas que surgem são resolvidos de acordo com os conceitos. Você se lembra da tradução literal da palavra servidor? ..

Então, a fragmentação feudal é obtida. É mais lucrativo (para quem?) Permitir que tudo seja possível para todos (por exemplo, usar clientes com vulnerabilidades conhecidas que estavam desatualizadas há 10 ou mais anos) do que agir como garante de qualquer coisa.

Utilizadores

O que os proprietários dos hubs fizeram com certeza é que eles torturavam usuários com spam exigindo ir a algum lugar ou se registrar por algum motivo, em vez de distribuir instruções claras em caso de situações típicas.

Naquela época, a DC não adicionou popularidade à necessidade de encaminhar portas em um roteador e conhecer a "qualidade" de seu endereço IP. O procedimento não é difícil, mas até hoje causa problemas.

Como resultado, é problemático transmitir informações úteis ao usuário do hub dentro do próprio hub. Não leia!

Sumário

Examinamos a teoria e os problemas de tradução de um aconchegante compartilhamento de arquivos no Direct Connect para o uso da criptografia moderna, necessária hoje. Como você pode ver, para isso, tive que apontar as falhas na interação entre o administrador do usuário <=> programa cliente <=> hub <=> e apresentá-lo novamente .

Na segunda parte do artigo, está planejado considerar a prática de selecionar e configurar um cliente DC para trabalhar em um hub de ADCs.