Mise à jour de mon script OpenVPN

Cela fait bientôt 9 mois que j’ai publié mon script pour installer facilement un serveur OpenVPN, et j’ai depuis fais beaucoup de changements, notamment ces derniers jours comme le montre ce petit graphique :

screenshot_04-12-2016_bghdhvtyr

Du coup, j’ai réécris en partie l’article original, mais je vais m’expliquer un peu plus en détail ici.

Un utilisateur m’avais demandé s’il était possible d’ajouter le support de Arch Linux, et en parallèle l’a aussi demandé à Nyr, puisque je le rappelle mon script en est un fork. Nyr ne veut pas supporter Arch Linux, puisqu’il dit qu’il y a peu d’utilisateurs. C’est faux sur desktop, mais vrai sur serveur, il y a vraiment très très peu de gens qui l’utilisent. HLFH, l’utilisateur en question, dit qu’il verra alors pour ajouter le support de Arch Linux sur mon script.

Et là, paf pif pof, la bombe explose, Nyr lâche toute sa haine contre moi :

I strongly suggest you to stay away from the @Angristan fork: it is buggy, insecure and badly maintained. He’s putting users at risk and he either can’t or don’t want to see it. I’m honestly ashamed that my work has been vandalized like that by someone who claims to have « improved » it.

Les mots sont un peu durs, non ?

Peu importe, j’ai envie de vous dire, comme pour tout autre chose, tout autre critique constructive est la bienvenue, je demande donc à Nyr de développer un peu plus sa pensée. Ce qu’il a fait, et je l’en remercie puisque ça m’a permis de corriger de grosses erreurs que j’avais commises.

C’est mieux que rien, on va dire, puisque Nyr a ensuite continué de me dénigrer moi et mon travail. Des fois, on ferait mieux de pas trop se venter :

That’s wrong, I obviously want my script to deploy a secure configuration. And it does.

[…]

Then, read the goddamn OpenVPN manual which either you haven’t read or you haven’t understood

On lui dit ou pas, que même la documentation de OpenVPN dis que ses paramètres par défaut sont vulnérables ?

Nyr a fait un super travail avec ce script, mais faut peut être pas se prendre pour un dieu dès que l’on a 3000 étoiles sur Github.

Bref.

J’ai pris en compte ses critiques, j’ai créé un nouveau dépôt (pour que mon travail immonde ne soit plus qu’un simple fork) et j’ai bien travaillé sur le script comme vous pouvez le voir sur l’historique des commits. Mon script n’a plus grand chose de l’original. 😉

Merci à TheKinrar qui a proposé une pull request pour ajouter le support d’Arch Linux, qui est, après plusieurs tests, bien fonctionnel ! On peut encore améliorer certaines choses, comme par exemple utiliser un service systemd pour les règles iptables au reboot au lieu d’un script rc.local qu’on doit installer manuellement.

Voici les autres changements :

Et surtout le plus gros commit, qui m’a demandé pas mal de travail c’est The crypto update 🔐. J’ai supprimé les modes « fast » et « slow » qui vous disent peut-être quelques chose si vous connaissiez déjà le script, et à la place j’ai mis certains paramètres par défaut, et pour d’autres comme la taillé de clé RSA, DH, ou encore la cipher, j’ai laissé le choix. Et grâce à Nyr j’ai bien corrigé la confusion qu’il y avait entre la cipher de la control channel et la data channel.

Le commit dont je suis vraiment fier c’est The crypto update 🔐, mais pour le Readme. En effet j’ai réécrit un peu le tout pour que ce soit plus propre, mais surtout pour justifier tous mes choix sur le chiffrement.

Je ne suis pas un cryto-noob, ni un crypto-expert, mais le chiffrement ne m’est pas inconnu comme vous pouvez le voir avec cet article sur HTTPS.

Ainsi, dans toute la partie #encryption, j’expose un à un les différents paramètres et algorithmes utilisés, ce que OpenVPN (et donc Nyr, hum) utilise par défaut, les différentes vulnérabilités qui existent, et ce que j’a choisi d’utiliser.

Sa lecture n’est pas forcément destiné à tout le monde, mais ça m’a demandé plusieurs heures de boulot.

À peu près tout ce que j’ai dit est justifié par des sources et donc je peux désormais clamer haut et fort : oui, mon script est une amélioration du script de Nyr, et oui OpenVPN utilise des paramètres dangereux par défaut pour le chiffrement.

N’hésitez pas cependant, à m’insulter dans les commentaires pour me corriger si jamais vous doutez de ce que j’ai affirmé dans ce long readme. Plus de 2000 mots quand même, c’est presque un mini-audit de OpenVPN 😛

Bref, moi ce que je veux surtout c’est avoir un script propre qui fonctionne bien et qui installe un serveur OpenVPN sécurisé en quelques minutes. Comme toujours il faut bien avoir en tête son modèle de menace, utiliser un VPN pour échapper à la NSA, c’est pas la meilleure solution, mais ça peut embêter Cazeneuve 😆

J’ai encore pas mal d’autres idées d’amélioration en tête, donc n’oubliez pas de check de temps en temps si vous utilisez le script. 🙂

Dernière modification le 5 décembre 2016.

Angristan

Stanislas - 17 ans - Lycéen passionné d'informatique, de technologie et de high-tech. Sysadmin junior, adepte des logiciels libres, de GNU/Linux et d'Android. Music addict.

Poster un Commentaire

16 Commentaires sur "Mise à jour de mon script OpenVPN"

avatar
GsMike
Visiteur
GsMike

Bonjour,

J’ai installer votre scirpt sur un vps tout fonctionne impecablement.

Mais je me demande comment rediriger les visiteur de mon vps sur mon pc a la maison connecté en vpn ?

en gros

http://www.mondomaine.tld > ip mon vps > VPN > serveur @home(apache) (a la manière des connexion VPN offert par les membres FDN)

une idée ?

Kcchouette
Visiteur
Kcchouette

Bonjour,
Je voulais savoir si ce script permettait que les utilisateurs se partagent 1 même fichier ovpn pour être utilisé par plusieurs personnes/plusieurs appareils simultanément ?
Si non, comment je pourrais faire cela ?

HLFH
Visiteur
HLFH

Article exceptionnel. Talent immense. Et merci TheKinrar.

Foobar
Visiteur
Foobar

Merci pour cette maj 😉
J’ai vaguement regardé le code mais sans plus tu gère comment les iptables après un reboot ?

PS: Quand on désinstalle les regles iptables reste.

David_5.1
Visiteur
David_5.1

Vu que tu demandes qu’on t’insulte, allons-y ;-D

Pour les histoires de hash des certificats, il y a des imprécisions sur wikipedia (que je viens de corriger) car SHA-2 que ce soit SHA-256, SHA-386 ou les autres, sont tous similaires et basés sur un schéma de Merkle–Damgård et donc vulnérables aux attaques de type length extension (et http://netifera.com/research/flickr_api_signature_forgery.pdf confirme en parlant de SHA-0-SHA-2).

Pour la suite, tout ce que je dis n’engage que moi 🙂 (donc ça mériterait d’être vérifié, mais je laisse l’exercice au lecteur, car je n’ai pas trouvé rapidement toutes les preuves que j’aurais aimé avoir).

Puisqu’on parle de signature d’un certificat, je ne vois pas en quoi signer un truc qui commence par le certificat (ce qui est le principe des attaques de type length extension) permettrait à l’attaquant de faire quoi que ce soit. Et si c’était le cas, ça voudrait dire a minima qu’une partie des certificats TLS est cassée (ce qui ferait probablement un peu plus de bruit que juste une page sur wikipedia…)

Vu le format des certificats, il suffit d’avoir une extension (par exemple un SAN) pour qu’on ne puisse que rajouter des extensions au mieux, ce qui ne ferait pas grand chose vu que la clef publique ne serait pas modifiable (sans la moindre extension, je ne sais pas si c’est possible d’être dans ce cas avec openVPN, j’ai l’impression qu’on pourrait essayer de rallonger l’exposant, mais je ne suis pas du tout convaincu que ce soit exploitable…)

Enfin, vu que les recommandations de mozilla proposent d’utiliser SHA-256 pour la signature de certificat en mode moderne (sha256WithRSAEncryption qui est, je pense (oui, ça veut dire qu’il faudrait vérifier) équivalent à EASYRSA_DIGEST = « sha256 », car on ne fait pas à ma connaissance de signature publique sans un algorithme de chiffrement asymétrique), je doute qu’il y ait un gros problème de sécurité avec (ils sont en général sérieux sur leurs recommandations de sécurité). Pour les recommandations, voir : https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

Oby
Visiteur
Oby

Merci pour ce script et merci surtout pour les explications dans le readme sur l’encryption, tout est bien détaillé, de mon côté je n’ai pas vu d’aberation (même si personnellement je préfère le sha-512 au sha-384, prendre un hash plus long edt négligeable en terme de ressources /perf)
Je vais jeter un oeil aux sources quand j’aurais le temps

J’en connais plus d’un qui vont être intéressés par ce script 😀

MAXIME MICHAUD
Visiteur
MAXIME MICHAUD

Je vais regarder ça 🙂
Bon boulot

wpDiscuz