Tanto en el servidor como en la configuración del cliente he configurado:
cipher none
auth none
Siguiendo este consejo , también estoy usando el puerto UDP 1195.
Cuando inicio el servidor y el cliente, recibo las siguientes advertencias:
Tue Dec 4 12:58:25 2018 ******* WARNING *******: '--cipher none' was specified. This means NO encryption will be performed and tunnelled data WILL be transmitted in clear text over the network! PLEASE DO RECONSIDER THIS SETTING!
Tue Dec 4 12:58:25 2018 ******* WARNING *******: '--auth none' was specified. This means no authentication will be performed on received packets, meaning you CANNOT trust that the data received by the remote side have NOT been manipulated. PLEASE DO RECONSIDER THIS SETTING!
... lo cual es bueno, pero todavía openvpn está usando encriptación. Lo sé porque:
1) Recibo el siguiente mensaje en el lado del servidor cuando el cliente se conecta:
Tue Dec 4 12:59:59 2018 client_abc/10.20.73.2:36752 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Dec 4 12:59:59 2018 client_abc/10.20.73.2:36752 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2) Tengo una enorme carga de CPU en ambos lados
3) Veo en Wireshark que los datos están encriptados
¿Qué más se requiere para deshabilitar el cifrado?
Respuestas:
Parece que tiene habilitados los Parámetros de cifrado negociables (NCP). Debe especificar
Cuando dos instancias de OpenVPN tienen NCP habilitado (predeterminado para las versiones recientes) negociarán qué cifrado usar de un conjunto de cifrados definidos por ncp-ciphers. El valor predeterminado para eso es 'AES-256-GCM: AES-128-GCM', que explica por qué ve AES-256-GCM en su conexión.
fuente
Suponiendo que está ejecutando openvpn 2.4, creo que también debe configurar
ncp-disable
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
Algunos antecedentes:
Openvpn solía requerir que configure manualmente el algoritmo de cifrado con el mismo valor en ambos extremos. Sin embargo, esto planteaba un problema, hacía que fuera muy difícil actualizar el cifrado en una VPN multiusuario existente. En 2016 se ideó un ataque llamado "sweet32", que permitió recuperar el texto plano en algunas circunstancias. No fue exactamente un ataque fácil de llevar a cabo en la práctica y había una forma de mitigarlo sin cambiar el cifrado, pero seguía siendo un desarrollo preocupante.
Openvpn 2.4 introdujo una nueva característica, habilitada por defecto para negociar parámetros criptográficos. No estoy seguro de si esto fue una reacción a sweet32 o el resultado de preocupaciones generales sobre las implicaciones de estar efectivamente encerrado en un único conjunto de cifrado.
Por lo tanto, cuando se habilita la negociación de parámetros criptográficos, la configuración de "cifrado" actúa efectivamente como un recurso alternativo que se utilizará si el otro lado de la conexión no admite la negociación.
fuente