Tor introduz defesa por prova de trabalho para serviços onion
(blog.torproject.org)- O Tor 0.4.8 introduz uma defesa que prioriza tráfego de rede verificado quando serviços onion sofrem ataques DoS
- Na arquitetura dos serviços onion, que oculta endereços IP, a limitação de taxa baseada em IP é incompleta, por isso era necessário um método de puzzle para clientes que não prejudicasse a privacidade
- Quando o serviço está sob pressão, o cliente prova a quantidade de trabalho realizada por meio de cálculos de puzzles cada vez mais difíceis, e a prioridade da conexão varia conforme esse nível
- Para usuários comuns, o tempo inicial de resolução é de cerca de 5 ms em computadores rápidos e de até 30 ms em hardware lento, sendo viável para a maioria dos dispositivos
- Quando o tráfego de ataque aumenta, o trabalho exigido pode subir para cerca de 1 minuto, tornando tentativas massivas de conexão caras e dando a usuários legítimos uma chance de acesso mesmo em situações congestionadas
Defesa PoW para serviços onion no Tor 0.4.8
- Com o lançamento do Tor 0.4.8, o Tor introduziu oficialmente uma defesa de prova de trabalho (PoW) para serviços onion
- O objetivo é conter ataques DoS enquanto prioriza tráfego verificado
- Recomenda-se que operadores de serviços onion atualizem para a versão 0.4.8
- Como os serviços onion ocultam endereços IP para proteger a privacidade dos usuários, eles podem ser vulneráveis a ataques DoS, e a proteção baseada apenas na limitação de taxa tradicional por IP é incompleta
Puzzles de cliente e tratamento por prioridade
- A PoW funciona basicamente como um sistema de tíquetes desativado por padrão, mas cria uma fila de prioridade quando há estresse na rede
- Antes de acessar um serviço onion, o cliente precisa resolver um pequeno puzzle para provar que realizou uma certa quantidade de trabalho
- Quanto mais difícil o puzzle, mais trabalho foi realizado
- O serviço onion define a prioridade da conexão de acordo com o nível de esforço demonstrado pelo cliente
- Se um atacante inundar um serviço onion com muitas solicitações, o esforço computacional necessário para acessar o site .onion aumenta
- Tentativas massivas de conexão exigem mais recursos computacionais
- A estrutura faz com que a rentabilidade do atacante diminua à medida que a quantidade de trabalho aumenta
Impacto visto por usuários comuns
- Usuários comuns normalmente enviam poucas solicitações por vez, então o custo de resolver o puzzle é gerenciável na maioria dos dispositivos
- O tempo inicial de resolução é de cerca de 5 ms em computadores rápidos
- Em hardware lento, chega a até 30 ms
- Quando o tráfego de ataque aumenta, a quantidade de trabalho pode subir para aproximadamente 1 minuto
- Esse processo não é visível para o usuário, e a experiência de esperar pela resposta da PoW é parecida com aguardar uma conexão de rede lenta
- Se grandes sites adotarem essa abordagem, será possível reduzir o impacto negativo de ataques direcionados sobre a velocidade da rede e ajudar a equilibrar a carga durante picos repentinos de tráfego, tornando o acesso a serviços onion mais consistente e confiável
1 comentários
Comentários do Hacker News
Interessante. A proposta deixa claras as expectativas: não pretende bloquear grandes botnets, mas sim se defender contra script kiddies e botnets pequenas
Mesmo durante ataques DoS, usuários que realmente querem acessar podem passar, embora talvez precisem fazer algum esforço
Também é interessante a escolha de https://github.com/tevador/equix como algoritmo de prova de trabalho
Em vez de funcionar como no Bitcoin, em que é preciso ficar abaixo de um alvo estático para ter sucesso, a estrutura faz o cliente “dar um lance” com esforço de prova de trabalho, e quanto mais esforço ele dedica, maior sua prioridade. A explicação é que isso se parece com prova de participação no sentido de que você deposita trabalho em vez de depositar moedas
[1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...
Esta versão também é boa, mas acho que ficaria melhor com transferência de valor
Além disso, prova de trabalho é apenas cálculo desnecessário e desperdiçado. Computação não é de graça, e cada watt usado em prova de trabalho piora a crise climática atual
Como alguém que mora em uma região que, em poucos dias, vai chegar a sensação térmica de 120 graus e temperatura real de 109 graus, para dizer de forma educada, eu mandaria à merda qualquer pessoa que sugerisse que prova de trabalho é uma boa ideia para qualquer coisa
Não é interessante; é o exemplo mais escancarado de consumo conspícuo do planeta
Um texto melhor, ou seja, com os detalhes técnicos de fato, é https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
A função de prova de trabalho escolhida parece ser equi-X
Surpreende que algo assim não tenha sido incluído antes, e ainda não sei se isso aumentará os dados que afetam o anonimato dos usuários, porque não li a proposta [0] com detalhes suficientes. Ainda assim, se ficar vinculado por par usuário-serviço e não for armazenado em lugar nenhum, parece ok
Também fico curioso sobre o quanto isso reduzirá separadamente a carga do serviço proxyado e a carga do próprio nó. Como o acesso é distribuído por vários nós, parece que o benefício maior será do lado do serviço
[0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
Bom. Talvez em breve não precisemos mais de CDNs para defesa contra DDoS. Basta oferecer a API como um serviço Onion
Esse método já foi proposto antes também para evitar spam por e-mail
A Cloudflare também pode fazer isso. A cada acesso a um site movimentado, você ficaria rodando cálculos inúteis por alguns segundos a alguns minutos. O efeito total provavelmente seria sugar as baterias do mundo inteiro
http://www.hashcash.org/
Curiosamente, ela inspirou a mineração por prova de trabalho do Bitcoin
Porque também vai despejar gases de efeito estufa na atmosfera
Fico me perguntando o que impede um abusador de obter uma nova identidade e continuar o DDoS depois que a prova de trabalho começa a funcionar
Edit: parece que a prova de trabalho é configurada por “serviço” atacado, não por cliente
Por causa do anonimato e da capacidade de criar novas identidades livremente, um atacante pode esgotar a capacidade por meio de um ataque Sybil e causar negação de serviço
Fico me perguntando se há uma forma mais elegante de resolver ataques Sybil aqui. Por exemplo, muitas CPUs têm um par de chaves exclusivo por processador, que pode ser verificado com certificados-raiz de CA de emissores como Intel, AMD etc. Se a prova de trabalho for vinculada a assinaturas sequenciais e permitir verificação paralela, toda prova de trabalho se tornaria exclusiva por CPU, impedindo a paralelização por botnets
Eles parecem estar mirando memória para aumentar o custo das botnets. Também parecem existir muitas outras formas de reduzir esse cenário de ataque. A mesma lógica talvez pudesse ser aplicada a celulares com eSIM. Depois disso, a autenticação da rede móvel usa criptografia de chave pública, então uma prova exclusiva também parece possível
É só uma ideia que me veio à cabeça, então é bem provável que eu esteja deixando passar algum problema óbvio desse método
A razão para escolher um algoritmo que usa muita memória é impedir o uso de hardware específico, ou seja, ASICs
Numa linha parecida, fico pensando: e se o servidor mantivesse vários pools de IPs e fizesse o cliente retornar uma prova de port knocking? Por exemplo, dar um token, mandar enviar para este IP:porta e esperar uma resposta única que eu consiga verificar. Isso poderia ser chamado de prova de latência. O uso de CPU seria baixo, e a carga poderia ser distribuída entre várias máquinas e portas. A desvantagem, obviamente, é precisar de vários IPs e potencialmente vários servidores. Até daria para implementar na mesma máquina, mas aí a carga de CPU só seria deslocada para as conexões de porta
Tenho uma ideia para reduzir o tráfego na rede Tor ou torná-la mais rápida. A rede deveria poder ser usada como uma CDN. Se você quiser publicar um arquivo, deveria poder enviar pedaços dele para nós autorizados e, quando houver uma solicitação pelo arquivo, apontar para esses nós
Claro, é preciso tomar cuidado para que a rede Tor não vire um “substituto anônimo de torrent” e acabe deturpando seu objetivo
A proposta atual fala em “priorização de tráfego de rede verificado”. Como isso de fato ajuda a rede, seria interessante se compartilhar “pedaços de arquivo” pudesse aumentar a prioridade de tráfego. Em vez de “prova de trabalho”, seria uma prova de contribuição de largura de banda
Ainda assim, não entendo bem como isso reduziria o tráfego de rede. De qualquer forma, seria necessário se comunicar com os nós da CDN
Considerando as metas e limitações definidas por esta proposta, ela parece razoável e provavelmente alcançará essas metas. Como foi dito, funcionará contra botnets pequenas, mas botnets grandes ainda podem superar os recursos disponíveis de clientes individuais
Pessoalmente, não gosto de prova de trabalho. Aqui ela se parece mais com bloat como mecanismo de defesa, pode tornar hardware antigo obsoleto rapidamente e, considerando todos os dispositivos afetados, tem potencial para consumir bastante energia. Se aplicada em larga escala, vira um ônus ambiental considerável
Do ponto de vista do atacante, só o fato de elevar tanto a dificuldade já pode ser considerado um sucesso. Se o usuário tiver que esperar 1 minuto com o dispositivo rodando a 100%, em muitos casos ele simplesmente vai desistir
Ainda assim, é uma forma bastante boa de mitigar ataques DoS sem prejudicar o anonimato do usuário; desse ponto de vista, apesar das desvantagens, é uma boa solução. Enquanto existir no Tor, não vejo grande problema, mas, se fosse aplicada à web em geral, eu consideraria um desastre completo
O texto diz que a diferença no tempo de solução entre um servidor avançado e um celular de baixo desempenho é de apenas 6 vezes. Não entendo como isso é possível. Um servidor tem muito mais de 6 vezes a quantidade de RAM e de CPUs que um celular, e provavelmente CPUs mais rápidas também
Além disso, se for DDoS, o trabalho do servidor é embaraçosamente paralelizável, mas o trabalho do cliente pode não ser necessariamente paralelizável
Mesmo que a diferença seja de 6 vezes, ou até de 1 vez, o texto diz que, quando um DDoS é detectado, o tempo de solução é de 1 minuto. A essa altura, o serviço não está praticamente fora do ar?
O ponto principal da parte em que, quando um DDoS é detectado, o tempo de solução é de 1 minuto é transformar um ataque DoS fácil existente, o introduction flooding, em uma falha parcial ou degradação de velocidade. É uma melhoria incremental para um problema difícil