⛪️ 🐭 👨🏾‍🤝‍👨🏼 Por que você não deve usar o WireGuard 📻 🧒🏽 🔭

Recentemente, o WireGuard atrai muita atenção, de fato - essa é uma nova "estrela" entre as VPNs. Mas ele é tão bom quanto parece? Gostaria de discutir algumas observações e considerar a implementação do WireGuard para explicar por que não é uma solução que substituirá o IPsec ou o OpenVPN.

Neste artigo, gostaria de desmascarar alguns mitos [em torno do WireGuard]. Sim, levará muito tempo para ler; portanto, se você não fez uma xícara de chá ou café, é hora de fazê-lo. Também gostaria de agradecer a Peter por revisar meus pensamentos caóticos.

Não tenho como objetivo desacreditar os desenvolvedores do WireGuard, desvalorizar seus esforços ou idéias. O produto deles é funcional, mas pessoalmente acho que é apresentado completamente diferente do que realmente é - é apresentado como um substituto para o IPsec e o OpenVPN, que na realidade agora simplesmente não existe.

Como observação, quero acrescentar que a responsabilidade por esse posicionamento do WireGuard é da mídia que falou sobre ele, e não do projeto em si ou de seus criadores.

Ultimamente, não há muitas boas notícias sobre o tópico do kernel do Linux. Então, fomos informados sobre as vulnerabilidades monstruosas do processador, que foram niveladas por software, e Linus Torvalds falou sobre isso uma linguagem utilitária e muito rude e chata do desenvolvedor. O agendador ou a pilha da rede estão em nível zero - também não são tópicos muito claros para revistas brilhantes. E então o WireGuard aparece.

Tudo parece ótimo no papel: uma nova e empolgante tecnologia.

Mas vamos olhar para ela com um pouco mais de cuidado.

Documentação técnica do WireGuard

Este artigo é baseado na documentação oficial do WireGuard escrita por Jason Donenfeld. Lá, ele explica o conceito, objetivo e implementação técnica do [WireGuard] no kernel do Linux.

A primeira frase diz:

WireGuard [...] IPsec , / TLS, OpenVPN, , [].

Obviamente, a principal vantagem de todas as novas tecnologias é sua simplicidade [em comparação com seus antecessores]. Mas uma VPN também deve ser eficiente e segura .

Então, o que vem a seguir?

Se você disser que você [da VPN] não precisa disso, poderá terminar a leitura. No entanto, observarei que essas tarefas são colocadas antes de qualquer outra tecnologia de encapsulamento.

A mais interessante das citações acima está nas palavras "na maioria dos casos", que, é claro, foram ignoradas pela imprensa. E aqui estamos, onde acabamos por causa do caos criado por essa negligência - neste artigo.

O WireGuard substituirá minha conexão VPN [IPsec] entre sites?

Não. Simplesmente não há chance de grandes fornecedores como Cisco, Juniper e outros comprarem o WireGuard para seus produtos. Eles não “pulam trens passados” em movimento, a menos que haja uma grande necessidade disso. Mais tarde, falarei sobre algumas das razões pelas quais eles provavelmente não seriam capazes de instalar os produtos WireGuard a bordo, mesmo que quisessem.

O WireGuard transferirá meu RoadWarrior de um laptop para um data center?

Não. O WireGuard não implementou um grande número de funções importantes no momento para poder fazer algo assim. Por exemplo, ele não pode usar o endereço IP dinâmico no lado do servidor do túnel, e isso sozinho quebra todo o cenário de um uso semelhante do produto.

O IPFire é frequentemente usado para canais da Internet de baixo custo, como DSL ou conexão a cabo. Isso faz sentido para uma empresa de pequeno ou médio porte que não precisa de fibra rápida.[Nota do tradutor: não esqueça que, em termos de comunicação, a Rússia e alguns países da CEI estão muito à frente da Europa e dos Estados Unidos, porque começamos a construir nossas redes muito mais tarde e com o advento das redes Ethernet e de fibra ótica como padrão, foi mais fácil reconstruir. Nos mesmos países da UE ou nos EUA, o acesso de banda larga xDSL a uma velocidade de 3-5 Mbps ainda é a norma universal, e a conexão de fibra óptica custa algum dinheiro irrealista para nossos padrões. Portanto, o autor do artigo fala da conexão DSL ou a cabo como normal, e não do passado antigo.] No entanto, DSL, cabo, LTE (e outros métodos de acesso sem fio) têm endereços IP dinâmicos. Obviamente, às vezes eles não mudam frequentemente, mas ainda mudam.

Existe um subprojeto chamado "wg-dynamic"O daemon de espaço do usuário é adicionado para superar essa falha. Um grande problema com o cenário do usuário descrito acima é o agravamento da situação pelo endereçamento IPv6 dinâmico.

Do ponto de vista do distribuidor, tudo isso também não parece muito bom. Um dos objetivos do projeto era manter o protocolo simples e limpo.

Infelizmente, tudo isso se tornou muito simples e primitivo, por isso precisamos usar software adicional para viabilizar todo esse design em condições da vida real.

O WireGuard é tão fácil de usar?

Ainda não. Não estou dizendo que o WireGuard nunca será uma boa alternativa para encaminhar um túnel entre dois pontos, mas até agora é apenas uma versão alfa do produto que deve se tornar.

Mas então o que ele realmente faz? O IPsec é realmente muito mais difícil de operar?

Obviamente não. O provedor IPsec considerou esse ponto e está entregando seu produto junto com uma interface como IPFire.

Para configurar um túnel VPN através do IPsec, você precisará de cinco conjuntos de dados que serão necessários para entrar na configuração: seu próprio endereço IP público, o endereço IP público do lado receptor, sub-redes que você deseja tornar público por meio dessa conexão VPN e pré-compartilhado chave. Assim, a VPN é configurada em alguns minutos e é compatível com qualquer fornecedor.

Infelizmente, existem algumas exceções nesta história. Todo mundo que tentou encaminhar um túnel VPN através do IPsec para uma máquina no OpenBSD entende do que estou falando. Existem alguns exemplos mais dolorosos, mas, na verdade, a boa prática de usar IPsec é muito, muito mais.

Sobre a complexidade do protocolo

O usuário final não precisa se preocupar com a complexidade do protocolo.

Se vivêssemos em um mundo em que essa era a verdadeira preocupação do usuário, teríamos nos livrado há muito tempo do SIP, H.323, FTP e outros protocolos criados há mais de dez anos que não funcionam bem com o NAT.

Existem razões pelas quais o IPsec é mais complicado que o WireGuard: ele faz muito mais. Por exemplo, autenticação do usuário usando um login / senha ou cartão SIM com EAP. Possui a capacidade expandida de adicionar novas primitivas criptográficas .

Mas o WireGuard não.

E isso significa que o WireGuard irá quebrar em algum momento, porque uma das primitivas criptográficas se enfraquecerá ou será completamente comprometida. O autor da documentação técnica diz o seguinte:

Vale notar que o WireGuard é criptograficamente autoconfiante. Ele intencionalmente carece da flexibilidade de cifras e protocolos. Se furos sérios forem encontrados nas primitivas subjacentes, todos os pontos de extremidade precisarão ser atualizados. Como você pode ver no fluxo contínuo de vulnerabilidades de SLL / TLS, a flexibilidade de criptografia agora aumentou tremendamente.

A última frase é absolutamente verdadeira.

Construir consenso sobre qual criptografia usar torna protocolos como IKE e TLS mais complexos. Muito complicado? Sim, as vulnerabilidades são bastante comuns no TLS / SSL e não há alternativa para elas.

Sobre como ignorar problemas reais

Imagine que você tem um servidor VPN com 200 clientes de combate, em algum lugar do mundo. Este é um caso de uso muito padrão. Se você precisar alterar a criptografia, precisará entregar a atualização para todas as cópias do WireGuard nesses laptops, smartphones e assim por diante. Entregue ao mesmo tempo . É literalmente impossível. Os administradores que tentarem fazer isso levarão meses para implantar as configurações necessárias, e as empresas de médio porte levarão literalmente anos para sediar esse evento.

IPsec e OpenVPN oferecem negociação de criptografia. Portanto, algum tempo após o qual você habilitar a nova criptografia, a antiga funcionará. Graças a isso, os clientes atuais poderão atualizar para a nova versão. Depois que a atualização é lançada, você simplesmente desativa a criptografia vulnerável. E isso é tudo! Feito! você é maravilhosa! E os clientes nem perceberão.

Este é realmente um caso muito comum para grandes implantações, e até o OpenVPN tem algumas dificuldades. A compatibilidade com versões anteriores é importante e, embora você use criptografia mais fraca, para muitos isso não causa o fechamento dos negócios. Porque isso levará à paralisia de centenas de clientes devido à incapacidade de fazer seu trabalho.

A equipe do WireGuard tornou seu protocolo mais simples, mas completamente inadequado para pessoas que não têm controle constante sobre os dois pares do túnel. Na minha experiência, este é o cenário mais comum.

Criptografia!

Mas qual é essa nova criptografia interessante que o WireGuard usa?

O WireGuard usa Curve25519 para troca de chaves, ChaCha20 para criptografia e Poly1305 para autenticação de dados. Também funciona com o SipHash para chaves de hash e o BLAKE2 para hash.

O ChaCha20-Poly1305 é padronizado para IPsec e OpenVPN (via TLS).

Obviamente, o desenvolvimento de Daniel Bernstein é usado com muita frequência. O BLAKE2 é o sucessor do BLAKE, o finalista do SHA-3 que não venceu devido à sua semelhança com o SHA-2. Se o SHA-2 fosse hackeado, havia uma alta probabilidade de o BLAKE ser comprometido.

O IPsec e o OpenVPN não precisam do SipHash devido ao seu design. Portanto, a única coisa que não pode ser usada com eles no momento é o BLAKE2, e somente até que seja padronizado. Isso não é uma grande desvantagem, porque as VPNs usam o HMAC para criar integridade, que é considerada uma solução forte mesmo em conjunto com o MD5.

Então, cheguei à conclusão de que todas as VPNs usam quase o mesmo conjunto de ferramentas criptográficas. Portanto, o WireGuard não é mais nem menos seguro do que qualquer outro produto relevante quando se trata de criptografia ou integridade de dados.

Mas mesmo isso não é a coisa mais importante que você deve prestar atenção, de acordo com a documentação oficial do projeto. Afinal, o principal é a velocidade.

O WireGuard é mais rápido que outras soluções VPN?

Em resumo: não, não é mais rápido.

ChaCha20 é uma cifra de fluxo mais fácil de implementar em software. Criptografa um bit de cada vez. Protocolos de bloco, como o AES, criptografam um bloco de 128 bits por vez. Para implementar o suporte a hardware, serão necessários muito mais transistores; portanto, processadores maiores vêm com o AES-NI, uma extensão do conjunto de instruções que executa algumas tarefas do processo de criptografia para acelerá-lo.

Era esperado que a AES-NI nunca chegasse a smartphones [e bateu, - aprox. trans.]. Para isso, o ChaCha20 foi desenvolvido - como uma alternativa fácil e econômica que economiza energia da bateria. Portanto, pode ser novidade para você que todo smartphone que você pode comprar hoje possui uma ou outra aceleração para o AES e trabalha com essa criptografia mais rapidamente e com menos consumo de energia do que com o ChaCha20.

Obviamente, quase todos os processadores de desktop / servidor adquiridos nos últimos dois anos têm AES-NI.

Portanto, espero que a AES ultrapasse o ChaCha20 em todos os cenários. Na documentação oficial do WireGuard, é mencionado que, graças ao AVX512, o ChaCha20-Poly1305 ultrapassará o AES-NI, mas essa extensão do conjunto de comandos estará disponível apenas em processadores grandes, o que novamente não ajudará em equipamentos móveis e menores que sempre trabalharão mais rapidamente com o AES- NI.

Não tenho certeza se isso poderia ter sido previsto durante o desenvolvimento do WireGuard, mas hoje o fato de ele estar pregado em uma criptografia já é uma desvantagem que pode não afetar muito o seu trabalho.

O IPsec permite escolher livremente qual criptografia é melhor para o seu aplicativo. E, claro, isso é necessário se, por exemplo, você deseja transferir 10 ou mais gigabytes de dados por meio de uma conexão VPN.

Problemas de integração do Linux

Embora o WireGuard tenha escolhido um protocolo de criptografia moderno, isso já está causando muitos problemas. E assim, em vez de usar o que é suportado pelo kernel imediatamente, a integração do WireGuard foi adiada por anos devido à falta dessas primitivas no Linux.

Não estou totalmente ciente da situação em outros sistemas operacionais, mas provavelmente não é muito diferente da situação com o Linux.

Como é a realidade?

Infelizmente, toda vez que um cliente me pede para configurar uma conexão VPN para ele, me deparo com o tópico de que eles usam credenciais e criptografia desatualizadas. O 3DES em conjunto com o MD5 ainda é uma prática comum, assim como o AES-256 e o SHA1. E embora o último seja um pouco melhor - isso não é algo que deve ser usado em 2020.

Para troca de chaves , o RSA é sempre usado - uma ferramenta lenta, mas bastante segura.

Meus clientes estão conectados com autoridades alfandegárias e outras organizações e instituições estatais, bem como com grandes corporações, cujos nomes são conhecidos em todo o mundo. Todos eles usam um formulário de solicitação criado décadas atrás, e a capacidade de usar o SHA-512 simplesmente nunca foi adicionada. Não posso dizer que isso de alguma forma afete claramente o progresso tecnológico, mas, obviamente, retarda o processo corporativo.

Dói-me ver isso, porque o IPsec suporta curvas elípticas fora da curva desde o ano de 2005. O Curve25519 também é mais novo e mais acessível. Ainda existem alternativas ao AES, como Camellia e ChaCha20, mas, obviamente, nem todos eles são suportados por grandes fornecedores, como Cisco e outros.

E as pessoas usam isso. Existem muitos kits da Cisco, existem muitos kits projetados para funcionar com a Cisco. Eles são líderes de mercado nesse segmento e não estão muito interessados em nenhuma inovação.

Sim, a situação [no segmento corporativo] é terrível, mas não veremos alterações devido ao WireGuard. É provável que os fabricantes nunca identifiquem nenhum problema de desempenho com as ferramentas e a criptografia já em uso, eles não verão problemas ao usar o IKEv2 - e, portanto, não estão procurando alternativas.

Em geral, você já pensou em abandonar a Cisco?

Benchmarks

Agora vamos passar para os benchmarks da documentação do WireGuard. Embora essa [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 puderem ser reproduzidos e, mais ainda, são inúteis quando obtidos em laboratório.

Na versão do WireGuard para Linux, ele tira proveito do GSO - Generic Segmentation Offloading. Graças a ele, o cliente cria um pacote enorme de tamanho de 64 kilobytes e o criptografa / descriptografa em uma única abordagem. Assim, o custo de chamar e implementar operações criptográficas é reduzido. Se você deseja maximizar a largura de banda da sua conexão VPN, é uma boa ideia.

Mas, como sempre, na realidade não é tão simples. O envio de um pacote tão grande para um adaptador de rede exige que ele seja dividido em muitos pacotes menores. O tamanho típico de envio é de 1.500 bytes. Ou seja, nossos 64 kilobytes gigantes serão divididos em 45 pacotes (1240 bytes de informação e 20 bytes de cabeçalho IP). Por um tempo, eles bloqueiam completamente a operação do adaptador de rede, porque devem ser enviados juntos e imediatamente. Como resultado, isso levará a um salto de prioridade e pacotes como, por exemplo, VoIP, serão enfileirados.

Assim, a alta taxa de transferência, que o WireGuard afirma com tanta ousadia, é alcançada diminuindo a velocidade da operação de rede de outros aplicativos. E a equipe do WireGuard já confirmou esta conclusão minha.

Mas vamos seguir em frente.

De acordo com os parâmetros de referência na documentação técnica, a conexão mostra uma largura de banda de 1011 Mbit / s.

Impressionante.

Isso é especialmente impressionante porque a largura de banda máxima teórica de uma conexão Ethernet de gigabit é 966 Mbps com um tamanho de pacote de 1.500 bytes menos 20 bytes por cabeçalho IP, 8 bytes por cabeçalho UDP e 16 bytes por cabeçalho de fio. . Há outro cabeçalho IP no pacote encapsulado e outro no TCP de 20 bytes. Então, de onde veio essa largura de banda extra?

Com os enormes quadros e vantagens do GSO, sobre os quais falamos acima, o máximo teórico com um tamanho de quadro de 9000 bytes será 1014 Mbit / s. Geralmente, esse rendimento é inatingível na realidade, porque está associado a grandes dificuldades. Portanto, posso apenas assumir que o teste foi realizado usando quadros ainda mais ousados, excedendo o tamanho de 64 kilobytes com um máximo teórico de 1023 Mbps, suportado apenas por alguns adaptadores de rede. Mas isso não é absolutamente aplicável em condições reais ou pode ser usado apenas entre duas estações conectadas diretamente uma à outra, exclusivamente dentro do banco de ensaio.

Porém, como o túnel da VPN é encaminhado entre dois hosts usando uma conexão à Internet que não suporta quadros grandes, o resultado alcançado no estande não pode ser tomado como padrão. Isso é simplesmente uma conquista irrealista de laboratório, impossível e não aplicável em condições reais de combate.

Mesmo sentado no data center, eu não seria capaz de transferir quadros maiores que 9000 bytes.

O critério de aplicabilidade na vida real é completamente violado e, como penso, o autor da "medida" se desacreditou seriamente por razões óbvias.

O último vislumbre de esperança

O site da WireGuard fala muito sobre contêineres e fica claro para o que realmente se destina.

Uma VPN simples e rápida que não requer configuração e pode ser implantada e configurada com ferramentas de orquestração massivas, como a Amazon em sua nuvem. Especificamente, a Amazon usa os recursos de hardware mais recentes que mencionei anteriormente, por exemplo - AVX512. Isso é feito para acelerar o trabalho e não estar vinculado ao x86 ou a qualquer outra arquitetura.

Eles otimizam a largura de banda e os pacotes cujo tamanho excede 9000 bytes - isso resultará em enormes quadros encapsulados para a comunicação de contêineres entre si ou para operações de backup, criando instantâneos ou implementando esses contêineres. Mesmo endereços IP dinâmicos não afetarão a operação do WireGuard no caso do cenário que descrevi.

Não é ruim jogado. Implementação brilhante e um protocolo muito fino, quase de referência.

Mas isso simplesmente não é adequado para o mundo fora do data center que você controla completamente. Se você correr o risco e começar a usar o WireGuard, terá que fazer compromissos constantes no desenvolvimento e na implementação do protocolo de criptografia.

Conclusão

É fácil concluir que o WireGuard ainda não está pronto.

Foi concebida como uma solução leve e rápida para vários problemas com as soluções existentes. Infelizmente, por causa dessas soluções, ele sacrificou muitos recursos que serão 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. Obviamente, é para isso que os canais criptografados são necessários.

A segurança é minha principal prioridade e, no momento, não tenho motivos para acreditar que o IKE ou TLS esteja de alguma forma comprometido ou quebrado. A criptografia moderna é suportada em ambos, e eles foram testados por décadas de operação. Se algo mais novo não significa que é algo, é melhor.

A interoperabilidade é crucial quando você entra em contato com terceiros cujas estações você não controla. IPsec é o padrão de fato e é suportado quase universalmente. E isso funciona. E, independentemente da aparência, em teoria, o WireGuard no futuro pode não ser compatível, mesmo com versões diferentes de si mesmo.

Qualquer proteção criptográfica é invadida mais cedo ou mais tarde e, portanto, deve ser substituída ou atualizada.

Negar todos esses fatos e querer cegamente usar o WireGuard para conectar seu iPhone à estação de trabalho em casa é apenas uma oficina sobre enfiar a cabeça na areia.

Por que você não deve usar o WireGuard