🍈 👨‍👩‍👧 👩🏾 Por qué no deberías usar WireGuard 👨🏼‍🎤 🆓 🧦

Recientemente, WireGuard atrae mucha atención, de hecho, esta es una nueva "estrella" entre las VPN. ¿Pero es tan bueno como parece? Me gustaría discutir algunas observaciones y considerar la implementación de WireGuard para explicar por qué no es una solución que reemplace IPsec u OpenVPN.

En este artículo, me gustaría desacreditar algunos mitos [en torno a WireGuard]. Sí, tomará mucho tiempo leerlo, así que si no ha preparado una taza de té o café, entonces es hora de hacerlo. También me gustaría agradecer a Peter por corregir mis pensamientos caóticos.

No me propongo el objetivo de desacreditar a los desarrolladores de WireGuard, de devaluar sus esfuerzos o ideas. Su producto funciona, pero personalmente creo que se presenta completamente diferente de lo que realmente es: se presenta como un reemplazo para IPsec y OpenVPN, que en realidad ahora simplemente no existe.

Como nota, quiero agregar que la responsabilidad de tal posicionamiento de WireGuard recae en los medios que hablaron sobre él, y no en el proyecto en sí o sus creadores.

No ha habido demasiadas buenas noticias sobre el tema del kernel de Linux últimamente. Entonces, nos dijeron sobre las monstruosas vulnerabilidades del procesador, que fueron niveladas por el software, y Linus Torvalds habló sobre el lenguaje utilitario demasiado grosero y aburrido del desarrollador. Programador o nivel cero de la pila de red: tampoco temas demasiado claros para revistas brillantes. Y luego aparece WireGuard.

Todo suena genial en papel: una nueva tecnología emocionante.

Pero echemos un vistazo a ella un poco más cuidadosamente.

Documentación técnica de WireGuard

Este artículo se basa en la documentación oficial de WireGuard escrita por Jason Donenfeld. Allí explica el concepto, el propósito y la implementación técnica de [WireGuard] en el kernel de Linux.

La primera oración dice:

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

Por supuesto, la principal ventaja de todas las nuevas tecnologías es su simplicidad [en comparación con sus predecesores]. Pero una VPN también debe ser eficiente y segura .

Entonces, ¿qué sigue?

Si dice que [de la VPN] no necesita esto, puede finalizar la lectura. Sin embargo, notaré que tales tareas se plantean antes que cualquier otra tecnología de túnel.

La más interesante de las citas anteriores radica en las palabras "en la mayoría de los casos", que, por supuesto, fueron ignoradas por la prensa. Y aquí estamos, donde terminamos debido al caos creado por esta negligencia, en este artículo.

¿WireGuard reemplazará mi conexión VPN [IPsec] entre sitios?

No. Simplemente no hay posibilidad de que grandes proveedores como Cisco, Juniper y otros compren WireGuard para sus productos. No "saltan los trenes" sobre la marcha, a menos que sea muy necesario. Más adelante hablaré sobre algunas de las razones por las cuales probablemente no podrían instalar los productos WireGuard a bordo, incluso si quisieran.

¿WireGuard transferirá mi RoadWarrior de una computadora portátil a un centro de datos?

No. WireGuard no ha implementado una gran cantidad de funciones importantes en este momento para que pueda hacer algo como esto. Por ejemplo, no puede usar la dirección IP dinámica en el lado del servidor del túnel, y esto solo rompe todo el escenario de un uso similar del producto.

IPFire se usa a menudo para canales de Internet de bajo costo, como DSL o conexión por cable. Esto tiene sentido para una pequeña o mediana empresa que no necesita fibra rápida.[Nota del traductor: no olvide que, en términos de comunicaciones, Rusia y algunos países de la CEI están muy por delante de Europa y Estados Unidos, porque comenzamos a construir nuestras redes mucho más tarde y con el advenimiento de las redes Ethernet y de fibra óptica como estándar, nos fue más fácil reconstruir. En los mismos países de la UE o EE. UU., El acceso de banda ancha xDSL a una velocidad de 3-5 Mbps sigue siendo la norma universal, y la conexión de fibra óptica cuesta algo de dinero poco realista según nuestros estándares. Por lo tanto, el autor del artículo habla de DSL o conexión de cable como normal, en lugar del pasado antiguo.] Sin embargo, DSL, cable, LTE (y otros métodos de acceso inalámbrico) tienen direcciones IP dinámicas. Por supuesto, a veces no cambian a menudo, pero aún cambian.

Hay un subproyecto llamado "wg-dynamic"El espacio de usuario daemon se agrega para superar esta deficiencia. Un gran problema con el escenario de usuario descrito anteriormente es el agravamiento de la situación mediante el direccionamiento dinámico IPv6.

Desde el punto de vista del distribuidor, todo esto tampoco se ve muy bien. Uno de los objetivos de diseño era mantener el protocolo simple y limpio.

Desafortunadamente, todo esto se volvió demasiado simple y primitivo, por lo que tenemos que usar software adicional para hacer viable todo este diseño en condiciones de la vida real.

¿WireGuard es tan fácil de usar?

Aún no. No digo que WireGuard nunca sea una buena alternativa para reenviar un túnel entre dos puntos, pero hasta ahora es solo una versión alfa del producto en el que debería convertirse.

Pero entonces, ¿qué hace realmente? ¿IPsec es realmente mucho más difícil de operar?

Obviamente no. El proveedor de IPsec ha considerado este punto y está entregando su producto junto con una interfaz como IPFire.

Para configurar un túnel VPN a través de IPsec, necesitará cinco conjuntos de datos que deberá ingresar en la configuración: su propia dirección IP pública, la dirección IP pública del lado receptor, subredes que desea hacer públicas a través de esta conexión VPN y previamente compartidas llave. Por lo tanto, la VPN se configura en unos minutos y es compatible con cualquier proveedor.

Desafortunadamente, hay algunas excepciones a esta historia. Todos los que intentaron reenviar un túnel VPN a través de IPsec a una máquina en OpenBSD entienden de lo que estoy hablando. Hay un par de ejemplos más dolorosos, pero de hecho, la buena práctica de usar IPsec es mucho, mucho más.

Sobre la complejidad del protocolo

El usuario final no tiene que preocuparse por la complejidad del protocolo.

Si viviéramos en un mundo donde esta era la verdadera preocupación del usuario, hace mucho tiempo nos habríamos librado de SIP, H.323, FTP y otros protocolos creados hace más de diez años que no funcionan bien con NAT.

Hay razones por las que IPsec es más complicado que WireGuard: hace mucho más. Por ejemplo, autenticación de usuario utilizando un nombre de usuario / contraseña o tarjeta SIM con EAP. Tiene la capacidad ampliada de agregar nuevas primitivas criptográficas .

Pero WireGuard no lo hace.

Y esto significa que WireGuard se romperá en algún momento, porque una de las primitivas criptográficas se debilitará o se verá completamente comprometida. El autor de la documentación técnica dice esto:

Vale la pena señalar que WireGuard es criptográficamente seguro de sí mismo. Carece intencionalmente de la flexibilidad de cifrados y protocolos. Si se encuentran agujeros serios en las primitivas subyacentes, todos los puntos finales deberán actualizarse. Como puede ver en el flujo continuo de vulnerabilidades SLL / TLS, la flexibilidad de cifrado ahora ha aumentado enormemente.

La última oración es absolutamente cierta.

Crear consenso sobre qué cifrado usar hace que protocolos como IKE y TLS sean más complejos. ¿Demasiado complicado? Sí, las vulnerabilidades son bastante comunes en TLS / SSL, y no hay alternativa a ellas.

Sobre ignorar problemas reales

Imagina que tienes un servidor VPN con 200 clientes de combate, en algún lugar del mundo. Este es un caso de uso muy estándar. Si tiene que cambiar el cifrado, debe entregar la actualización a todas las copias de WireGuard en estas computadoras portátiles, teléfonos inteligentes, etc. Entregar al mismo tiempo . Es literalmente imposible. A los administradores que intenten hacerlo estos meses les llevará implementar las configuraciones necesarias, y las empresas medianas literalmente tardarán años en organizar tal evento.

IPsec y OpenVPN ofrecen negociación de cifrado. Por lo tanto, algún tiempo después de que habilite el nuevo cifrado, el antiguo funcionará. Gracias a esto, los clientes actuales podrán actualizar a la nueva versión. Una vez que se implementa la actualización, simplemente apaga el cifrado vulnerable. ¡Y eso es todo! ¡Hecho! ¡eres guapisima! Y los clientes ni siquiera lo notarán.

Este es realmente un caso muy común para implementaciones grandes, e incluso OpenVPN tiene algunas dificultades. La compatibilidad con versiones anteriores es importante, y aunque utilice un cifrado más débil, para muchos esto no causa el cierre del negocio. Porque conducirá a la parálisis de cientos de clientes debido a la incapacidad de hacer su trabajo.

El equipo de WireGuard ha simplificado su protocolo, pero es completamente inadecuado para las personas que no tienen control constante sobre ambos pares de su túnel. En mi experiencia, este es el escenario más común.

¡Criptografía!

Pero, ¿cuál es este nuevo cifrado interesante que utiliza WireGuard?

WireGuard utiliza Curve25519 para el intercambio de claves, ChaCha20 para el cifrado y Poly1305 para la autenticación de datos. También funciona con SipHash para las claves hash y BLAKE2 para el hash.

ChaCha20-Poly1305 está estandarizado para IPsec y OpenVPN (a través de TLS).

Obviamente, el desarrollo de Daniel Bernstein se usa con mucha frecuencia. BLAKE2 es el sucesor de BLAKE, el finalista de SHA-3 que no ganó debido a su parecido con SHA-2. Si SHA-2 fuera pirateado, había una alta probabilidad de que BLAKE se viera comprometido.

IPsec y OpenVPN no necesitan SipHash debido a su diseño. Por lo tanto, lo único que no se puede usar con ellos en este momento es BLAKE2, y solo hasta que esté estandarizado. Esto no es un gran inconveniente, porque las VPN usan HMAC para crear integridad, lo que se considera una solución sólida incluso en combinación con MD5.

Entonces llegué a la conclusión de que todas las VPN usan casi el mismo conjunto de herramientas criptográficas. Por lo tanto, WireGuard no es más ni menos seguro que cualquier otro producto relevante cuando se trata de cifrado o integridad de datos.

Pero incluso esto no es lo más importante a lo que debe prestar atención de acuerdo con la documentación oficial del proyecto. Después de todo, lo principal es la velocidad.

¿WireGuard es más rápido que otras soluciones VPN?

En resumen: no, no más rápido.

ChaCha20 es un cifrado de flujo que es más fácil de implementar en software. Cifra un bit a la vez. Los protocolos de bloque, como AES, encriptan un bloque de 128 bits a la vez. Para implementar el soporte de hardware, se requerirán muchos más transistores, por lo tanto, los procesadores más grandes vienen con AES-NI, una extensión del conjunto de instrucciones que realiza algunas tareas del proceso de cifrado para acelerarlo.

Se esperaba que AES-NI nunca llegara a los teléfonos inteligentes [y golpeó, - aprox. trans.]. Para esto, se desarrolló el ChaCha20, como una alternativa fácil y económica que ahorra batería. Por lo tanto, puede ser una novedad para usted que cada teléfono inteligente que pueda comprar hoy tenga una u otra aceleración para AES y funcione con este cifrado más rápido y con menos consumo de energía que con ChaCha20.

Obviamente, casi todos los procesadores de escritorio / servidor comprados en los últimos años tienen AES-NI.

Por lo tanto, espero que AES supere a ChaCha20 en cada escenario. La documentación oficial de WireGuard menciona que gracias al AVX512, el ChaCha20-Poly1305 superará a AES-NI, pero esta extensión de conjunto de comandos solo estará disponible en procesadores grandes, lo que nuevamente no ayudará con equipos más pequeños y móviles que siempre funcionarán más rápido con AES- NI.

No estoy seguro de si esto podría haberse previsto durante el desarrollo de WireGuard, pero hoy el hecho de que esté enclavado en un cifrado ya es un inconveniente que puede no afectar muy bien su trabajo.

IPsec le permite elegir libremente qué cifrado es mejor para su aplicación. Y, por supuesto, esto es necesario si, por ejemplo, desea transferir 10 o más gigabytes de datos a través de una conexión VPN.

Problemas de integración de Linux

Aunque WireGuard ha elegido un protocolo de cifrado moderno, esto ya está causando muchos problemas. Y así, en lugar de usar lo que es compatible con el núcleo de fábrica, la integración de WireGuard se ha retrasado durante años debido a la falta de estas primitivas en Linux.

No estoy completamente consciente de la situación en otros sistemas operativos, pero probablemente no es muy diferente de la situación con Linux.

¿Cómo se ve la realidad?

Desafortunadamente, cada vez que un cliente me pide que configure una conexión VPN para él, me encuentro con el tema de que usan credenciales y cifrado obsoletos. 3DES junto con MD5 sigue siendo una práctica común, como lo son AES-256 y SHA1. Y aunque este último es un poco mejor, esto no es algo para usar en 2020.

Para el intercambio de claves , siempre se usa RSA, una herramienta lenta pero bastante segura.

Mis clientes están conectados con las autoridades aduaneras y otras organizaciones e instituciones estatales, así como con grandes corporaciones, cuyos nombres son conocidos en todo el mundo. Todos usan un formulario de solicitud creado hace décadas, y la capacidad de usar SHA-512 simplemente nunca se agregó. No puedo decir que esto de alguna manera afecte claramente el progreso tecnológico, pero obviamente ralentiza el proceso corporativo.

Me duele ver esto, porque IPsec ha admitido curvas elípticas fuera de la curva desde el año 2005. Curve25519 también es más nuevo y más accesible. Todavía hay alternativas a AES, como Camellia y ChaCha20, pero, obviamente, no todas son compatibles con grandes proveedores, como Cisco y otros.

Y la gente lo usa. Hay muchos kits de Cisco; hay muchos kits diseñados para funcionar con Cisco. Son líderes del mercado en este segmento y no están muy interesados en ninguna innovación.

Sí, la situación [en el segmento corporativo] es terrible, pero no veremos ningún cambio debido a WireGuard. Es probable que los fabricantes nunca identifiquen ningún problema de rendimiento con las herramientas y el cifrado que ya están en uso, no verán problemas al usar IKEv2 y, por lo tanto, no están buscando alternativas.

En general, ¿alguna vez has pensado en abandonar Cisco?

Puntos de referencia

Ahora pasemos a los puntos de referencia de la documentación de WireGuard. Aunque esta [documentación] no es un artículo científico, todavía esperaba que los desarrolladores adoptaran un enfoque más científico o utilizaran un enfoque científico como referencia. Cualquier punto de referencia es inútil si no puede reproducirse, y aún más, es inútil cuando se obtiene en el laboratorio.

En la compilación WireGuard para Linux, aprovecha la GSO - Descarga de segmentación genérica. Gracias a él, el cliente crea un gran paquete de 64 kilobytes de tamaño y lo cifra / descifra en un solo enfoque. Por lo tanto, se reduce el costo de llamar e implementar operaciones criptográficas. Si desea maximizar el ancho de banda de su conexión VPN, esta es una buena idea.

Pero, como siempre, en realidad no es tan simple. Enviar un paquete tan grande a un adaptador de red requiere que se corte en muchos paquetes más pequeños. El tamaño de envío típico es de 1.500 bytes. Es decir, nuestros 64 kilobytes gigantes se dividirán en 45 paquetes (1240 bytes de información y 20 bytes de encabezado IP). Luego, durante un tiempo, bloquean completamente el funcionamiento del adaptador de red, ya que deben enviarse juntos e inmediatamente. Como resultado, esto dará lugar a un salto en la prioridad, y los paquetes como, por ejemplo, VoIP, se pondrán en cola.

Por lo tanto, el alto rendimiento, que WireGuard afirma tan audazmente, se logra al ralentizar el funcionamiento de la red de otras aplicaciones. Y el equipo de WireGuard ya ha confirmado esta conclusión mía.

Pero sigamos adelante.

Según los puntos de referencia en la documentación técnica, la conexión muestra un ancho de banda de 1011 Mbit / s.

Impresionante.

Esto es especialmente impresionante porque el ancho de banda teórico máximo de una conexión Ethernet de un gigabit es de 966 Mbit / s con un tamaño de paquete de 1,500 bytes menos 20 bytes por encabezado IP, 8 bytes por encabezado UDP y 16 bytes por encabezado de cable. . Hay otro encabezado IP en el paquete encapsulado y otro en TCP de 20 bytes. Entonces, ¿de dónde viene este ancho de banda adicional?

Con las enormes tramas y ventajas de GSO, de las que hablamos anteriormente, el máximo teórico con un tamaño de trama de 9000 bytes será de 1014 Mbit / s. Por lo general, dicho rendimiento es inalcanzable en realidad, porque está asociado con grandes dificultades. Por lo tanto, solo puedo suponer que la prueba se realizó con marcos aún más en negrita que exceden el tamaño de 64 kilobytes con un máximo teórico de 1023 Mbit / s, que solo es compatible con algunos adaptadores de red. Pero esto no es absolutamente aplicable en condiciones reales, o puede usarse solo entre dos estaciones conectadas directamente entre sí, exclusivamente dentro del banco de pruebas.

Pero dado que el túnel VPN se reenvía entre dos hosts utilizando una conexión a Internet que no admite tramas grandes, el resultado logrado en el stand no puede tomarse como estándar. Esto es simplemente un logro de laboratorio poco realista, que es imposible y no aplicable en condiciones reales de combate.

Incluso sentado en el centro de datos, no podría transferir marcos de más de 9000 bytes.

El criterio de aplicabilidad en la vida real se viola por completo y, según creo, el autor de la "medición" se desacreditó seriamente por razones obvias.

El último rayo de esperanza

El sitio web de WireGuard habla mucho sobre los contenedores y queda claro a qué está destinado realmente.

Una VPN simple y rápida que no requiere ninguna configuración y se puede implementar y configurar con herramientas de orquestación masivas, como las de Amazon en su nube. Específicamente, Amazon utiliza las últimas funciones de hardware que mencioné anteriormente, por ejemplo, AVX512. Esto se hace para acelerar el trabajo y no estar vinculado a x86 ni a ninguna otra arquitectura.

Optimizan el ancho de banda y los paquetes cuyo tamaño excede los 9000 bytes; esto dará como resultado enormes marcos encapsulados para comunicar contenedores entre sí, o para operaciones de copia de seguridad, crear instantáneas o implementar estos contenedores. Incluso las direcciones IP dinámicas no afectarán el funcionamiento de WireGuard en el caso del escenario que describí.

No está mal jugado. Implementación brillante y un protocolo muy delgado, casi de referencia.

Pero simplemente no es adecuado para el mundo fuera del centro de datos que usted controla por completo. Si se arriesga y comienza a usar WireGuard, deberá comprometerse constantemente en el desarrollo y la implementación del protocolo de cifrado.

Conclusión

Para mí es fácil concluir que WireGuard aún no está listo.

Fue concebido como una solución ligera y rápida para una serie de problemas con las soluciones existentes. Desafortunadamente, por el bien de estas soluciones, sacrificó muchas características que serán relevantes para la mayoría de los usuarios. Es por eso que no puede reemplazar IPsec u OpenVPN.

Para que WireGuard sea competitivo, necesita agregar al menos la configuración de la dirección IP y la configuración de enrutamiento y DNS. Obviamente, esto es para lo que se necesitan los canales encriptados.

La seguridad es mi principal prioridad, y en este momento no tengo ninguna razón para creer que IKE o TLS estén de alguna manera comprometidos o quebrados. El cifrado moderno es compatible con ambos, y se han probado durante décadas de funcionamiento. Si algo más nuevo no significa que es algo, es mejor.

La interoperabilidad es crucial cuando contacta a terceros cuyas estaciones no controla. IPsec es el estándar de facto y es compatible casi universalmente. Y funciona. Y no importa cómo se vea, en teoría, WireGuard en el futuro puede no ser compatible incluso con diferentes versiones de sí mismo.

Cualquier protección criptográfica se piratea tarde o temprano y, en consecuencia, debe reemplazarse o actualizarse.

Negar todos estos hechos y desear ciegamente usar WireGuard para conectar su iPhone a la estación de trabajo de su hogar es solo un taller sobre cómo meter la cabeza en la arena.

Por qué no deberías usar WireGuard