COVIL HACKER

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » COVIL HACKER » Anonimato e segurança » Censura na Internet e desvio de bloqueio: não há tempo para relaxar


Censura na Internet e desvio de bloqueio: não há tempo para relaxar

Сообщений 1 страница 2 из 2

1

Isenção de responsabilidade: quase tudo descrito no artigo não é algo fundamentalmente novo ou inovador - é conhecido e inventado há muito tempo, usado em diferentes países do mundo, implementado em código e descrito em publicações científicas e técnicas, por isso não abro nenhum Pandora's caixa.

Frequentemente no Habré, em tópicos dedicados ao bloqueio de recursos, há declarações engraçadas como “Eu configurei TLS-VPN, agora eles vão assistir o que quiserem e os censores não vão bloquear minha VPN”, “Eu uso um túnel SSH, então tudo está OK, eles não vão banir totalmente todos os SSH", e assim por diante. Bom, vamos analisar a experiência de outros países e pensar como pode ser de fato.

0
Então, digamos que compramos de algum serviço ou, como usuários experientes, instalamos em uma nuvem / VPS pessoal e configuramos um servidor VPN para nós mesmos. Digamos que esses sejam os populares WireGuard ou OpenVPN. Você sabe o que? O WireGuard é um protocolo tão bonito que grita "Olhem todos, olhem, sou uma VPN" com todos os seus pacotes. E isso, em princípio, não é surpreendente, porque os autores no site do projeto escrevem diretamente que a ofuscação não foi e não será incluída em seus objetivos e planos.

Assim, no equipamento DPI (também conhecido como TSPU), com um pouco de desejo, o protocolo WireGuard é detectado e bloqueado por um ou dois. IPSec/L2TP - semelhante. Com OpenVPN a mesma coisa - este é provavelmente o primeiro protocolo que os chineses aprenderam a identificar e banir seu "Grande Firewall Chinês" (GFW). Estamos fodidos.

1
Ok, digamos que tiramos conclusões e, em vez de protocolos completamente pálidos, decidimos usar TLS-VPN, como SSTP, AnyConnect / OpenConnect ou SoftEther - o tráfego neles ocorre dentro do TLS, a conexão inicial é estabelecida via HTTP - que deve ser completamente indistinguível da conexão regular a qualquer site regular. Bem, como posso dizer...

No caso do MS SSTP , os censores, querendo saber o que você está fazendo, simplesmente farão uma solicitação ao seu servidor com a URL /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75 }/ com o método HTTP SSTP_DUPLEX_POST , conforme descrito no padrão do protocolo , e o servidor terá prazer em confirmar em resposta que é, sim, de fato uma VPN MS SSTP.

SoftetherVPN em resposta a uma solicitação GET com um caminho/vpnsvc/connect.cgi , digite application/octet-stream e payload ' VPNCONNECT ' retornará um código 200 e um blob binário previsível com uma história sobre quem ele é.

AnyConnect/OpenConnect quando acessado via / ou via /auth responderá com um XML muito característico. E você não pode se livrar de tudo isso de forma alguma - isso é definido nos protocolos e é por essa lógica que os clientes VPN funcionam. Estamos fodidos.

2
Claramente, seremos mais espertos e, como ainda temos TLS, vamos colocar um proxy reverso (por exemplo, haproxy) na frente do servidor VPN e resolver tudo via SNI (identificação do nome do servidor): conexões com um domínio específico na solicitação será enviado para o servidor VPN e todos os outros - para um site inofensivo com gatos. Você pode até tentar se esconder atrás de algum CDN - eles não vão banir todo o CDN, e eles não serão capazes de extrair nosso tráfego do tráfego total para todo o CDN, certo?

No entanto, existe um "mas". Nas versões atuais do TLS, o campo SNI não é criptografado, portanto, os censores podem espioná-lo facilmente e fazer uma solicitação com exatamente o nome de domínio correto. Não conte com a extensão Encrypted Client Hello (ECH), antes conhecida como eSNI: primeiro, ainda está em Drafte não se sabe quando será aceito e amplamente utilizado e, em segundo lugar, os censores podem pegar e simplesmente bloquear todas as conexões TLSv1.3 com ECH, como fizeram na China . Os índios do xerife não se importam. Estamos fodidos.

3
Brincadeiras à parte, somos determinados. Por exemplo, corrigimos o servidor OpenConnect para que ele aceite apenas conexões com uma palavra especial no URL (felizmente, os clientes AnyConnect / OpenConnect permitem isso) e fornece a todos os outros um stub plausível. Ou configure a autenticação obrigatória usando certificados de cliente.

Ou conectamos artilharia pesada de camaradas chineses que comeram um cachorro enquanto contornavam o bloqueio - V2Ray / XRay com um plugin VMess e VLess em cima de Websockets ou gRPC ou Trojan-GFW . Eles trabalham em TLS, podem compartilhar a mesma porta com um servidor da Web HTTPS e, sem conhecer a querida linha secreta que não pode ser espionada de fora, parece impossível detectar a presença de um túnel e conectar-se a ele, então tudo é multar?

Vamos pensar. Cada cliente TLS, ao se conectar, passa um determinado conjunto de parâmetros para o servidor: versões TLS com suporte, conjuntos de cifras com suporte, extensões com suporte, curvas elípticas e seus formatos. Cada biblioteca tem seu próprio conjunto e suas variantes podem ser analisadas. Isso é chamado de impressão digital ClientHello . A impressão digital da biblioteca OpenSSL é diferente da impressão digital da biblioteca GnuTLS. A impressão digital da biblioteca Go TLS é diferente da do navegador Firefox.

E quando conexões frequentes e longas para um determinado site são registradas do seu endereço por um cliente com a biblioteca GnuTLS (que não é usada em nenhum navegador popular, mas é usada no cliente OpenConnect VPN), ou de um telefone celular através de um celular operador, algum cliente se conecta ao Go (no qual o V2Ray está escrito), estamos ferrados. Essa detecção, por exemplo, é realizada na China e no Turquemenistão .

4
OK. Digamos que reconstruímos nosso cliente V2Ray não com TLS padrão, mas com uTLS , que pode se disfarçar de navegadores populares. Ou eles até pegaram os códigos-fonte do navegador mais popular, arrancaram todo o código da pilha de rede e escreveram seu próprio cliente proxy com base nele , para serem completamente indistinguíveis do TLS do navegador usual. Ou eles decidiram ir na direção de se disfarçar de outros protocolos como o SSH, ou pegaram o OpenVPN com um patch XOR . Ou algum KCP/ Hysteria disfarçado de DTLS.

Resumindo, digamos que temos algo mais raro e discreto. Parece que está tudo bem? Como dizer. Lembra do "pacote Yarovaya"? Aquele que requer serviços de Internet para salvar todos os metadados da sessão, e os provedores de Internet geralmente registram despejos de tráfego de seus assinantes? Muitos, mesmo assim, riram - eles dizem, bem, estúpido, o que eles receberão gigabytes de dados criptografados que não descriptografarão de qualquer maneira? E aqui está o que.

Você usa, por exemplo, seu túnel, olha para todos os tipos de sites proibidos lá. E então clique! - e acidentalmente passar pelo seu túnel para algum site doméstico ou serviço visto em cooperação com o estado - condicional lá VK / Mail.ru / Yandex ou qualquer outra coisa. Ou em algum site inofensivo encontra um widget, banner ou contador deles. Ou alguém no comentário lançará um link para algum site honeypot que se pareça com um recurso de notícias e você clicará nele.

E aqui acontece o mais interessante. O que está dentro do TLS, o que está dentro do SSH, o que está dentro do OpenVPN + xor, os dados são transmitidos de forma criptografada e não podem ser descriptografados. Mas a "forma externa" (tamanhos de pacotes e temporizações entre eles) dos dados criptografados é exatamente a mesma dos dados não criptografados. Os censores veem que o tráfego está indo do assinante para algum servidor desconhecido e vice-versa, e o fluxo de algum serviço controlado vê que algumas solicitações chegam lá do mesmo endereço IP do "servidor desconhecido" e as respostas voam e - isso é interessante - os tamanhos dos pacotes e os pontos de tempo coincidem quase completamente. O que é muito característico diz que temos um proxy aqui, possivelmente uma VPN, Andryukha, em cavalos!

E sim, se você agir com mais sabedoria e seu servidor tiver dois endereços IP, um para entrada e outro para saída, então não funcionará para corresponder sua "entrada" e "saída" por endereços, mas pelo "formulário" do dados transmitidos, pelo menos e significativamente mais difíceis, mas se desejado, ainda é possível. Estamos fodidos de novo.

5
Não é uma coisa tão ruim. Configuramos o acesso baseado em regras para nosso túnel. Ou seja, caminharemos sobre ele apenas quando necessário e quando necessário - e em todos os outros casos, deixaremos as malas rodarem imediatamente por meio de uma conexão regular à Internet. É verdade que adicionar um novo recurso à lista toda vez é outra hemorróida, especialmente quando você mantém um proxy / VPN não apenas para você, mas também, por exemplo, para pais idosos que moram longe e que, por exemplo, desejam ler todos os tipos de agentes estrangeiros - mas isso, na verdade, as pequenas coisas, a gente dá conta.

Digamos que ainda estamos usando o túnel SSH. É verdade que funcionará, provavelmente, por um curto período de tempo. Porque? Porque é tudo sobre os mesmos padrões de tráfego. E não, não há necessidade de anotar e comparar dolorosamente nada em qualquer lugar. Os padrões de tráfego de ssh-as-console, ssh-as-ftp e ssh-as-proxy são muito diferentes e são facilmente detectados por uma rede neural adequadamente treinada. Portanto, os chineses e iranianos há muito detectam todo esse uso "errado" do SSH e reduzem a velocidade da conexão para um caracol, que você ainda pode trabalhar no terminal, mas praticamente sem navegar.

Bem, ou digamos que você ainda use o túnel TLS, levando em consideração tudo o que é fornecido neste artigo. Mas o problema é que tudo o que foi dito no parágrafo anterior se aplica a ele - ou seja, é detectado por um observador externo usando heurística e aprendizado de máquina, que ainda pode ser treinado nos sites mais populares. Ainda estamos fodidos.

6
OK. Adicionamos preenchimento aleatório ao nosso túnel secreto - "adicionando" algum lixo de comprimento aleatório ao final do pacote para confundir os observadores. Ou quebramos deliberadamente os pacotes em pequenos pedaços (e temos problemas com o MTU, ah, teremos que reconstruir diligentemente mais tarde). Ou, ao contrário, quando temos uma conexão TLS com algum servidor dentro do túnel, começamos a enviar esses pacotes como estão sem uma camada de criptografia adicional , parecendo de fora cem por cento como TLS normal sem fundo duplo (embora você tenha gastar algumas iterações para trazer o protocolo à mente e conectar vulnerabilidades de implementação muito sutis e nada óbvias ). Ao que parece, final feliz, não estamos mais fodidos?

E aqui começa tudo de mais interessante. Ou seja, mais cedo ou mais tarde, em questões de identificação de túneis e bloqueios, principalmente com o desenvolvimento de tecnologias para contorná-los (afinal, ainda não tocamos em esteganografia e muitas outras coisas interessantes), começa a crescer algo chamado dano colateral - dano que surgiu acidentalmente durante um ataque a um alvo pretendido. Por exemplo, como dizem os insiders e confirmam os relatórios dos campos, os chineses aprenderam a detectar a detecção tls-inside-tls mencionada acima, mesmo com preenchimento aleatório , com aproximadamente 40% de precisão . É claro que com tanta precisão também são possíveis falsos positivos, mas quando os problemas dos índios preocuparam o xerife?

Protocolos que não se parecem com nada de fora (por exemplo, shadowsocks, obfs4, etc.) também podem ser identificados por... estatísticas de zeros e uns em bytes , porque para tráfego criptografado essa proporção é muito próxima de 1:1 - embora, é claro, os inocentes possam sofrer. É possível banir endereços quando há conexões demais ou muito longas para sites não muito populares. Existem algumas dessas opções e, se você acha que falsos positivos e danos causados ​​​​pelo bloqueio de sites respeitáveis ​​​​pararão os censores, você está enganado.

Quando Roskomnadzor tentou bloquear o Telegram, eles adicionaram sub-redes e hosts inteiros à lista de banimentos, banindo assim vários sites e serviços inocentes- e eles não ganharam nada por isso. No Irã, devido à popularidade do cliente proxy semelhante ao navegador mencionado acima, os censores geralmente baniram sem rodeios as conexões de impressão digital TLS do Chrome para serviços de nuvem populares. Na China , eles se enquadram maciçamente na distribuição da CDN , cujos serviços são usados ​​por sites e serviços inofensivos e inocentes. No Turquemenistão, quase um terço (!) de todos os endereços IP e sub-redes existentes no mundo são bloqueados dessa forma , porque assim que os censores detectam pelo menos uma VPN ou proxy, toda uma gama de endereços próximos a ele ou mesmo todo o AS é enviado para a proibição.

Você provavelmente pode perguntar, e as pessoas jurídicas que também usam VPN para trabalhar ou cujos serviços podem cair acidentalmente na distribuição? Esse problema é facilmente resolvido com a lista de permissões: se uma entidade legal precisar de um servidor VPN ou se você precisar proteger algum de seus serviços contra bloqueio acidental, deverá obrigá-los a informar os departamentos relevantes sobre os endereços e protocolos necessários com antecedência para que eles os adicionem à lista certa - foram precisamente esses pedidos que Roskomnadzor enviou aos bancos por meio do Banco Central , pensando em algo ruim, e o mecanismo para essas listas já existe .

E, claro, uma continuação completa disso será "tudo o que não é permitido é proibido". Lei que proíbe VPNs e anonimizadores para contornar o bloqueiojá existe na Rússia. Proibição do uso de ferramentas de criptografia não certificadas - também . Restringir e expandir suas áreas de aplicação e endurecer repetidamente as penalidades para tais "violações" é uma questão simples. Na China, caras educados vieram visitar os desenvolvedores dos notórios ShadowSocks e GoAgent e fizeram ofertas que eles não podiam recusar . No Irã , há casos de processos relacionados ao uso de VPN para acessar sites proibidos. O mecanismo de informar as autoridades sobre vizinhos não confiáveis ​​​​foi perfeitamente elaborado no século passado na URSS. Os estados têm o monopólio da violência, lembre-se. Estamos fodidos de novo?

4294967295
Por que isso tudo?

Como eu disse, a maior parte do que é descrito no artigo não é ficção ou teoria pura - é conhecido há muito tempo, usado em alguns países do mundo, implementado em código e até descrito em publicações científicas.

Contornar bloqueios é uma luta constante entre um escudo e uma espada e, ao mesmo tempo, um jogo de gato e rato : às vezes você come um urso, às vezes um urso come você , às vezes você está perseguindo, às vezes você está alcançando.

Se agora você tem um proxy ou VPN e funciona - não relaxe: você está apenas meio passo à frente de seus malfeitores. Você pode, é claro, sentar-se em silêncio e pensar: "Sim, eles são todos tolos e macacos de braços tortos e não fazem nada complicado e realmente funcionam", mas, como dizem, espere o melhor e prepare-se para o pior. Sempre faz sentido estudar a experiência dos mesmos colegas chineses e examinar mais de perto os desenvolvimentos mais difíceis de detectar e mais resistentes à censura. Quanto mais passos você ficar à frente dos censores, mais tempo terá para se adaptar à nova situação. Se você é um desenvolvedor e entende de protocolos e tecnologias de rede, pode participar de um dos projetos existentes, ajudar no desenvolvimento e pensar em novas ideias. Pessoas de todo o mundo vão agradecer.

Interessante e útil a esse respeito será Net4People , No Thought is a Crime , discussões no projeto XTLS (há a maior parte em chinês, mas o tradutor automático em inglês faz um bom trabalho), relatório GFW . Se alguém conhece bons recursos e comunidades sobre o assunto, escreva nos comentários

Bem, não se esqueça que mais cedo ou mais tarde, não podendo resistir tecnicamente a tal amor pela liberdade, o estado pode começar a resistir administrativamente (o mesmo monopólio da violência ), aliás, para que de sua parte, por sua vez, não seja mais possível resistir tecnicamente. Mas esta é uma história completamente diferente, exigindo um artigo separado e, provavelmente, em um recurso diferente.

Quando escrevi esta publicação, queria inserir nela imagens de algum filme dark cyberpunk, onde, como resultado do desenvolvimento das tecnologias de vigilância e censura e da incapacidade de resistir a ela, as pessoas se tornaram total e completamente controladas pelos estados e perderam tudo direitos à liberdade de pensamento e privacidade vida pessoal. Mas espero que não chegue a isso. Tudo depende de nós.

Fonte: Habr See More

0

2

шеде273.8CHAPCHAPMoscДиамКагаУтес(197RobeADHDЧернВесеРоссКитаTescTescNaviSkarанарMichСанк
ПашкTakaPhilChriXVIIЯзыкFashАлекLateYeahHaviаспеSenzУхтиРехтDaniСушкDaniTranбахтTescАрти
Will(193NiveСергDariIngrПырлБрауВартJameУшакКришШвейELEGПинсиспрDansEdwaVincБогдстраГрам
CIPDCotoЛатыOmsaCotoWeniCircСибимолнPeteJackJungPaliАндрArthModoDISNВещиМовчMargмракJamb
HarmБезывидаHuntязыкчитаВороZoneВПЗ0ZoneASASсереZoneZoneZoneZoneZoneZoneZoneменяZoneZone
ZoneR2A7коллZoneZoneZoneклейчаепVT-7WakiпереHotpAskoучасязыкФормТрав6200ChicSponКитаКита
CHROCERASTARрельдетьVocaзащиWorlKenwвкусрабоLEGOBabyKathStubПрокMoleDeLoднемRiccупакЛитР
ЛитРБрагВиткЛитРЛитРЛитРFinlJeweСероФормСахасборКошеХодоСырцразнВелиМадаDrexЯковMoviтеат
АнгиGinaPatrMaurChanЛиба(ВедкнигистоСолоMeinавтоРощиГерб2000SociDAIWНалоRobeСкопДьякпрак
Рыба(ПенавтопознКамоавтоКороVT-7VT-7VT-7BabuChroПрокСиниWindАлекГолоLendмульавтоJennКург
tuchkasКузнКита

0


Вы здесь » COVIL HACKER » Anonimato e segurança » Censura na Internet e desvio de bloqueio: não há tempo para relaxar


Рейтинг форумов | Создать форум бесплатно