Recentemente, o WireGuard tem atraído bastante atenção; de fato, é a nova "estrela" entre VPN. Mas será que ele é tão bom quanto parece? Eu gostaria de discutir algumas observações e analisar a implementação do WireGuard para explicar por que ele não é uma solução que substitua o IPsec ou o OpenVPN.
Neste artigo, gostaria de desmistificar alguns mitos [em torno do WireGuard]. Sim, a leitura será longa, então, se você ainda não preparou sua xícara de chá ou café, este é o momento certo. Também gostaria de agradecer ao Peter pela revisão dos meus pensamentos caóticos.
Não tenho a intenção de desacreditar os desenvolvedores do WireGuard, desmerecer seus esforços ou ideias. O produto deles é funcional, mas pessoalmente, considero que ele é apresentado de forma totalmente errada — sendo visto como uma substituição do IPsec e OpenVPN, o que, na realidade, não existe agora.
Como nota, é importante mencionar que a responsabilidade por esse posicionamento do WireGuard recai sobre a mídia que o discutiu, e não sobre o projeto ou seus criadores.
Ultimamente, não houve muitas boas notícias sobre o núcleo do Linux. Fomos informados sobre as monstruosas vulnerabilidades dos processadores, que foram mitigadas em software, e Linus Torvalds falou sobre isso de maneira bastante rude e entediante, em uma linguagem técnica de desenvolvedor. O escalonador ou a pilha de rede de nível zero também não são tópicos muito compreensíveis para revistas de consumo. E é aqui que surge o WireGuard.
No papel, tudo soa ótimo: uma nova tecnologia que captura a imaginação.
Mas vamos analisá-la com um pouco mais de atenção.
Documentação técnica do WireGuard
Este artigo é baseado em documentação oficial do WireGuard, escrita por Jason Donenfeld. Nele, ele explica o conceito, o objetivo e a implementação técnica [do WireGuard] no núcleo do Linux.
A primeira frase diz:
O WireGuard […] visa substituir o IPsec na maioria dos casos de uso, assim como outras soluções populares baseadas em espaço de usuário e/ou TLS, como o OpenVPN, sendo mais seguro, eficiente e fácil de usar [ferramenta].
Claro, a principal vantagem de todas as novas tecnologias é sua simplicidade [em comparação com os predecessores]. Mas uma VPN também deve ser eficaz e segura.
E agora?
Se você disser que não precisa disso [do VPN], podemos encerrar a leitura aqui. No entanto, devo observar que essas questões são colocadas para qualquer outra tecnologia de tunelamento.
O mais interessante da citação acima está nas palavras "na maioria dos casos", que, evidentemente, foram ignoradas pela imprensa. E aqui estamos, onde acabamos devido ao caos gerado por essa negligência — neste artigo.
O WireGuard se tornará uma substituição para a minha conexão VPN [IPsec] entre sites?
Não. Não há chance de que grandes fornecedores, como Cisco, Juniper e outros, adotem o WireGuard para seus produtos. Eles não "pulam em trens que passam" a menos que haja uma grande necessidade. Mais tarde, falarei sobre algumas razões pelas quais eles provavelmente não conseguirão implementar o WireGuard em seus produtos, mesmo que quisessem.
O WireGuard levará meu RoadWarrior do laptop para o data center?
Não. Neste momento, o WireGuard não possui um grande número de funções importantes para que consiga fazer algo assim. Por exemplo, ele não pode usar IPs dinâmicos do lado do servidor do túnel, e apenas isso já quebra todo o cenário de uso deste produto.
O IPFire é frequentemente usado para canais de Internet baratos, como DSL ou conexão a cabo. Isso faz sentido para pequenas ou médias empresas que não precisam de fibra óptica rápida. [Nota do tradutor: não devemos esquecer que, em termos de conectividade, a Rússia e alguns países da CEI estão muito à frente da Europa e dos EUA, porque começamos a construir nossas redes muito mais tarde, e com a chegada do Ethernet e das redes de fibra óptica como padrão, foi mais fácil para nós nos adaptarmos. Nos mesmos países da UE ou EUA, o acesso de banda larga xDSL a 3-5 Mbps ainda é a norma geral, e a conexão de fibra óptica custa quantias absurdas sob nossos padrões. Por isso, o autor do artigo menciona conexão DSL ou a cabo como uma norma, e não uma relíquia antiga.] No entanto, conexões DSL, a cabo, LTE (e outros métodos de acesso sem fio) têm IPs dinâmicos. Claro, eles não mudam frequentemente às vezes, mas ainda assim mudam.
Há um subprojeto chamado “wg-dynamic”, que adiciona uma demonstração do espaço do usuário para superar essa limitação. Um grande problema do cenário do usuário descrito acima é a piora da situação devido à endereçamento dinâmico IPv6.
Do ponto de vista do distribuidor, tudo isso também não parece muito bom. Um dos objetivos do desenvolvimento foi manter a simplicidade e a clareza do protocolo.
Infelizmente, tudo isso se tornou realmente simples e primitivo demais, o que nos obriga a usar software adicional para que toda essa estrutura seja viável no uso real.
É tão fácil usar o WireGuard?
Ainda não. Não estou dizendo que o WireGuard nunca será uma boa alternativa para a comunicação entre dois pontos, mas por enquanto ele é apenas uma versão alpha do produto que deveria ser.
Mas o que ele realmente faz? O IPsec é realmente mais difícil de operar?
Obviamente que não. O fornecedor de IPsec pensou nisso e fornece seu produto juntamente com uma interface, por exemplo, com o IPFire.
Para configurar um túnel VPN através do IPsec, você precisará de cinco conjuntos de dados que devem ser inseridos na configuração: seu próprio endereço IP público, o endereço IP público do lado receptor, as sub-redes que deseja disponibilizar através dessa conexão VPN e a chave pré-compartilhada. Assim, a VPN é configurada em poucos minutos e é compatível com qualquer fornecedor.
Infelizmente, há algumas exceções nesta história. Qualquer um que tentou estabelecer um túnel VPN através do IPsec para uma máquina no OpenBSD sabe do que estou falando. Existem mais alguns exemplos problemáticos, mas na verdade há muito mais práticas positivas de uso do IPsec.
Sobre a complexidade do protocolo
O consumidor final não deve se preocupar com a complexidade do protocolo.
Se vivêssemos em um mundo onde isso fosse uma preocupação real para o usuário, já teríamos nos livrado do SIP, H.323, FTP e outros protocolos criados há mais de dez anos que não funcionam bem com NAT.
Há razões pelas quais o IPsec é mais complicado do que o WireGuard: ele faz muito mais coisas. Por exemplo, autenticação do usuário usando login/senha ou chip SIM com EAP. Ele tem uma capacidade expandidas de adicionar novos primitivos criptográficos.
E o WireGuard não tem isso.
E isso significa que o WireGuard, em algum momento, falhará, pois um dos primitivos criptográficos enfraquecerá ou será totalmente comprometido. O autor da documentação técnica menciona isso da seguinte forma:
Vale ressaltar que o WireGuard é criptograficamente autoconfiante. Ele intencionalmente carece de flexibilidade em termos de cifras e protocolos. Se forem descobertas falhas graves em primitivos subjacentes, todos os pontos finais precisarão ser atualizados. Como é evidente pelo fluxo contínuo de vulnerabilidades SSL/TLS, a flexibilidade de criptografia aumentou de forma colossal.
A última frase é absolutamente verdadeira.
Alcançar um consenso sobre qual criptografia usar torna os protocolos como IKE e TLS mais de complicados. Excessivamente complicados? Sim, vulnerabilidades em TLS/SSL ocorrem com frequência suficiente, e não há alternativas.
Sobre ignorar os problemas reais
Imagine que você tem um servidor VPN com 200 clientes ativos, em diversas partes do mundo. Este é um cenário de uso bastante padrão. Se você precisar alterar a criptografia, será necessário entregar uma atualização a todas as cópias do WireGuard nesses laptops, smartphones e assim por diante. Ao mesmo tempo entregar. Isso é literalmente impossível. Administradores que tentarem fazer isso levarão meses para implantar as configurações necessárias, e empresas medianas precisarão literalmente de anos para realizar tal tarefa.
IPsec e OpenVPN oferecem a função de negociação de cifras. Portanto, por algum tempo após você ativar uma nova criptografia, a antiga ainda funcionará. Isso permite que os clientes atuais atualizem para a nova versão. Depois que a atualização for implantada, você simplesmente desativa a criptografia vulnerável. E pronto! Você está incrível! E os clientes nem notam isso.
Na verdade, este é um caso muito comum para grandes implantações, e até mesmo o OpenVPN encontra algumas dificuldades nesse aspecto. A retrocompatibilidade é importante, e embora você esteja utilizando uma criptografia mais fraca, para muitos isso não se torna razão para fechar o negócio. Pois isso resultaria em paralisia para centenas de clientes devido à incapacidade de realizar seu trabalho.
A equipe do WireGuard simplificou seu protocolo, mas completamente inadequado para pessoas que não têm controle contínuo sobre ambos os pares do seu túnel. Na minha experiência, esse cenário é o mais comum.
Criptografia!
Mas que tipo de criptografia interessante é essa que o WireGuard utiliza?
O WireGuard utiliza Curve25519 para troca de chaves, ChaCha20 para criptografia e Poly1305 para autenticação de dados. Também trabalha com SipHash para chaves de hash e BLAKE2 para hashing.
ChaCha20-Poly1305 é padronizado para IPsec e OpenVPN (via TLS).
É evidente que o desenvolvimento de Daniel Bernstein é muito utilizado. O BLAKE2 é o sucessor do BLAKE, finalista do SHA-3, que não venceu devido à sua semelhança com o SHA-2. Se o SHA-2 fosse comprometido, haveria uma grande chance de que o BLAKE também fosse.
IPsec e OpenVPN não precisam do SipHash devido ao seu design. Portanto, a única coisa que não pode ser usada com eles atualmente é o BLAKE2, e isso somente até que seja padronizado. Isso não é uma grande desvantagem, pois VPNs utilizam HMAC para criar integridade, que é considerada uma solução forte mesmo em conjunto com MD5.
Portanto, concluo que praticamente o mesmo conjunto de ferramentas criptográficas é utilizado em todas as VPNs. Assim, o WireGuard não é mais nem menos seguro do que qualquer outro produto atual quando se trata de criptografia ou integridade dos dados transmitidos.
Mas mesmo isso não é o mais importante a ser destacado de acordo com a documentação oficial do projeto. O que realmente importa é a velocidade.
O WireGuard é mais rápido que outras soluções de VPN?
Em resumo: não, não é mais rápido.
ChaCha20 é um cifrador de fluxo, que é mais fácil de implementar em software. Ele cifra um bit de cada vez. Protocolos de bloco, como o AES, cifra blocos de 128 bits de cada vez. Para implementar suporte de hardware, são necessários muito mais transistores, então processadores maiores vêm equipados com AES-NI — uma extensão do conjunto de instruções que realiza algumas tarefas do processo de criptografia para acelerar.
Esperava-se que o AES-NI nunca chegasse aos smartphones [mas chegou, — nota do tradutor]. Para isso, foi desenvolvido o ChaCha20 — como uma alternativa leve e econômica, que poupa a bateria. Portanto, pode ser uma novidade para você saber que cada smartphone que você pode comprar hoje tem algum tipo de aceleração para AES e funciona com essa criptografia mais rápido e com menor consumo de energia do que com o ChaCha20.
É evidente que praticamente todos os processadores para desktops / servidores comprados nos últimos anos têm AES-NI.
Consequentemente, espero que o AES supere o ChaCha20 em cada cenário específico. Na documentação oficial do WireGuard, menciona-se que, graças ao AVX512, o ChaCha20-Poly1305 superará o AES-NI, mas essa extensão de conjunto de instruções estará disponível apenas em grandes processadores, o que novamente não ajudará com hardware menor e móvel, que sempre funcionará mais rápido com AES-NI.
Não tenho certeza se isso poderia ser previsto durante o desenvolvimento do WireGuard, mas hoje o fato de ele estar preso a uma única criptografia já é uma desvantagem, que pode impactar negativamente seu funcionamento.
O IPsec permite escolher livremente qual criptografia se adapta melhor ao seu caso. E, é claro, isso é necessário se você, por exemplo, quiser transferir 10 gigabytes ou mais de dados através de uma conexão VPN.
Problemas de integração no Linux
Embora o WireGuard tenha escolhido um protocolo de criptografia moderno, isso já está causando uma série de problemas. E assim, em vez de usar o que é suportado pelo kernel desde o início, a integração do WireGuard foi adiada por anos devido à falta desses primitivas no Linux.
Não estou totalmente atualizado sobre a situação em outros sistemas operacionais, mas provavelmente não difere muito da situação no Linux.
Como está a realidade?
Infelizmente, toda vez que um cliente me pede para configurar uma conexão VPN, deparo-me com o fato de que eles usam credenciais e criptografia desatualizadas. 3DES acompanhado de MD5 ainda é uma prática comum, assim como o AES-256 e SHA1. E embora o último seja um pouco melhor — não é algo que deve ser utilizado em 2020.
Para a troca de chaves sempre usa-se RSA — uma ferramenta lenta, mas suficientemente segura.
Meus clientes estão conectados a autoridades aduaneiras e outros órgãos e instituições do governo, bem como a grandes corporações cujos nomes são conhecidos em todo o mundo. Todos eles usam um formulário de solicitação que foi criado há décadas, e a possibilidade de usar SHA-512 simplesmente nunca foi adicionada. Não posso dizer que isso impacta de forma evidente o progresso tecnológico, mas está claro que isso desacelera os processos corporativos.
Sinto muito ao ver isso, porque o IPsec suporta curvas elípticas desde 2005. A Curve25519 também é mais nova e está disponível para uso. Existem ainda alternativas ao AES, como Camellia e ChaCha20, mas, é claro, nem todas são suportadas por grandes fornecedores como a Cisco e outros.
E as pessoas utilizam isso. Existem muitos conjuntos da Cisco, há uma infinidade de conjuntos projetados para trabalhar com a Cisco. Eles são líderes de mercado nesse segmento e não estão muito interessados em inovações.
Sim, a situação [no segmento corporativo] é horrível, mas não veremos nenhuma mudança por causa do WireGuard. Os fabricantes provavelmente nunca identificarão problemas de desempenho com as ferramentas e criptografia já usadas, nem enxergarão problemas ao usar o IKEv2 — e, portanto, não estão em busca de alternativas.
De fato, você já pensou em desistir da Cisco?
Benchmarks
Agora vamos passar para os benchmarks da documentação do WireGuard. Embora esta [documentação] não seja um artigo científico, eu ainda esperava que os desenvolvedores adotassem uma abordagem mais científica ou usassem uma abordagem científica como referência. Quaisquer benchmarks são inúteis se não podem ser reproduzidos, e são ainda mais inúteis quando obtidos em condições de laboratório.
Na construção do WireGuard para Linux, ele ganha vantagem usando GSO — Generic Segmentation Offloading. Com isso, o cliente cria um pacote enorme de 64 kilobytes e o criptografa/descriptografa em uma única abordagem. Assim, os custos para chamadas e implementações de operações criptográficas são reduzidos. Se você deseja maximizar a largura de banda da sua conexão VPN — isso é uma boa ideia.
Mas, como é comum, na realidade as coisas não são tão simples. O envio de um pacote tão grande para o adaptador de rede requer que ele seja dividido em vários pacotes menores. O tamanho normal de um envio é de 1500 bytes. Ou seja, nosso gigante de 64 kilobytes será dividido em 45 pacotes (1240 bytes de informação e 20 bytes de cabeçalho IP). Em seguida, por um tempo, eles bloquearão completamente o funcionamento do adaptador de rede, pois precisam ser enviados juntos e de uma vez. Isso resultará em um salto de prioridade, e pacotes como VoIP, por exemplo, serão colocados em uma fila de espera.
Assim, a alta largura de banda que a WireGuard tão audaciosamente afirma alcançar é feita à custa da lentidão nas operações de rede de outros aplicativos. E a equipe da WireGuard já confirmou essa é a minha conclusão.
Mas vamos seguir em frente.
De acordo com os benchmarks na documentação técnica, a conexão mostra uma largura de banda de 1011 Mbps.
Impressionante.
Isso é especialmente impressionante devido ao fato de que a largura de banda teórica máxima de uma conexão Ethernet de um gigabit é de 966 Mbps com um tamanho de pacote de 1500 bytes, menos 20 bytes para o cabeçalho IP, 8 bytes para o cabeçalho UDP e 16 bytes para o cabeçalho da própria WireGuard. Há outro cabeçalho IP no pacote encapsulado e outro de 20 bytes no TCP. Então, de onde veio esta largura de banda adicional?
Com grandes quadros e as vantagens do GSO, que discutimos acima, o máximo teórico com um tamanho de quadro de 9000 bytes será de 1014 Mbps. Normalmente, tal largura de banda é inatingível na prática, pois está associada a muitas dificuldades. Portanto, só posso supor que o teste foi realizado usando quadros ainda maiores, excedendo o tamanho de 64 kilobytes com um máximo teórico de 1023 Mbps, que é suportado apenas por alguns adaptadores de rede. Mas isso é absolutamente inaplicável em condições reais, ou pode ser usado apenas entre duas estações diretamente conectadas, exclusivamente em um ambiente de teste.
No entanto, como o túnel VPN é estabelecido entre dois hosts por meio de uma conexão de internet que não suporta grandes quadros, o resultado alcançado no estande não pode ser considerado um padrão. É simplesmente uma conquista de laboratório irreal, que é impossível e ineficaz em condições reais de combate.
Mesmo estando no data center, eu não conseguiria passar quadros maiores que 9000 bytes.
O critério de aplicabilidade na vida real foi absolutamente rompido e, como eu acho, o autor da "medição" realizada desacreditou seriamente a si mesmo por motivos compreensíveis.
Última luz de esperança
No site do WireGuard, fala-se muito sobre contêineres e fica claro para que ele realmente foi projetado.
VPN simples e rápida, que não requer configuração e pode ser implantada e configurada por ferramentas massivas de orquestração, como as da Amazon em sua nuvem. Especificamente, a Amazon utiliza as mais recentes funcionalidades de hardware que mencionei anteriormente, como AVX512. Isso é feito para acelerar o funcionamento e não ficar preso à x86 ou qualquer outra arquitetura.
Eles otimizam a largura de banda e pacotes que excedem 9000 bytes — resultando em enormes quadros encapsulados para a comunicação entre contêineres, ou para operações de backup, criação de snapshots ou deployment desses contêineres. Mesmo endereços IP dinâmicos não afetarão o funcionamento do WireGuard no cenário que descrevi.
Bem jogado. Brilhante implementação e um protocolo muito sutil, quase padrão.
Mas ele simplesmente não é adequado para o mundo fora de um data center totalmente controlado por você. Se você se atrever a começar a usar o WireGuard, terá que fazer compromissos constantes no desenvolvimento e na implementação do protocolo de criptografia.
Saída
Não é difícil concluir que o WireGuard ainda não está pronto.
Ele foi concebido como uma solução leve e rápida para uma série de problemas existentes. Infelizmente, por causa dessas soluções, sacrificou muitas funcionalidades que seriam relevantes para a maioria dos usuários. É por isso que não pode substituir o IPsec ou o OpenVPN.
Para que o WireGuard se torne competitivo, ele precisa adicionar pelo menos a configuração do endereço IP e a configuração de roteamento e DNS. É óbvio que é exatamente para isso que são necessários canais criptografados.
A segurança é minha principal prioridade, e neste momento não tenho motivos para pensar que o IKE ou TLS estão de alguma forma comprometidos ou quebrados. A criptografia moderna é suportada em ambos, e eles foram testados por décadas de uso. Se algo é mais novo, não significa que seja melhor.
A compatibilidade funcional é extremamente importante quando você se conecta a terceiros cujas estações você não controla. O IPsec é, de fato, o padrão e é amplamente suportado. E ele funciona. E, embora isso possa parecer teórico, o WireGuard no futuro pode ser incompatível até mesmo com diferentes versões de si mesmo.
Qualquer proteção criptográfica é eventualmente quebrada e, portanto, precisa ser substituída ou atualizada.
Negar todos esses fatos e o desejo cego de usar o WireGuard para conectar seu iPhone à estação de trabalho em casa é simplesmente uma masterclass em enterrar a cabeça na areia.
Fonte: habr.com
