Recientemente, WireGuard ha estado atrayendo mucha atención, de hecho, es la nueva "estrella" entre VPN. Pero, ¿es tan bueno como parece? Me gustaría discutir algunas observaciones y examinar la implementación de WireGuard para explicar por qué no es una solución que reemplace a IPsec o OpenVPN.
En este artículo, me gustaría desmentir algunos mitos [alrededor de WireGuard]. Sí, hay que leer mucho, así que si aún no te has preparado una taza de té o café, es el momento de hacerlo. Además, quisiera agradecer a Peter por revisar mis pensamientos caóticos.
No tengo la intención de desacreditar a los desarrolladores de WireGuard, ni de devaluar sus esfuerzos o ideas. Su producto es funcional, pero personalmente creo que se presenta de una manera completamente diferente a lo que realmente es: se presenta como un reemplazo de IPsec y OpenVPN, que en realidad no existe en este momento.
Como nota, quiero agregar que la responsabilidad de tal posicionamiento de WireGuard recae en los medios, que han hablado de él, y no en el propio proyecto o sus creadores.
Recientemente, no ha habido muchas buenas noticias sobre el núcleo de Linux. Se nos han informado sobre vulnerabilidades enormes en los procesadores que se han mitigado de forma programática, y Linus Torvalds ha comentado al respecto de manera demasiado grosera y aburrida, en el lenguaje utilitario de un desarrollador. El planificador o el stack de red de nivel cero tampoco son temas muy comprensibles para revistas de actualidad. Y aquí aparece WireGuard.
Sobre el papel, todo suena genial: una nueva tecnología que fascina la imaginación.
Pero echemos un vistazo más de cerca.
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 objetivo y la implementación técnica de [WireGuard] en el núcleo de Linux.
La primera frase dice:
WireGuard […] busca reemplazar tanto a IPsec en la mayoría de los casos de uso, como a otras soluciones populares basadas en espacio de usuario y/o TLS, como OpenVPN, siendo a la vez una [herramienta] más segura, eficiente y fácil de usar.
Por supuesto, la principal ventaja de todas las nuevas tecnologías es su simplicidad [en comparación con los predecesores]. Pero un VPN también debe ser efectivo y seguro.
¿Y qué sigue?
Si dices que no necesitas esto de [VPN], entonces aquí termina la lectura. Sin embargo, debo señalar que tales tareas se presentan ante cualquier otra tecnología de túnel.
Lo más interesante de la cita anterior está en las palabras 'en la mayoría de los casos', que, por supuesto, fueron ignoradas por la prensa. Y aquí estamos, donde llegamos debido al caos creado por esta negligencia, en este artículo.
¿Se convertirá WireGuard en un reemplazo de mi conexión VPN [IPsec] entre sitios?
No. Simplemente no hay forma de que grandes proveedores, como Cisco, Juniper y otros, adquieran WireGuard para sus productos. No 'saltarían a trenes que pasan' a mitad de camino, a menos que haya una gran necesidad. Más adelante hablaré sobre algunas razones por las que probablemente no podrán implementar WireGuard en sus productos, incluso si quisieran.
¿Transportará WireGuard mi RoadWarrior de la laptop al centro de datos?
No. En este momento, WireGuard carece de muchas funciones importantes para lograr algo así. Por ejemplo, no puede utilizar una dirección IP dinámica en el lado del servidor del túnel, y solo esto rompe todo el escenario de uso del producto.
IPFire se utiliza a menudo para canales de Internet económicos, como DSL o conexiones por cable. Esto tiene sentido para pequeñas o medianas empresas que no necesitan fibra óptica rápida. [Nota del traductor: no hay que olvidar que en términos de conectividad, Rusia y algunos países de la CEI están muy por delante de Europa y los Estados Unidos, porque comenzamos a construir nuestras redes mucho más tarde y con la llegada de Ethernet y redes de fibra óptica como estándar, nos fue más fácil adaptarnos. En los mismos países de la UE o EE. UU., el acceso de banda ancha xDSL a velocidades de 3-5 Mbit/s sigue siendo la norma general, y la conexión de fibra óptica cuesta precios irrealmente altos según nuestros estándares. Por eso, el autor del artículo se refiere a las conexiones DSL o por cable como la norma, y no como antigüedades.] Sin embargo, DSL, cable, LTE (y otros métodos de acceso inalámbrico) tienen direcciones IP dinámicas. Por supuesto, a veces no cambian con frecuencia, pero aún así cambian.
Hay un subproyecto llamado «wg-dynamic», que agrega un demonio de espacio de usuario para superar esta limitación. Un gran problema del caso de uso del usuario mencionado anteriormente es la agravación de la situación por la dirección dinámica de IPv6.
Desde el punto de vista del distribuidor, todo esto tampoco se ve muy bien. Uno de los objetivos del desarrollo fue mantener la simplicidad y la claridad del protocolo.
Desafortunadamente, todo esto se ha vuelto demasiado simple y primitivo, por lo que tenemos que usar software adicional para que toda esta estructura sea viable en condiciones de explotación real.
¿Es realmente fácil usar WireGuard?
Por ahora, no. No digo que WireGuard nunca será una buena alternativa para el túnel entre dos puntos, pero por ahora es solo una versión alfa del producto que debe ser.
Pero, ¿qué es lo que realmente hace? ¿Es realmente IPSec mucho más complicado de operar?
Obviamente que no. El proveedor de IPSec ha pensado en esto y proporciona su producto junto con una interfaz, por ejemplo, con IPFire.
Para configurar un túnel VPN a través de IPSec necesitarás cinco conjuntos de datos que debes ingresar en la configuración: tu propia dirección IP pública, la dirección IP pública de la parte receptora, las subredes que deseas hacer públicas a través de esta conexión VPN y la clave precompartida. De este modo, la VPN se configura en unos pocos minutos y es compatible con cualquier proveedor.
Desafortunadamente, hay algunas excepciones en esta historia. Cualquiera que haya intentado establecer un túnel VPN a través de IPSec a una máquina en OpenBSD sabe de lo que estoy hablando. Hay un par de ejemplos dolorosos más, pero en realidad hay muchas más prácticas positivas en el uso de IPSec.
Sobre la complejidad del protocolo
El consumidor final no debería preocuparse por la complejidad del protocolo.
Si viviéramos en un mundo donde eso fuera una preocupación real para el usuario, ya habríamos dejado de lado SIP, H.323, FTP y otros protocolos creados hace más de diez años que funcionan mal con NAT.
Hay razones por las que IPSec es más difícil que WireGuard: hace muchas más cosas. Por ejemplo, la autenticación del usuario mediante nombre de usuario/contraseña o tarjeta SIM con EAP. Tiene la capacidad extendida de agregar nuevos primitivos criptográficos.
Y WireGuard no tiene eso.
Y eso significa que WireGuard, en algún momento, fallará, porque uno de los primitivas criptográficos se debilitará o será completamente comprometido. El autor de la documentación técnica dice esto de la siguiente manera:
Cabe destacar que WireGuard es criptográficamente confiado. Le falta intencionalmente la flexibilidad de cifrados y protocolos. Si se descubren fallas graves en los primitivas subyacentes, será necesario actualizar todos los puntos finales. Como se puede ver en el continuo goteo de vulnerabilidades de SSL/TLS, la flexibilidad de cifrado ha aumentado enormemente en la actualidad.
La última afirmación es absolutamente correcta.
Alcanzar un consenso sobre qué cifrado utilizar hace que protocolos como IKE y TLS sean más de complejos. ¿Demasiado complejos? Sí, en TLS/SSL, las vulnerabilidades ocurren con bastante frecuencia, y no hay alternativas.
Sobre ignorar problemas reales
Imagina que tienes un servidor VPN con 200 clientes activos en todo el mundo. Este es un escenario de uso bastante estándar. Si tienes que cambiar el cifrado, necesitarás desplegar una actualización en todas las copias de WireGuard en estos portátiles, teléfonos inteligentes, etc. Simultáneamente desplegar. Esto es literalmente imposible. A los administradores que intenten hacerlo les llevará meses desplegar las configuraciones necesarias, y a las empresas promedio literalmente les llevará años realizar tal empresa.
IPsec y OpenVPN ofrecen la función de negociación de cifrados. Por lo tanto, durante un tiempo, después de activar el nuevo cifrado, también funcionará el antiguo. Gracias a esto, los clientes actuales podrán actualizar a la nueva versión. Una vez que se haya desplegado la actualización, simplemente desactivarás el cifrado vulnerable. ¡Y ya está! ¡Listo! ¡Eres increíble! Y ni siquiera lo notarán los clientes.
De hecho, este es un caso muy común para grandes despliegues, e incluso OpenVPN enfrenta algunas dificultades en esto. La compatibilidad hacia atrás es importante, y aunque utilices cifrados más débiles, para muchos esto no resulta en el cierre del negocio. Porque esto llevaría a la paralización del trabajo de cientos de clientes debido a la incapacidad de realizar su trabajo.
El equipo de WireGuard ha simplificado su protocolo, pero es completamente inapropiado para personas que no tienen control constante sobre ambos pares de su túnel. Según mi experiencia, este escenario es el más común.
¡Criptografía!
Pero, ¿qué es este interesante nuevo cifrado 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 trabaja con SipHash para claves hash y BLAKE2 para el hashing.
ChaCha20-Poly1305 está estandarizado para IPsec y OpenVPN (a través de TLS).
Es evidente que el trabajo de Daniel Bernstein se utiliza con mucha frecuencia. BLAKE2 es el sucesor de BLAKE, finalista de SHA-3, que no ganó debido a su similitud con SHA-2. Si SHA-2 fuese comprometido, habría una alta probabilidad de que BLAKE también esté comprometido.
IPsec y OpenVPN no requieren SipHash debido a su diseño. Por lo tanto, lo único que actualmente no se puede utilizar con ellos es BLAKE2, y solo hasta que sea estandarizado. Esto no es un gran inconveniente, ya que las VPN utilizan HMAC para garantizar la integridad, lo cual se considera una solución robusta incluso en combinación con MD5.
Así llegué a la conclusión de que prácticamente todas las VPN utilizan el mismo conjunto de herramientas criptográficas. Así que WireGuard no es más ni menos seguro que cualquier otro producto actual en términos de cifrado o integridad de los datos transmitidos.
Pero ni siquiera eso es lo más importante en lo que debemos centrarnos según la documentación oficial del proyecto. Lo principal es la velocidad.
¿Es WireGuard más rápido que otras soluciones de VPN?
En resumen: no, no es más rápido.
ChaCha20 es un cifrador por flujo, que es más fácil de implementar en software. Cifra un bit a la vez. Los protocolos de bloque, como AES, cifran bloques de 128 bits a la vez. Implementar soporte de hardware requiere muchos más transistores, por lo que 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 [pero ha llegado, nota del traductor]. Para esto, se desarrolló ChaCha20 como una alternativa ligera y económica, que ahorra la batería. Por lo tanto, puede ser una sorpresa para usted que cada teléfono inteligente que puede comprar hoy en día tiene alguna forma de aceleración para AES y funciona con este cifrado más rápido y con menos consumo de energía que con ChaCha20.
Es evidente que prácticamente todos los procesadores para PC de escritorio / servidores comprados en los últimos par de años tienen AES-NI.
Por lo tanto, espero que AES supere a ChaCha20 en cada escenario particular. En la documentación oficial de WireGuard se menciona que gracias a AVX512, ChaCha20-Poly1305 superará a AES-NI, pero esta extensión del conjunto de instrucciones solo estará disponible en los procesadores de gama alta, lo cual, nuevamente, no ayudará con el hardware más pequeño y móvil, que siempre funcionará más rápido con AES-NI.
No estoy seguro de si esto se previó al desarrollar WireGuard, pero hoy en día, el hecho de que esté atado a un solo cifrado ya es una desventaja que podría afectar negativamente su rendimiento.
IPsec permite elegir libremente qué cifrado se adapta mejor a su caso. Y por supuesto, esto es necesario si, por ejemplo, desea transferir 10 gigabytes o más de datos a través de una conexión VPN.
Problemas de integración en Linux
Aunque WireGuard eligió un protocolo de cifrado moderno, esto ya está causando muchos problemas. Y así, en lugar de utilizar lo que es compatible con el núcleo de forma predeterminada, la integración de WireGuard se ha pospuesto durante años debido a la falta de estos primitivos en Linux.
No estoy completamente al tanto de cómo es la situación en otros sistemas operativos, pero probablemente no sea muy diferente a la situación en Linux.
¿Cómo es la realidad?
Desafortunadamente, cada vez que un cliente me pide que configure una conexión VPN, me encuentro con el tema de que utilizan credenciales y cifrados obsoletos. 3DES junto con MD5 sigue siendo una práctica común, al igual que AES-256 y SHA1. Y aunque este último es un poco mejor, no es algo de lo que debería depender en 2020.
Para el intercambio de claves siempre se utiliza RSA, una herramienta lenta pero suficientemente segura.
Mis clientes están relacionados con las autoridades aduaneras y otros organismos y entidades gubernamentales, así como con grandes corporaciones cuyos nombres son conocidos en todo el mundo. Todos ellos utilizan un formulario de solicitud que fue creado hace décadas, y la posibilidad de utilizar SHA-512 simplemente nunca se añadió. No puedo decir que esto influya de manera evidente en el progreso tecnológico, pero está claro que ralentiza los procesos corporativos.
Me duele verlo, porque IPsec ha soportado curvas elípticas desde alrededor de 2005. Curve25519 también es más nuevo y está disponible para su uso. También hay alternativas a AES, como Camellia y ChaCha20, pero obviamente no todas son soportadas por grandes proveedores como Cisco y otros.
Y la gente las utiliza. Hay muchos kits de Cisco, hay numerosos kits diseñados para trabajar con Cisco. Son líderes del mercado en este segmento y no están muy interesados en innovaciones.
Sí, la situación [en el segmento corporativo] es terrible, pero no veremos cambios debido a WireGuard. Los fabricantes probablemente nunca identificarán problemas de rendimiento con las herramientas y cifrados ya utilizados, no verán problemas al usar IKEv2, y por eso no buscan alternativas.
En general, ¿alguna vez has considerado renunciar a Cisco?
Benchmarks
Ahora pasemos a los benchmarks de la documentación de WireGuard. Aunque esta [documentación] no es un artículo científico, aún esperaba un enfoque más científico de los desarrolladores, o al menos el uso de un enfoque científico como referencia. Cualquier benchmark es inútil si no se puede reproducir, y se vuelve aún más inútil cuando se obtiene en condiciones de laboratorio.
En la construcción de WireGuard para Linux, obtiene ventaja utilizando GSO — Generic Segmentation Offloading. Gracias a esto, el cliente crea un paquete enorme de 64 kilobytes y lo cifra/desencripta en un solo paso. De este modo, se reducen los costos de llamada y ejecución de operaciones criptográficas. Si deseas maximizar el ancho de banda de tu conexión VPN, esta es una buena idea.
Sin embargo, como es costumbre, en la realidad no todo es tan sencillo. Enviar un paquete tan grande a un adaptador de red requiere que sea dividido en muchos paquetes más pequeños. El tamaño de envío común es de 1500 bytes, es decir, nuestro gigante de 64 kilobytes se dividirá en 45 paquetes (1240 bytes de información y 20 bytes de encabezado IP). Luego, por un tiempo, bloquearán completamente el funcionamiento del adaptador de red, porque deben ser enviados juntos y al mismo tiempo. Esto resultará en un aumento de prioridad, y paquetes como VoIP se pondrán en una cola de espera.
Así, el alto ancho de banda que WireGuard promete se logra a costa de ralentizar el trabajo de red de otras aplicaciones. Y el equipo de WireGuard ya confirmó esta es mi conclusión.
Pero sigamos adelante.
Según los benchmarks en la documentación técnica, la conexión muestra un ancho de banda de 1011 Mbps.
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 Mbps con un tamaño de paquete de 1500 bytes, menos 20 bytes por el encabezado IP, 8 bytes por el encabezado UDP y 16 bytes por el encabezado de WireGuard. Hay otro encabezado IP en el paquete encapsulado y uno más en TCP de 20 bytes. Entonces, ¿de dónde proviene este ancho de banda adicional?
Con tramas grandes y las ventajas de GSO que mencionamos anteriormente, el máximo teórico con un tamaño de trama de 9000 bytes será de 1014 Mbps. Normalmente, este ancho de banda es inalcanzable en la práctica, debido a las grandes dificultades asociadas. Por lo tanto, solo puedo suponer que la prueba se realizó utilizando tramas aún más grandes con un tamaño superior a 64 kilobytes, con un máximo teórico de 1023 Mbps, que solo es compatible con algunos adaptadores de red. Pero esto es completamente inaplicable en condiciones reales, o puede usarse solo entre dos estaciones conectadas directamente, exclusivamente en un entorno de prueba.
Sin embargo, dado que el túnel VPN se establece entre dos hosts a través de una conexión a Internet que no soporta grandes tramas, el resultado obtenido en el laboratorio no puede considerarse un estándar. Es simplemente un logro de laboratorio irreal que no se puede aplicar en condiciones reales.
Incluso estando en el centro de datos, no podría transferir tramas de más de 9000 bytes.
El criterio de aplicabilidad en la vida real está absolutamente violado y, como creo, el autor de la "medición" realizada se ha desacreditado gravemente por razones evidentes.
El último destello de esperanza
En el sitio web de WireGuard se habla mucho sobre contenedores y se entiende para qué se ha creado realmente.
Una VPN simple y rápida que no requiere configuración y se puede desplegar y configurar con herramientas de orquestación masivas, como las de Amazon en su nube. Amazon utiliza características de hardware más recientes, como las mencionadas anteriormente, por ejemplo, AVX512. Esto se hace para acelerar el rendimiento y no depender de x86 o cualquier otra arquitectura.
Optimiza el ancho de banda y los paquetes que superan los 9000 bytes, lo que resulta en grandes tramas encapsuladas para la comunicación entre contenedores o para operaciones de respaldo, creación de instantáneas o despliegue de dichos contenedores. Incluso las direcciones IP dinámicas no afectarán el funcionamiento de WireGuard en el escenario que he descrito.
Bien jugado. Una brillante implementación y un protocolo muy sutil, casi de referencia.
Pero simplemente no es adecuado para un mundo fuera del centro de datos completamente controlado por usted. Si se arriesga y comienza a usar WireGuard, deberá hacer constantes compromisos en el desarrollo e implementación del protocolo de cifrado.
Salida
No me resulta difícil concluir que WireGuard aún no está listo.
Se concibió como una solución ligera y rápida a una serie de problemas en soluciones existentes. Desafortunadamente, a cambio de estas soluciones, sacrificó muchas funciones que serían relevantes para la mayoría de los usuarios. Por eso no puede reemplazar a IPsec o 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. Es obvio que esto es lo que se requiere para los canales cifrados.
La seguridad es mi máxima prioridad, y en este momento no tengo razones para suponer que IKE o TLS estén comprometidos o rotos de alguna manera. Ambos cuentan con cifrado moderno y han sido verificados durante décadas de uso. El hecho de que algo sea más nuevo no significa necesariamente que sea mejor.
La compatibilidad funcional es extremadamente importante cuando te conectas con terceros, estaciones que no controlas. IPsec es, de facto, el estándar y está prácticamente soportado en todas partes. Y funciona. Aunque parezca que, en teoría, WireGuard podría no ser compatible en el futuro incluso con diferentes versiones de sí mismo.
Cualquier protección criptográfica será eventualmente vulnerada y, por lo tanto, necesita ser reemplazada o actualizada.
Negar todos estos hechos y el deseo ciego de utilizar WireGuard para conectar tu iPhone a tu estación de trabajo en casa es, simplemente, un manual de cómo enterrar la cabeza en la arena.
Fuente: habr.com
