Actualisation du vpn et de son cryptage à faire

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/

Meme si on me demande pas mon avis, je dirais que si notre infra en est capable, il « suffit de » (quelqu’un pour) le faire. Toi ou toute autre personne ayant des compétences techniques pour réaliser ce genre d’améliorations est bienvenu.e et nécessaire au bon fonctionnement de l’asso.

Nous organiserons des soirées sysadmin plus régulièrement dans les semaines à venir.
Je dois dire aussi que le forum c’est sympa mais en ce moment entre les demandes de support, et les propositions en tous genre je commence à être submergé.

D’où ma proposition de VENIR FAIRE, plutot que de proposer. RDV à une prochaine soirée sysadmin j’espère!

1 « J'aime »

il suffit de me pinger sur le chat, normalement j’ai les notifs. et même me pinger en fait sur le fofo puisque j’ai les notifs aussi avec l’appli discourse sur l’un de mes tels.
Ca me dérange pas de le faire mais ne connaissant pas votre infra, dans tous les cas je préfère indiquer via une conf jitsi en partage d’écran ou bien de commun accord avec quelqu’un qui le gère d’habitude. En soi c’est quelques paramètres à changer, rien de bien méchant mais évidemment avant ça je dois savoir sur quoi ça tourne. Même si je sais déjà que donc la distribution debian sous laquelle ça tourne n’est plus à jour.

Une autre solution mais à plus long terme est aussi de passer à quelque chose de plus « stable » qui serait pfsense ou même opnsense si on a envie d’être dans du libre et on pourrait imaginer une phase de test pour comparer la stabilité. Enfin tout ça est à discuter et surtout à voir de visu.

Donc PINGEZ-MOI.

à vérifier mais j’ai regardé un peu mes logs pour savoir vu que je n’ai pas une vue sur le serveur lui-même. Il semblerait qu’un lein AES-GCM soit quand même établi.
Mais alors dans tous les cas il faudrait à mon sens faire quelques modifs à tout le moins dans le fichier client. Mais c’est à vérifier quand même.