Donc actuellement le chiffrement est AES-128-CBC
Ici mon opinion avec du contexte scientifique derrière:
C’est le plus bas cryptage actual qui soit et certainement donc pas la norme pour le moment. Même si je sais bien que le manuel d’openvpn le recommande. Mais il le recommande pour des raisons de rétrocompatibilités pour les versions inférieures à la version 2.4 (incluse?).
Si c’est pour avoir du cryptage, pourquoi même en avoir un si les entreprises étant un tant soi peu équipée (comme Alphabet bossant quand même sur du quantique je le rappelle) dont on essaie de s’émanciper peuvent potentiellement, théoriquement (alors oui je sais y a beaucoup de si), ou même n’importe quel pirate (un peu ingénieux je l’accorde) en faisant un MITM pourrait éventuellement arriver à décoder le flux et donc potentiellement faire n’importe quel type d’attaque comme de l’injection de requête DNS une fois le flux décrypté.
Fondamentalement, pour que les choses soient claires, je m’en fous des agences gouvernementales.
D’abord parce qu’à part pour les paranos, y a quand même très peu de choses pour que l’un d’entre nous se fassent un jour embarquer dans un van de la CIA ou même breacher par une équipe des seal team. Il y a beaucoup plus de chances par contre qu’un de nos appareils mobiles (En dehors des librem 5 de purism dont très peu d’entre nous sont en possession) se fassent pirater même avec lineage ou autre. En tout cas si ces mêmes agences gouvernementales veulent vraiment en savoir plus sur vous. cfr pegasus et autre.
Non moi ce qui m’inquiètent plus ce sont les entreprises qui seraient potentiellement intéressées de savoir ce qui se passent sur le traffic. Parce que ce sont elles qui ont de l’argent essentiellement.
Donc je vous ai trouvé un petit article pas si mal écrit et de source relativement fiable puisque les informations que mets l’auteur font consensus au sein de la communauté cybersec.
Je trouve que ça donne une bonne vue holistique de la chose en des termes relativement simples:
https://proprivacy.com/guides/aes-encryption
Comme il le relève C’est pas comme si le cryptage aes-128-CBC soit obsolète. Mais on a déjà eu des failles de sécurité relativement importantes dans ce cryptage, ce dont il ne fait pas mention, répertoriées en partie ici :
https://ciphersuite.info/cs/TLS_RSA_WITH_AES_128_CBC_SHA/
Alors oui y a des patchs mais bon … ça reste des patchs. Ca veut quand même dire qu’il y avait potentiellement un problème plus structurel à l’algo sachant que donc comme spécifié, l’algo AES-256-GCM n’a pas été atteint par ces mêmes failles à circonstances équivalentes donc …
Sachant aussi que vous n’êtes jamais à l’abri de gens plus intelligents que vous. Donc autant utilisé ce qui se fait de mieux je dirais.
Chose importante à relever également c’est que la version 256-GCM recourt à des accélérations matérielles importantes, ce qui n’est quand même pas anodin dans notre cas me semble-t-il? Donc potentielle diminution d’utilisation CPU et donc de latence etc.
Alors ce que je proposerais c’est :
mettre le --data-cipher AES-256-GCM
et mettre une --data-cipher-fallback aes-128-cbc
au moins durant une période de transition le temps que tout le monde soit prévenu du changement et qu’on soit certain que les équipements reliés au réseau soient équipés pour maintenir ce cryptage.
Dites mo ice que vous en pensez
@igel @ljf @ced117
EDIT:
Et pour qu’on puisse pas me dire que j’ai un biais cognitif, mais que je manquais de temps quand j’ai fait le post, je vous ai trouvé un autre article relativement bien écrit et argumenté par des « whitepapers » même si c’est fort du domaine de l’opinion aussi.
Vous avez aussi des petites précisiosn sur comment est implémenté le protocol openwhispers et l’infra de signal par exemple.
https://soatok.blog/2020/05/13/why-aes-gcm-sucks/