Por qué no debería usar WireGuard

WireGuard ha estado llamando mucho la atención últimamente, de hecho es la nueva estrella entre las VPN. Pero, ¿es tan bueno como parece? Me gustaría discutir algunas observaciones y revisar la implementación de WireGuard para explicar por qué no es una solución para reemplazar IPsec u OpenVPN.

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

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

Como apunte, me gustaría agregar que la responsabilidad de tal posicionamiento de WireGuard es de los medios que hablaron sobre él, y no del proyecto en sí o de sus creadores.

Últimamente no ha habido muchas buenas noticias sobre el kernel de Linux. Entonces, nos hablaron de las monstruosas vulnerabilidades del procesador, que fueron niveladas por el software, y Linus Torvalds habló de eso de manera demasiado grosera y aburrida, en el lenguaje utilitario del desarrollador. Un programador o una pila de redes de nivel cero tampoco son temas muy claros para las revistas de moda. Y aquí viene WireGuard.

Sobre el papel, todo suena genial: una tecnología nueva y emocionante.

Pero veámoslo un poco más de cerca.

Libro blanco de WireGuard

Este artículo está basado en documentación oficial de WireGuardescrito 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 […] tiene como objetivo reemplazar IPsec en la mayoría de los casos de uso y otras soluciones populares basadas en espacio de usuario y/o TLS, como OpenVPN, al mismo tiempo que es más seguro, eficaz y fácil de usar [herramienta].

Por supuesto, la principal ventaja de todas las nuevas tecnologías es su simplicidad [en comparación con los predecesores]. Pero una VPN también debería ser eficaz y seguro.

Y luego que?

Si dice que esto no es lo que necesita [de una VPN], entonces puede terminar la lectura aquí. Sin embargo, señalaré que tales tareas se establecen para cualquier otra tecnología de tunelización.

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

Por qué no debería usar WireGuard

¿Reemplazará WireGuard mi VPN de sitio a sitio [IPsec]?

No. Simplemente no hay posibilidad de que grandes proveedores como Cisco, Juniper y otros compren WireGuard para sus productos. No "saltan sobre los trenes que pasan" en movimiento a menos que haya una gran necesidad de hacerlo. Más adelante, repasaré algunas de las razones por las que probablemente no podrán incorporar sus productos WireGuard, incluso si quisieran.

¿WireGuard llevará mi RoadWarrior de mi computadora portátil al centro de datos?

No. En este momento, WireGuard no tiene implementadas una gran cantidad de características importantes para poder hacer algo como esto. Por ejemplo, no puede usar direcciones IP dinámicas en el lado del servidor del túnel, y esto solo rompe todo el escenario de tal uso del producto.

IPFire se usa a menudo para enlaces de Internet baratos, como DSL o conexiones por cable. Esto tiene sentido para las pequeñas o medianas empresas que no necesitan fibra rápida. [Nota del traductor: no olvide que en términos de comunicación, 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 un estándar, fue más fácil para nosotros 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 general, y una conexión de fibra óptica cuesta un dinero poco realista según nuestros estándares. Por lo tanto, el autor del artículo habla de DSL o conexión por cable como la norma, y ​​no como la antigüedad.] 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 cambian.

Hay un subproyecto llamado "wg-dinámica", que agrega un demonio de espacio de usuario para superar esta deficiencia. Un gran problema con el escenario del usuario descrito anteriormente es el agravamiento del direccionamiento IPv6 dinámico.

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

Desafortunadamente, todo esto se ha vuelto demasiado simple y primitivo, por lo que tenemos que usar software adicional para que todo este diseño sea viable en el uso real.

¿Es WireGuard tan fácil de usar?

Aún no. No estoy diciendo que WireGuard nunca será una buena alternativa para hacer túneles entre dos puntos, pero por ahora es solo una versión alfa del producto que se supone que es.

Pero entonces, ¿qué es lo que realmente hace? ¿Es IPsec realmente mucho más difícil de mantener?

Obviamente no. El proveedor de IPsec ha pensado en esto y envía su producto junto con una interfaz, como IPFire.

Para configurar un túnel VPN sobre 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 de la parte receptora, las subredes que desea hacer públicas a través de esta conexión VPN y clave previamente compartida. Por lo tanto, la VPN se configura en minutos y es compatible con cualquier proveedor.

Desafortunadamente, hay algunas excepciones a esta historia. Cualquiera que haya intentado hacer un túnel a través de IPsec a una máquina OpenBSD sabe de lo que estoy hablando. Hay un par de ejemplos más dolorosos, pero de hecho, hay muchas, muchas más buenas prácticas para usar IPsec.

Acerca de la complejidad del protocolo

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

Si viviéramos en un mundo donde esto fuera una preocupación real del usuario, hace tiempo que nos habríamos deshecho 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 complejo que WireGuard: hace muchas más cosas. Por ejemplo, autenticación de usuario mediante un nombre de usuario/contraseña o una tarjeta SIM con EAP. Tiene una capacidad extendida para agregar nuevos primitivos criptográficos.

Y WireGuard no tiene eso.

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 tiene opiniones criptográficas. Carece deliberadamente de la flexibilidad de los 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 del cifrado ahora ha aumentado enormemente.

La última frase es absolutamente correcta.

Llegar a un consenso sobre qué encriptación usar hace que protocolos como IKE y TLS más complejo. ¿Demasiado complicado? Sí, las vulnerabilidades son bastante comunes en TLS/SSL y no hay alternativa a ellas.

Sobre ignorar los 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 bastante estándar. Si tiene que cambiar el cifrado, debe enviar la actualización a todas las copias de WireGuard en estas computadoras portátiles, teléfonos inteligentes, etc. Al mismo tiempo entregar. Es literalmente imposible. Los administradores que intenten hacer esto tardarán meses en implementar las configuraciones requeridas, y una empresa mediana literalmente tardará años en llevar a cabo tal evento.

IPsec y OpenVPN ofrecen una función de negociación de cifrado. Por lo tanto, durante un tiempo después del cual activa el nuevo cifrado, el antiguo también funcionará. Esto permitirá a los clientes actuales actualizarse a la nueva versión. Después de implementar la actualización, simplemente desactive el cifrado vulnerable. ¡Y eso es! ¡Listo! ¡eres guapisima! Los clientes ni siquiera lo notarán.

En realidad, este es un caso muy común para implementaciones grandes, e incluso OpenVPN tiene algunas dificultades con esto. La compatibilidad con versiones anteriores es importante, y aunque use un cifrado más débil, para muchos, esta no es una razón para cerrar un negocio. Porque paralizará el trabajo de cientos de clientes por la imposibilidad de hacer su trabajo.

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

Por qué no debería usar WireGuard

¡Criptografía!

Pero, ¿qué es este nuevo e interesante cifrado que utiliza WireGuard?

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

ChaCha20-Poly1305 está estandarizado para IPsec y OpenVPN (sobre TLS).

Es obvio que el desarrollo de Daniel Bernstein se usa muy a menudo. BLAKE2 es el sucesor de BLAKE, un finalista de SHA-3 que no ganó por su similitud con SHA-2. Si SHA-2 se rompiera, había una buena posibilidad de que BLAKE también se viera comprometido.

IPsec y OpenVPN no necesitan SipHash debido a su diseño. Entonces, lo único que actualmente no se puede usar con ellos es BLAKE2, y eso es 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 junto con MD5.

Entonces llegué a la conclusión de que casi el mismo conjunto de herramientas criptográficas se usa en todas las VPN. Por lo tanto, WireGuard no es ni más ni menos seguro que cualquier otro producto actual en lo que respecta al cifrado o la integridad de los datos transmitidos.

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

¿Es WireGuard 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 el software. Cifra un bit a la vez. Los protocolos de bloque como AES cifran un bloque de 128 bits a la vez. Se requieren muchos más transistores para implementar el soporte de hardware, por lo que los procesadores más grandes vienen con AES-NI, una extensión del conjunto de instrucciones que realiza algunas de las tareas del proceso de encriptación para acelerarlo.

Se esperaba que AES-NI nunca llegara a los teléfonos inteligentes [pero lo hizo, aprox. por.]. Para esto, el ChaCha20 se desarrolló como una alternativa liviana que ahorra batería. Por lo tanto, puede ser una novedad para usted que todos los teléfonos inteligentes que puede comprar hoy en día tienen algún tipo de aceleración AES y funcionan más rápido y con un menor consumo de energía con este cifrado que con ChaCha20.

Obviamente, prácticamente 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 todos los escenarios. La documentación oficial de WireGuard menciona que con AVX512, ChaCha20-Poly1305 superará a AES-NI, pero esta extensión del conjunto de instrucciones solo estará disponible en CPU más grandes, lo que nuevamente no ayudará con hardware más pequeño y móvil, que siempre será más rápido con AES. - N. I.

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

IPsec le permite elegir libremente qué cifrado es mejor para su caso. 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 en Linux

Aunque WireGuard ha elegido un protocolo de encriptación moderno, esto ya causa muchos problemas. Y así, en lugar de usar lo que es compatible con el kernel listo para usar, la integración de WireGuard se ha retrasado durante años debido a la falta de estas primitivas en Linux.

No estoy del todo seguro de cuál es la situación en otros sistemas operativos, pero probablemente no sea muy diferente a la de Linux.

¿Cómo se ve la realidad?

Desafortunadamente, cada vez que un cliente me pide que configure una conexión VPN para ellos, me encuentro con el problema de que están usando credenciales y cifrado 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, esto no es algo que deba usarse en 2020.

Para el intercambio de llaves siempre Se utiliza RSA, una herramienta lenta pero bastante segura.

Mis clientes están asociados con autoridades aduaneras y otras organizaciones e instituciones gubernamentales, así como con grandes corporaciones cuyos nombres son conocidos en todo el mundo. Todos usan un formulario de solicitud que se creó hace décadas, y la capacidad de usar SHA-512 simplemente nunca se agregó. No puedo decir que 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 desde el año 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 compatibles con los principales proveedores como Cisco y otros.

Y la gente se aprovecha. Hay muchos kits de Cisco, hay muchos kits diseñados para trabajar con Cisco. Son líderes de mercado en este segmento y no están muy interesados ​​en ningún tipo de innovación.

Sí, la situación [en el segmento corporativo] es terrible, pero no veremos ningún cambio gracias a WireGuard. Los proveedores probablemente nunca verán ningún problema de rendimiento con las herramientas y el cifrado que ya están usando, no verán ningún problema con IKEv2 y, por lo tanto, no buscarán alternativas.

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

Puntos de referencia

Y 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 que usaran un enfoque científico como referencia. Cualquier punto de referencia es inútil si no se puede reproducir, y más inútil aún cuando se obtiene en el laboratorio.

En la compilación de Linux de WireGuard, aprovecha el uso de GSO - Descarga de segmentación genérica. Gracias a él, el cliente crea un enorme paquete de 64 kilobytes y lo cifra/descifra de una sola vez. Así, se reduce el costo de invocar e implementar operaciones criptográficas. Si desea maximizar el rendimiento de su conexión VPN, esta es una buena idea.

Pero, como siempre, la realidad no es tan simple. Enviar un paquete tan grande a un adaptador de red requiere que se divida en muchos paquetes más pequeños. El tamaño de envío normal es de 1500 bytes. Es decir, nuestro gigante de 64 kilos se dividirá en 45 paquetes (1240 bytes de información y 20 bytes de cabecera IP). Luego, durante un tiempo, bloquearán por completo el trabajo del adaptador de red, ya que deben enviarse juntos y de una vez. Como resultado, esto conducirá a un salto de prioridad y los paquetes como VoIP, por ejemplo, se pondrán en cola.

Por lo tanto, el alto rendimiento que WireGuard afirma tan audazmente se logra a costa de ralentizar la conexión en red de otras aplicaciones. Y el equipo de WireGuard ya está confirmado esta es mi conclusión.

Pero sigamos adelante.

De acuerdo con los puntos de referencia en la documentación técnica, la conexión muestra un rendimiento de 1011 Mbps.

Impresionante

Esto es especialmente impresionante debido al hecho de que el rendimiento teórico máximo de una única conexión Gigabit Ethernet es de 966 Mbps con un tamaño de paquete de 1500 bytes menos 20 bytes para el encabezado IP, 8 bytes para el encabezado UDP y 16 bytes para el encabezado de el propio WireGuard. Hay una cabecera IP más en el paquete encapsulado y otra en TCP para 20 bytes. Entonces, ¿de dónde vino este ancho de banda adicional?

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

Pero dado que el túnel VPN se reenvía entre dos hosts mediante una conexión a Internet que no admite tramas gigantes, el resultado obtenido en el banco no puede tomarse como punto de referencia. Este es simplemente un logro de laboratorio poco realista que es imposible e inaplicable en condiciones reales de combate.

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

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

Por qué no debería usar WireGuard

Último rayo de esperanza

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

Una VPN simple y rápida que no requiere configuración y puede implementarse y configurarse con herramientas de orquestación masivas como Amazon tiene en su nube. Específicamente, Amazon usa las últimas funciones de hardware que mencioné anteriormente, como el AVX512. Esto se hace para acelerar el trabajo y no estar atado a x86 o cualquier otra arquitectura.

Optimizan el rendimiento y los paquetes de más de 9000 bytes: estos serán enormes marcos encapsulados para que los contenedores se comuniquen entre sí, o para operaciones de respaldo, creando instantáneas o implementando estos mismos contenedores. Incluso las direcciones IP dinámicas no afectarán el funcionamiento de WireGuard de ninguna manera en el caso del escenario que describí.

Bien jugado. Implementación brillante y protocolo muy delgado, casi de referencia.

Pero simplemente no encaja en un mundo fuera de un centro de datos que usted controla por completo. Si se arriesga y comienza a usar WireGuard, tendrá que hacer concesiones constantes en el diseño y la implementación del protocolo de encriptación.

conclusión

Es fácil para mí concluir que WireGuard aún no está listo.

Fue concebido como una solución ligera y rápida a 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 o OpenVPN.

Para que WireGuard sea competitivo, debe agregar al menos una configuración de dirección IP y una configuración de enrutamiento y DNS. Obviamente, para eso están los canales encriptados.

La seguridad es mi principal prioridad y, en este momento, no tengo motivos para creer que IKE o TLS estén comprometidos o rotos de alguna manera. El cifrado moderno es compatible con ambos, y han sido probados por décadas de operación. El hecho de que algo sea más nuevo no significa que sea mejor.

La interoperabilidad es extremadamente importante cuando se comunica con terceros cuyas estaciones no controla. IPsec es el estándar de facto y se admite en casi todas partes. Y trabaja. 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 rompe tarde o temprano y, en consecuencia, debe ser reemplazada o actualizada.

Negar todos estos hechos y querer ciegamente usar WireGuard para conectar su iPhone a la estación de trabajo de su hogar es solo una clase magistral para esconder la cabeza en la arena.

Fuente: habr.com

Añadir un comentario