optimizar el túnel de la rap #31
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
tinc usa un monton de cpu cuando hay mucho trafico porque tiene que cifrar el tunel y usa algoritmos antiguos (rsa si no recuerdo mal). no se si en 1.0 es posible cambiar los algoritmos, pero recuerdo que en 1.1 si
de
man tinc.confen tinc 1.1 cambiaron los valores por defecto a
blowfishysha1respectivamente:https://tinc-vpn.org/documentation-1.1/Host-configuration-variables.html
Según https://docs.openssl.org/master/man1/openssl-enc/#supported-ciphers podría usar cualquiera de estos:
creo que los candidatos serían blowfish, camellia y aes en distintos modos. la pregunta es cuál está balanceado entre seguridad y performance donde el modelo de ataque sería una mitm.
vuelvo con un analisis de performance
estoy ejecutando
iperf3en una red local. estoy mirando la cpu con pidstat y tomando nota del pico:conexión directa (sin vpn)
uso de cpu: 0% (incluso con htop)
cipher por defecto de tinc 1.0 (aes-256-cbc)
pico de cpu: 44%
bf-cbc
pico de cpu: 31%
aes-128-cbc
pico de cpu: 46%
aes-256-cbc
pico de cpu: 47%
camellia-128-cbc
pico de cpu: 42%
camellia-256-cbc
pico de cpu: 44%
camellia-192-cbc
pico de cpu: 42%
parece que gana blowfish, no? por 10-15% menos de cpu tenemos la misma performance. también hay que tener en cuenta que algunas cpu tienen optimizaciones para aes (para bien o para mal) pero no sé si tinc las aprovecha
segun la wikipedia blowfish tiene vulnerabilidades: https://en.wikipedia.org/wiki/Blowfish_(cipher)#Weakness_and_successors
pero tinc no las menciona, será porque no le afectan? https://www.tinc-vpn.org/documentation/Security.html
con
Digest = sha1no cambia mucho, así que ni lo tocaríael parche es simple, le dejo la decisión a la comisión de cuidados
Si, tal como menciona fauno en este comentario
tinc no menciona la vulnerabilidad e incluso la recomienda por default, más allá que si le afecta directamente creo que la desconfianza de Blowfish es que también es algo antiguo y sobre todo el tamaño, aún usa bloques cifrados de 64 bits lo que es propenso a un ataque sweet32 como mismo se menciona en el link de Wikipedia que fauno compartió.
Según este foro , GnuPG recomendó usar Blowfish pero no para archivos mayores de 4GB.
Ese mismo foro también menciona un par de cosas como que no se puede usar en algunas CPU modernas con hardware AES, y algunas vulnerabilidades de ataques por caché para S-boxes que dependen de clave.
Se recomienda usar como alternativa Twofish que tiene algunas vulnerabilidades pero no se conocen ataques prácticos. Pero, Twofish no viene en la lista de algorítmos soportados para tinc.
No sé si Blowfish sea más indicado, pero ya lo pasé a la comisión de cuidados
Según esta entrada de Wikipedia, Camelia ha salido bien en sus anáisis de seguridad, considerandólo como un algorítmo moderno y seguro.
ok le bajé la prioridad
Terminé la tabla comparativa, ahora paso a la comisión de cuidados.
¿Gana Blowfish considerando que se quiere resolver el gasto de recursos CPU? A ver que se opina en la comisión.
@fauno ¿tienes las cifras del gasto de CPU con el algorítmo actual que usa el tunel? Es RSA, ¿cierto?
@pirra este es el hash y cipher por defecto: #31 (comment)
Cierto!, Listo, tabla actualizada con estos datos. Tabla para seleccionar algorítmo
Nuevamente, un análisis desde el CAD:
Camellia y Blowfish son algoritmos antiguos y no recomendados en la actualidad.
Si el rendimiento representa un problema, existen dos alternativas:
@ChasquiLabo por la 2da: podemos asegurar el uso de aceleración? verificamos esto? (te lo asigno porque estuviste en esta búsqueda)
va, se van anotando los requisitos para los fierros
Entonces, ¿nos estaríamos quedando con el AES por defecto?, asegurando el uso de aceleración por hardware.
Pero eso también implicaría que este recurso del hardware esté en el server que loja la RAP, no solamente en las Huertas, ¿cierto?