WireGuard, protocole de communication chiffré sur UDP et logiciel libre

Posté par  . Édité par Cyrille Pontvieux, Anonyme, Benoît Sibaud, benja, volts, SaintGermain, Yves Bourguignon, tisaac, palm123, GG, gregober, Voisin, Pierre Tramo et azerttyu. Modéré par Nils Ratusznik. Licence CC By‑SA.
Étiquettes :
50
22
août
2022
Sécurité

WireGuard est à la fois un protocole de communication chiffré sur UDP et un logiciel libre l’implémentant, le tout créé par Jason A. Donenfeld, qui vise à remplacer les protocoles ou logiciels comme IPSec ou OpenVPN.

Bien que WireGuard ait été principalement pensé pour Linux et que son implémentation de référence soit celle du noyau Linux, il existe des implémentations sous licence libre pour la majorité des plateformes (Linux, BSD, Windows, Mac, Android, iOS), sous GPLv2 pour le noyau Linux, sous MIT, BSD, APLv2 ou GPL suivant les autres cas.

Sommaire

Introduction

WireGuard se veut plus simple qu’IPSec à la fois pour les développeurs et pour les utilisateurs. Il ne propose notamment qu’une seule suite d’algorithmes cryptographiques (considérés comme les plus sûrs et les plus performants à l’heure actuelle) et ne laisse aucun choix de configuration.

Bien que le protocole ne soit pas normalisé sous forme d’une RFC comme peuvent l’être d’autres protocoles d’internet (IPSec par exemple), il est décrit dans un « papier blanc » écrit par son créateur.

Disponibilité

Linux

WireGuard est disponible nativement dans le noyau Linux depuis la version 5.6 et est disponible comme un module externe pour les noyaux 3.10 et ultérieur (en utilisant le support dynamique de chargements de modules DKMS).

NetworkManager gère WireGuard par défaut depuis la version 1.16, cependant il n’existe pas d’interface graphique pour gérer ce type de connexions. Pour ajouter une interface graphique de configuration, il existe le greffon network-manager-wireguard (semblable aux greffons pour OpenVPN ou OpenConnect).

Debian

Avec Debian 11 (Bullseye), WireGuard est intégré au noyau 5.10 et vous n’avez rien à faire si ce n’est installer les outils en ligne de commande fournis par le paquet wireguard et ses dépendances.

Sur Debian 10 (Buster), WireGuard s’installe depuis les backports (aussi avec le paquet wireguard), mais l’installation utilise DKMS et peut nécessiter des actions manuelles si vous avez SecureBoot activé :

Ensuite il faudra peut-être remplacer resolvconf par openresolv à cause du bogue 939904.

Android

Une application est disponible soit sur Play Store, soit sur F-droid.

Petite astuce, il est possible de générer un QR code depuis le serveur : qrencode -t ansiutf8 < fichier_de.conf

FreeBSD, NetBSD et OpenBSD

WireGuard est intégré au noyau d’OpenBSD depuis la version 6.8. NetBSD propose WireGuard dans le noyau de sa branche de développement, la future version 10. Quant à FreeBSD, le support de WireGuard fut retiré de son noyau juste avant la sortie de la version 13. Pour pallier ce manque, le mécanisme des ports propose une nouvelle implémentation en espace noyau, ainsi que l’implémentation de référence qui fonctionne en mode utilisateur.

Windows

Wireguard est disponible pour Windows soit sous la forme d’un module en espace utilisateur (recommandée), soit sous la forme d’un module noyau expérimental : WireguardNT.

MacOS et iOS

Des applications sont disponibles sur l'App Store pour macOS et iOS.

Tutoriel : Installer Wireguard sur Debian/Ubuntu

Tutoriel assez complet pour installer WireGuard sur Debian et Ubuntu 20.04 avec :

  • tunnel/NAT
  • IPv6
  • serveur DNS (pour éviter les fuites DNS)

Si vous installez le résolveur DNS validateur, cache, récursif unbound, il faut penser à désinstaller bind9 avant sinon vous aurez un conflit sur le port 53.

Installation de WireGuard

Le serveur utilisé est un VPS avec une installation Ubuntu server 20.04 toute fraîche.

apt install wireguard

Activation de l'ip_forward pour les deux piles IP

sed -i 's/^#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/' /etc/sysctl.conf
sed -i 's/^#net.ipv6.conf.all.forwarding=1/net.ipv6.conf.all.forwarding=1/' /etc/sysctl.conf

Prise en compte immédiate

sysctl -p

La configuration se fait dans /etc/wireguard/. Le serveur a besoin d’un fichier de configuration nommé par exemple wg0.conf. Ici wg0 sera le nom de l’interface réseau de WireGuard.
Pour l’exemple, nous utiliserons ici les plages d’adresses privées suivantes : 10.26.174.0/24, fd42:42:42::/64.
Le serveur écoutera sur le port 51955.

Nous allons également devoir générer des paires de clefs (privées et publiques) pour le serveur (A) et pour l’exemple les deux premiers clients (B et C). Pour cela, Wirguard fournit tous les outils nécessaires.

umask 077; wg genkey | tee peer_A.key | wg pubkey > peer_A.pub
umask 077; wg genkey | tee peer_B.key | wg pubkey > peer_B.pub
umask 077; wg genkey | tee peer_C.key | wg pubkey > peer_C.pub

Dans la foulée, on va également générer des clefs pré-partagées histoire d’ajouter un petit niveau de sécurité.

umask 077; wg genpsk > peer_A-peer_B.psk
umask 077; wg genpsk > peer_A-peer_C.psk

WireGuard a la capacité de lancer des commandes à son lancement (PostUp) et à sa fermeture (PostDown). Nous allons nous en servir pour lancer les commandes Iptables nécessaires à son fonctionnement. Dans cet exemple, l’interface réseau du VPS sur lequel ont été menés les tests est ens3.

Le fichier de configuration /etc/wireguard/wg0.conf

[Interface]
Address = 10.26.174.1/24, fd42:42:42::1/64
ListenPort = 51955
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE; ip6tables -A FORWARD -i %i -j ACCEPT; ip6tables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE; ip6tables -D FORWARD -i %i -j ACCEPT; ip6tables -t nat -D POSTROUTING -o ens3 -j MASQUERADE 
PrivateKey = C...contenu_de_peer_A.key...=
DNS = 10.26.174.1, fd42:42:42::1

[Peer]
PublicKey = K...contenu_de_peer_B.pub...=
PresharedKey = k...contenu_de_peer_A-peer_B.psk...= 
AllowedIPs = 10.26.174.2/32, fd42:42:42::2/128

[Peer]
PublicKey = r...contenu_de_peer_C.pub...=
PresharedKey = j...contenu_de_peer_A-peer_C.psk...=
AllowedIPs = 10.26.174.3/32, fd42:42:42::3/128

Installation du serveur DNS Unbound

Si vous ne comptez pas utiliser unbound, et donc sauter cette étape, vous allez avoir une erreur au lancement de WireGuard. openresolv est la solution. Installez ce paquet et passez à l’étape suivante.

apt install unbound unbound-host resolvconf

Le fichier de configuration qui va bien : /etc/unbound/unbound.conf.d/dns-cx11.conf. 

server:
    num-threads: 4

    # enable logs
    verbosity: 0  # no verbosity,  only  errors

    # Répondre aux requêtes DNS sur toutes les interfaces
    interface: 0.0.0.0                          # 0.0.0.0 unbound sur plusieurs interfaces
    interface: ::0
    max-udp-size: 3072

    # IPs authorised to access the DNS Server
    access-control: 0.0.0.0/0                 refuse
    access-control: 127.0.0.0/8               allow
    access-control: 10.26.174.0/24            allow

    access-control: ::0/0                     refuse
    access-control: ::1                       allow
    access-control: fe80::/10                 allow
    access-control: fd42:42:42::/64           allow

    #hide DNS Server info
    hide-identity: yes
    hide-version: yes

    # limit DNS fraud and use DNSSEC
    harden-glue: yes
    harden-dnssec-stripped: yes
    harden-referral-path: yes

    # add an unwanted reply threshold to clean the cache and avoid, when possible, DNS poisoning
    unwanted-reply-threshold: 10000000

    # have the validator print validation failures to the log
    val-log-level: 1

    # minimum lifetime of cache entries in seconds
    cache-min-ttl: 1800

    # maximum lifetime of cached entries in seconds
    cache-max-ttl: 14400
    prefetch: yes
    qname-minimisation: yes
    prefetch-key: yes

    #include: /etc/unbound/unbound.conf.d/adslist.txt

Droits :

chown -R unbound:unbound /var/lib/unbound

Pour vérifier si le fichier de configuration est valide

unbound-checkconf /etc/unbound/unbound.conf.d/dns-cx11.conf

La réponse attendue :

unbound-checkconf: no errors in /etc/unbound/unbound.conf.d/dns-cx11.conf

Désactiver systemd-resolved (si utilisé)

systemctl stop systemd-resolved
systemctl disable systemd-resolved

Activation d’unbound`

systemctl enable unbound-resolvconf
systemctl enable unbound

Il est conseillé de redémarrer le serveur

Protection du serveur avec UFW

apt install ufw

On va modifier une stratégie par défaut d’UFW dans /etc/default/ufw pour permettre un bon fonctionnement de WireGuard : DEFAULT_FORWARD_POLICY="DROP" devient DEFAULT_FORWARD_POLICY="ACCEPT"

On va également ouvrir le port d'écoute du serveur VPN (51955).

ufw allow 51955/udp
ufw allow in on wg0 to any

Histoire de conserver l’accès SSH :

ufw allow ssh

S’il vous arrive d’avoir deux mains gauches et dix pouces, relisez vos règles avant d’activer UFW.

ufw enable

Pour voir les règles prises en compte :

ufw status

Test de WireGuard

Lancement du serveur VPN :

wg-quick up wg0

Si tout se passe bien on peut admirer le résultat :

wg show

(wg donne le même résultat)

Pour l’arrêter :

wg-quick down wg0

Mise en service et activation du service au démarrage du serveur :

systemctl enable wg-quick@wg0

Redémarrage et tadaaa !

  • # Intégré dans systemd-networkd

    Posté par  . Évalué à 10.

    Merci pour cette présentation :)

    Je trouve que le paragraphe "Tutoriel : Installer Wireguard côté serveur sur Debian/Ubuntu" est mal nommé, ça pourrait être "Tutoriel : Installer Wireguard sur Debian/Ubuntu" tout court, puisqu'il n'y a aucune notion de client ou serveur avec Wireguard, juste des peers qui se connectent entre eux.

    Pour donner une autre idée/vision, je l'utilise sur des machines Debian dont le réseau est géré par systemd-networkd, et ça tombe bien, puisqu'il y est géré nativement depuis un bon moment.

    Je n'installe aucun paquet sur les serveurs, uniquement le paquet wireguard-tools sur ma station de travail pour générer les clés avec la commande wg genkey | tee /dev/stderr | wg pubkey, ça affiche les deux dans la console sans écrire de fichier (la clé privée en premier, et la clé publique en dessous).
    Pour les clés preshared, j'utilise juste wg genpsk sans rediriger dans un fichier, puisque je vais juste copier/coller les clés dans la conf.

    Ensuite, je crée juste deux fichiers de conf par serveur :
    /etc/systemd/network/50-wg0.netdev (avec des droits en root:systemd-network 0640 puisqu'il contient des secrets)

    [NetDev]
Name=wg0
Kind=wireguard

[WireGuard]
PrivateKey=<server1_private_key>
# Port d'écoute, si la machine est joignable directement par d'autres
ListenPort=<port>

[WireGuardPeer]
PublicKey=<server2_public_key>
PresharedKey=<preshared_key>
# Adresse de la machine distante, si elle est joignable directement
Endpoint=<remote_peer_public_ip>:<port>
AllowedIPs=<remote_peer_vpn_ip>/32
AllowedIPs=<remote_subnet1>/<mask>
AllowedIPs=<remote_subnet2>/<mask>

    /etc/systemd/network/50-wg0.network

    [Match]
Name=wg0

[Network]
Address=<server1_peer_vpn_ip>/<mask>

[Route]
Destination=<remote_subnet1>/<mask>
Scope=link

[Route]
Destination=<remote_subnet2>/<mask>
Scope=link

    Un restart du service systemd-networkd et… tadaaa !

    Bonus : Si le réseau de la machine n'est pas géré par systemd-networkd, on peut quand même l'utiliser pour Wireguard en lui demandant d'ignorer les autres interfaces avec quelque chose comme :

    [Match]
Name=!en* wl*

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Freebox

    Posté par  . Évalué à 8.

    Article très intéressant !
    Je pense qu'il serait intéressant de mentionner qu'il est possible d'activer un serveur WireGuard très simplement sur les Freebox (je ne sais pas pour les autres box). De plus, WireGuard permet d'accéder à son réseau local depuis l'extérieur, sur un appareil Android, alors que ça ne fonctionne pas (ou c'est très compliqué) via OpenVPN (tjrs sur Freebox).

    La Freebox permet aussi de se connecter à un VPN WireGuard en mode client, mais ça n'est utilisé que pour le gestionnaire de téléchargement.

    • [^] # Re: Freebox

      Posté par  . Évalué à 1.

      Petite question.
      Je viens d'activer Wireguard sur ma Freebox et installé le client Android.
      Connexion Ok, mais pas moyen d'accéder au réseau local (A part la Freebox).
      Tu as fais une manip particulière pour l'accès aux machines du réseau local depuis le VPN ?

      • [^] # Re: Freebox

        Posté par  . Évalué à 2.

        Non, je n'ai rien fait de particulier.
        Maïs dans ma configuration, tout en bas, j'ai adresse IP autorisées : 0.0.0.0/0, 192.168.27.64/27, 192.168.0.0/24
        La deuxième est la plage attribuée aux client wireguard, et la troisième c'est ma plage d'ip locale.
        Et "exclure les ip locales" est décoché

        • [^] # Re: Freebox

          Posté par  . Évalué à 0.

          Bon, je suis bon pour le forum :-(
          Moi, rien à faire:
          ping 192.168.0.xxx (la Freebox) -> OK
          ping 192.168.0.yyy (le NAS) -> Rien
          http://192.168.0.zzz (Le serveur astro) -> Rien aussi
          J'ai essayé d'activer le VPN routé en plus (pour l'ip forward) -> Pas mieux :-(

          • [^] # Re: Freebox

            Posté par  (site web personnel) . Évalué à 2.

            tu as peut être une adresse en 192.168.0.0/24 depuis l'accès distant dans ce cas ça ne marchera pas

            c'est pour ça sur son réseau local il faut éviter 192.168.0.0/24 et 192.168.1.0/24 qui sont souvent les réseaux par défaut dans les routeurs fournit par les opérateurs.
            Mettre par exemple 192.168.37.0/24 et on aura certainement jamais ce problème

        • [^] # Re: Freebox

          Posté par  . Évalué à 2.

          Trouvé !
          C'est l'agrégation 4G+ADSL qui fait foirer l'accès au réseau local.
          Agrégation désactivée: Accès au réseau local OK
          Agrégation activée: Accès à la Freebox seulement.

  • # Une seule suite crypto ?

    Posté par  (site web personnel) . Évalué à 4.

    Je tique un peu sur cette remarque.
    Est-ce ce que cela signifie qu'une seule seule crypto est actuellement proposée mais que le protocole offre un mécanisme de négociation comme en TLS, ou n'y a-t-il pas de négociation du tout ?

    • [^] # Re: Une seule suite crypto ?

      Posté par  . Évalué à 6.

      Je pense que tu confuses. Wireguard c'est un outil qui utilise de nombreuse primitives cryptographiques: (ChaCha20 pour le chiffrage symétrique, Curve25519 pour DH, BLAKE2S pour le hashing, HKDF pour la dérivation des mot de passe/clés, …). Tu remarquera qu'il s'agit des primitives "à la mode", c'est à dire celle qui sont le plus efficace et sécurisées pour le moment.

      Mais, contrairement à TLS, il n'y a pas de négociation d'algorithmes et de capacités (ce qui est plus source de problème plus que d'intercompatibilité, AMHA), vu que le protocole défini les primitives utilisées.

      Si, à l'avenir, une primitive s'avère problématique, je suppose qu'ils feront avancer la version du protocole pour échanger une primitive avec une autre, en rendant obsolète la primitive à problème.

      • [^] # Re: Une seule suite crypto ?

        Posté par  (site web personnel) . Évalué à 6.

        Ce qui veut dire faire évoluer en même temps client et serveur. Ça risque d'être compliqué sur le long terme, surtout si un même client peut utiliser deux serveurs différents.

        • [^] # Re: Une seule suite crypto ?

          Posté par  . Évalué à 1.

          J'ai pas réussi à retrouver le message de Jason Donenfeld lors de la conception initiale de Wireguard.

          Mais en gros, sur la crypto, il partait de l'expérience de OpenSSL : quand tu veux créer un socket TLS, c'est extrêmement compliqué, à cause du choix des algorithmes cryptographiques.
          Sur Wireguard, l'utilisateur n'a pas le choix. C'est un ensemble d'algorithmes, point. Mais il me semble que l'agilité cryptographique n'a pas été oubliée.

          Quant à mettre à jour les logiciels, c'est la même chose lors du déploiement de nouveaux algorithmes, y compris pour OpenSSH, TLS, etc.

          • [^] # Re: Une seule suite crypto ?

            Posté par  . Évalué à 10.

            Mais il me semble que l'agilité cryptographique n'a pas été oubliée.

            Si, si. C’est écrit noir-sur-blanc dans le papier blanc de WireGuard :

            WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update.

            Sachant qu’on compte déjà 8 implémentations indépendantes du protocole (d’après Wikipedia, j’avoue n’avoir pas vérifié), si un jour il faut « demander à tous les nœuds de mettre à jour [en même temps] », ça promet d’être amusant…

            • [^] # Re: Une seule suite crypto ?

              Posté par  (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 22 août 2022 à 18:55.

              Cette absence d'agilité cryptographique est en effet une sérieuse erreur de conception de Wireguard (voir le RFC 7696 pour une explication). Un bon exemple est l'arrivée des algorithmes post-quantiques. Comment Wireguard va-t-il gérer cela ?

              • [^] # Re: Une seule suite crypto ?

                Posté par  (site web personnel) . Évalué à 4. Dernière modification le 22 août 2022 à 21:53.

                La solution choisie par Wireguard est de créer une nouvelle version qui sera incompatible avec la précédente.

                Dans l'article Cryptographic Agility and Superior Alternatives l'auteur explique pourquoi l'agilité est une mauvaise chose du point de vu de la sécurité en prenant l'exemple de JWT et qu'elles sont les alternatives possibles. Le cas de Wireguard est évoqué.

                Je ne suis pas assez compétant en sécu pour discuter son point de vue, Bruce Shneier a quant à lui évoqué sa préférence pour l'agilité récemment (https://www.schneier.com/blog/archives/2022/08/nists-post-quantum-cryptography-standards.html).

                Ce que j'en comprend, c'est que la question est : à qui revient la responsabilité de l'algo à utiliser ? A ceux qui conçoivent le protocole, aux développeurs qui vont utiliser une lib (JWT, openSSL) voir même à l'utilisateur (configuration SSL/TSL dans apache par exemple).

                J'aurais tendance à accorder ma confiance aux premiers, et donc n'avoir qu'un seul algo possible. Je comprend que cela permet de garder une base de code plus réduite ce qui est un bon point, le problème d'incompatibilité est de toute manière existant avec l'agilité. Quand il a fallu désactiver les vieux algos sur SSL/TLS sur les serveurs web, on s'est rendu incompatible avec certains clients. A l'inverse quand on avait des vieux OS sur les serveurs et que les navigateurs coupaient les vieux algos, cela entrainait aussi des compatibilités.

                Mais je vois mal utiliser la méthode choisie par Wireguard pour le web, mais laisser la responsabilité aux administrateurs systèmes n'est pas toujours la bonne solution (j'en suis un). Mais pour le cas d'usage de Wireguard, qui est dans un réseau maîtrisé, ça me semble être une très bonne approche. En tant qu'admin je sais que je dois tenir à jour les versions du logiciel mais pas en plus à connaître les arcanes de la configuration des algos de crypto pour avoir une installation sécurisée.

                • [^] # Re: Une seule suite crypto ?

                  Posté par  (site web personnel) . Évalué à 6.

                  Mais à nouveau, comment fais-tu pour tout mettre à jour en même temps ?

                  Les dates de disponibilité dépendent d'une plate-forme à l'autre, et si tu mets à jour ton serveur en premier, tes clients n'auront plus accès au VPN et ne pourront donc plus faire la mise à jour.

                  • [^] # Re: Une seule suite crypto ?

                    Posté par  . Évalué à 3.

                    Je suppose qu'il suffit de faire écouter la nouvelle version sur un port différent et ne couper l'ancienne version que lorsqu'elle n'est plus utilisée. Cela ne me paraît pas totalement insurmontable.

                    • [^] # Re: Une seule suite crypto ?

                      Posté par  (site web personnel) . Évalué à 8.

                      • Ça t'empêche d'utiliser la version fournie par ta distribution (par définition, tu n'auras qu'une seule version d'installée sur ton système),
                      • Ça t'oblige à garder une vieille version en production,
                      • Ça t'empêche d'utiliser des ports standards.

                      • [^] # Re: Une seule suite crypto ?

                        Posté par  . Évalué à 0.

                        J’ai bien python2 et python3 intallés en parallère sur ma machine. Ainsi que gtk2, gtk3 et gtk4.

                        • [^] # Re: Une seule suite crypto ?

                          Posté par  . Évalué à 3.

                          WireGuard est disponible nativement dans le noyau Linux depuis la version 5.6 et est disponible comme un module externe pour les noyaux 3.10 et ultérieur (en utilisant le support dynamique de chargements de modules DKMS).

                          Je ne sais pas a quel point le noyau supporte d'avoir 2 implémentations du même module chargés?

                  • [^] # Re: Une seule suite crypto ?

                    Posté par  . Évalué à 4.

                    Mais à nouveau, comment fais-tu pour tout mettre à jour en même temps ?

                    Bah c’est pourtant facile, il suffit d’être organisationellement agile qu’on te dit !

                    « Organisationnellement agile » étant un mot de code pour dire que l’on parle d’une organisation centralisée où toutes les décisions sont prises par un acteur unique. C’est le seul cas de figure où l’approche mono-algorithme est viable, en fait.

                    Des organisations comme Signal peuvent se permettre de choisir cette approche et de dire merde à l’agilité cryptographique. Mais la présenter comme LA solution universelle applicable partout, c’est stupide.

                • [^] # Re: Une seule suite crypto ?

                  Posté par  . Évalué à 10.

                  Supporter l’agilité cryptographique n’implique aucunement de laisser les administrateurs et/ou les utilisateurs décider de l’algorithme à utiliser.

                  Ce n’est pas parce que c’est comme ça qu’on a fait avec TLS que c’est inhérent au principe de l’agilité cryptographique. (Tous les arguments que j’ai lu contre l’agilité cryptographique sont du même tonneau : on a magistralement foiré l’agilité cryptographique dans (TLS|JWT|SSH|…), du coup il ne faut plus d’agilité du tout…)

                  Disons que le protocole autorise trois algorithmes différents A, B, et C, et recommande l’algorithme A.

                  Alice utilise un logiciel supportant les trois algorithmes. Bob utilise un autre logiciel supportant aussi les trois algorithmes. Quand ils se parlent, leurs logiciels s’échangent la liste des algorithmes supportés et, constatant la présence de l’algorithme A des deux côtés, utilisent obligatoirement A, sans que jamais Alice et Bob n’aient leur mot à dire.

                  On découvre une faille dans l’algorithme A, les auteurs du protocole recommandent désormais l’algorithme B. Alice met à jour son logiciel pour une nouvelle version dans laquelle l’algorithme A est désactivé. Bob n’a pas encore mis à jour (l’éditeur de son logiciel n’a pas encore publié de nouvelle version). Quand ils se parlent, le logiciel d’Alice annonce supporter les algos B et C, le logiciel de Bob annonce toujours supporter les algos A, B, C — les deux se mettent d’accord pour utiliser B, toujours sans que ni Alice ni Bob n’aient leur mot à dire.

                  Plus tard, Bob met à jour, sa nouvelle version ne supporte plus que B et C. Alice et Bob continuent de se parler en utilisant automatiquement B.

                  Plus tard encore, les auteurs du protocole rajoutent un algo D, et décident qu’il est tellement mieux que les autres qu’il devrait désormais être utilisé partout où c’est possible.

                  Cette fois l’éditeur du logiciel de Bob est plus rapide et publie une nouvelle version avec le support de D. Alice, elle, reste temporairement avec une version qui ne supporte toujours que B et C. Alice et Bob continuent de se parler en utilisant automatiquement B.

                  Alice met à jour, son logiciel supporte désormais B, C, et D. Alice et Bob utilisent désormais automatiquement D chaque fois qu’ils se parlent.

                  Et ainsi de suite. À aucun moment Alice et Bob ne peuvent configurer leurs logiciels pour décider eux-mêmes de l’algorithme à utiliser. Le choix est imposé par les logiciels, en fonction des recommandations des auteurs du protocole et de ce que supporte le logiciel d’en face.

                  • [^] # Re: Une seule suite crypto ?

                    Posté par  . Évalué à 2.

                    Perso, je suis pour l'agilité. Mais je pense si c'est introduit, il y aura des demandes incessantes pour ajouter des algos foireux et pour demander que ce soit configurable.

                    Quand ils se parlent, le logiciel d’Alice annonce supporter les algos B et C, le logiciel de Bob annonce toujours supporter les algos A, B, C — les deux se mettent d’accord pour utiliser B, toujours sans que ni Alice ni Bob n’aient leur mot à dire.

                    Ce n'est pas aussi magique que ça, il y a un risque de downgrade attack, qu'il faut aussi gérer sans bug.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Une seule suite crypto ?

                      Posté par  (site web personnel) . Évalué à 6.

                      Perso, je suis pour l'agilité. Mais je pense si c'est introduit, il y aura des demandes incessantes pour ajouter des algos foireux et pour demander que ce soit configurable.

                      Les demandes, ça se gère sans problème, il suffit de les refuser. C'est très facile à automatiser d'ailleurs.

                      Sérieusement, si le projet est clair sur le fait que ce sont les développeurs principaux qui choisissent les algos et que toute demande sur ce sujet sera refusée, ça ne pose pas plus de problème que le choix actuel.

                      D'ailleurs, je ne serais pas surpris que même actuellement, ils reçoivent justement de telles demandes. Ou des demandes d'introduction d'agilité, comme on dit visiblement.

                      Ce n'est pas aussi magique que ça, il y a un risque de downgrade attack, qu'il faut aussi gérer sans bug.

                      Bof. Ce n'est pas compliqué, si je comprends bien le problème principal, c'est celui de la mise à jour d'un serveur VPN et de ses clients, qui, avec la conception actuelle, quand le cas se présentera, devra se faire de façon simultanée. Donc, comme je disais, pas besoin de maintenir un ensemble délirant de protocoles, pour que les évolutions ne nécessitent plus une telle parfaite synchronisation : il suffit que le serveur prenne en charge la version actuelle du jeu d'algos crypto et, sur configuration explicite, la précédente.

                      Scénario :

                      • le serveur est mis à jour, et configuré pour accepter l'ancien jeu d'algos ;
                      • les clients sont avertis qu'ils doivent mettre à jour avant telle date ;
                      • à la date dite, le serveur est configuré pour ne plus accepter l'ancien jeu d'algos.

                      Sans ça, le scénario serait plutôt :

                      • le serveur n'est pas mis à jour, pour ne pas péter l'intégralité des connexions ;
                      • les clients sont avertis qu'ils doivent mettre à jour exactement à telle date, telle heure ;
                      • (les clients qui mettent à jour trop tôt sont pétés) ;
                      • à la date dite, le serveur est mis à jour ;
                      • (les clients qui n'ont pas mis à jour à temps sont pétés).

                      Ce scénario, qui est celui choisi par la conception de WireGuard, est juste moins bien que l'autre, pour le service évidemment, mais également pour la sécurité. Parce que si vous observez bien, l'utilisation d'algos obsolètes n'y nécessite même pas d'attaque par dégradation, elle est carrément maintenue par conception, le temps que tout le monde soit prêt à faire une mise à jour synchronisée !

                      • [^] # Re: Une seule suite crypto ?

                        Posté par  . Évalué à 3.

                        Les demandes, ça se gère sans problème, il suffit de les refuser. C'est très facile à automatiser d'ailleurs.

                        C'est d'ailleurs le rêve de tout développeur, de passer son temps à faire le tri dans le bugs pour en refuser les trois quarts.

                        Bof. Ce n'est pas compliqué

                        Ben oui, il suffit de coder sans bug. Ce n'est pas comme si c'était anecdotique, il y a POODLE, FREAK, DROWN, Logjam… Ce n'est pas le genre d'attaque qui manque.

                        Donc, comme je disais, pas besoin de maintenir un ensemble délirant de protocoles

                        Mais il ne faut pas un ensemble délirant de protocole, il en faut juste 2 dont 1 cassé.

                        (les clients qui mettent à jour trop tôt sont pétés) ;

                        Comme dit dans un autre commentaire, tu peux faire tourner les deux versions en même temps.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Une seule suite crypto ?

                    Posté par  . Évalué à 5.

                    Il me semble que tu disais que les développeurs de GPG n'arrivaient pas à supprimer des algos pourtant considérés comme plutôt fragiles à cause de leur communauté qui réclamait de les garder.

                    Ça ne semble pas être si simple de désactiver un algo (probablement tant qu'il n'est pas complètement percé).

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                    • [^] # Re: Une seule suite crypto ?

                      Posté par  . Évalué à 10.

                      Pas grand’chose à voir. OpenPGP est très utilisé pour chiffrer/signer des « données au repos » (data at rest), potentiellement sur de longues durées. Ceux qui réclamaient le maintien du support pour de vieux algorithmes sont tous ceux qui voulaient conserver la possibilité de déchiffrer leurs vieilles archives de messagerie ou leurs vieilles sauvegardes datant des années 1990¹.

                      Des protocoles utilisés pour le chiffrement de données en transit, comme TLS ou WireGuard, n’ont nul besoin de supporter des algorithmes obsolètes.² C’était justement ça l’erreur de TLS : pas l’agilité cryptographique en soi, mais l’agilité cryptographique avec une liste de trouze mille algorithmes, dont certains complètement dépassés et, pire encore, certains délibérément affaiblis pour suivre les législations des années 1990 (les suites TLS_EXPORT) — et même, encore vraiment pire, des pseudo-algorithmes qui en réalité ne chiffrent pas du tout (les suites TLS_NULL).

                      Ajoute à ça que de toutes les implémentations d’OpenPGP, GnuPG est celle qui a à la marge de manœuvre la plus étroite quand il s’agit des vieux algos, parce que c’est la seule à les supporter — toutes les autres implémentations sont nées beaucoup plus tard et ont choisi de ne supporter d’emblée que les algos modernes ; elles pouvaient se le permettre précisément parce que GnuPG était là pourceux qui avaient besoin des vieux algos !

                      Bref, la difficulté de retirer un algo pour les développeurs de GnuPG n’indique pas grand’chose de la difficulté qu’il y aurait à retirer un algo dans WireGuard, si ce dernier avait fait le choix d’en supporter plusieurs.

                      Par ailleurs, les auteurs de WireGuard semblent confiant dans leur capacité à imposer à tout le monde de passer à un hypothétique WireGuard-v2 le jour où il faudra changer d’algo, donc pourquoi croire qu’ils ne seraient pas capable d’imposer le retrait d’un algo ?

                      (À moins bien sûr que cette capacité ne soit que du flanc, et qu’en réalité ils n’aient pas la moindre idée de la procédure qu’il faudra mettre en œuvre le jour où il faudra basculer…)

                      ¹ Et qui auraient mieux fait de re-chiffrer leurs vieilles archives avec des algos plus modernes plutôt que de les conserver chiffrées avec les vieux algos de l’époque, mais bon…

                      ² Sauf pour ceux qui veulent faire du WireGuard-over-IPoT depuis 1999, mais bon, je m’autorise à penser que ça doit être une niche encore plus réduite que celle des utilisateurs d’OpenPGP. :D

          • [^] # Re: Une seule suite crypto ?

            Posté par  (site web personnel) . Évalué à 3.

            Quant à mettre à jour les logiciels, c'est la même chose lors du déploiement de nouveaux algorithmes, y compris pour OpenSSH, TLS, etc.

            Si, justement : le client et le serveur se mettent d'accord pour utiliser le meilleur choix disponible chez les deux parties.

            Imaginons que mon serveur Wireguard a été mis à jour et mon client en fonctionne donc plus. Comment suis-je censé mettre à jour mon client sans VPN ? Que dois-je faire si le client n'est pas encore disponible pour une raison X ou Y (les deux ne sont pas sous le même OS) ?

            • [^] # Re: Une seule suite crypto ?

              Posté par  . Évalué à 0.

              Par internet ? Comme n'importe quel autre logiciel en fait. Wireguard c'est un tunnel crypté, fourni soit avec le noyau ou à côté, comme module, ou en user space, bref, t'as l'embarras du choix.

              • [^] # Re: Une seule suite crypto ?

                Posté par  (site web personnel) . Évalué à 1.

                Quand je pars à l’étranger, je ne veux avoir accès à internet qu’à travers un VPN. Si je n’ai plus de VPN, je n’ai plus accès à internet non plus.

  • # Une petite erreur ?

    Posté par  (Mastodon) . Évalué à 6.

    On a d'abord :

    Pour l’exemple, nous utiliserons ici les plages d’adresses privées suivantes : 10.26.174.0/24, fd42:42:42::/64

    Et plus loin, dans la configuration de unbound :

    access-control: 10.26.174.0/16 allow
    access-control: fd42:42:42::/48 allow

    Ce genre d'erreur, ça peut prendre des heures à retrouver…

  • # Extension d'IP pour par exemple un serveur de license

    Posté par  . Évalué à 6.

    Salut,

    Je me demandais si WG pouvait faire comme OpenVPN, à savoir une interface prolongeant le plan d'adressage local (via TAP avec une IP v4 en 192.168.1.x distribuée par OpenVPN).

    L'idée c'est d'attaquer un service bien particulier qui nécessite le même plan d'adressage plutôt que d'implémenter du routage sur le serveur.

    Ou est ce que WG nécessite systématique un routage (statique ou dynamique) de par son fonctionnement en mode peer ?

    Merci !

  • # Simple comme...

    Posté par  . Évalué à 2.

    WireGuard se veut plus simple qu’IPSec à la fois pour les développeurs et pour les utilisateurs.

    Côté admin/utilisateur la simplicité est complètement loupé alors. Je l'ai utilisé un peu sur un Routeur OPNSense/Poste Windows je vois pas où est la simplicité. Pour la partie Windows si il n'y a pas d'option "vpn before login" c'est presque mort en entreprise.

    Pour rester positif c'est encore jeune, à voir dans les années comment va évoluer le projet.

    de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité

    • [^] # Re: Simple comme...

      Posté par  . Évalué à 6. Dernière modification le 22 août 2022 à 19:40.

      En entreprise c'est mort à tout les niveaux pour l'utiliser :
      - pas d'adressage IP dynamique, tout les clients doivent avoir un adressage statique
      - pas d'intégrations d'annuaires
      - pas de MFA
      - pas de traversée de double-NAT

      Wireguard, dans son état actuel est juste un jouet. C'est dommage parce qu'à côté il comble les faiblesses de ses 2 concurrents :
      - OpenVPN fonctionne en user-space et est donc très consommateur de ressources
      - IPSec Ikev2 ne génère pas d'interface réseau par défaut, le routage des flux se fait avec des règles XFRM.

      Mais bon, pour la consommation de ressources d'OpenVPN, il "suffit" de fournir suffisement de ressources pour avoir suffisement de débit pour tout le monde. Pour Ikev2, un bon firewall fera un routage correct des flux si on a des besoin complexes, et avec StrongSwan sous Linux il est également possible de lier un tunnel à une interface réseau pour pouvoir faire du routage de flux classiques.

      Du coup pour le moment, Wireguard n'a que peu d'intérêts.

      Emacs le fait depuis 30 ans.

      • [^] # Re: Simple comme...

        Posté par  (site web personnel) . Évalué à -6.

        C'est bien, tu n'as plus qu'à faire des PR.

        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

      • [^] # Re: Simple comme...

        Posté par  . Évalué à 3. Dernière modification le 23 août 2022 à 12:54.

        Vu que c'est level 3, aucune des fonctions que tu listes n'entre dans le champ technique de WG. Rien ne t'empêche de faire de l'IP dynamique, du LDAP, du TURN, ce que tu veux.

        Oublie WG un instant et demande toi comment faire ça avec une simple carte Ethernet, wg est une interface en plus, ça marche pareil.

        Donc oui, tu peux avoir un DHCP sur WG, ce serveur DHCP peut consulter un annuaire pour assigner les IP, tu peux utiliser TURN pour passer le double NAT et ensuite démarrer WG à travers le trou (et c'est même assez simple avec systemd d'ailleurs)

        Ce n'est pas le rôle de WG de faire ça (à la Unix-style: WG fait un seul truc et bien). D'ailleurs, je ne pense pas que OpenVPN ne le fasse aussi.

        • [^] # Re: Simple comme...

          Posté par  (site web personnel) . Évalué à 5.

          Vu que c'est level 3, aucune des fonctions que tu listes n'entre dans le champ technique de WG. Rien ne t'empêche de faire de l'IP dynamique, du LDAP, du TURN, ce que tu veux.

          Oublie WG un instant et demande toi comment faire ça avec une simple carte Ethernet, wg est une interface en plus, ça marche pareil.

          Je ne pense pas non. Sans avoir essayé, il me semble qu'un interface de niveau 3, ça n'est justement pas un adaptateur virtuel semblable à une carte Ethernet, Wifi ou Bluetooth, mais un lien IP, comme peut l'être une interface PPP par exemple.

          Ça n'empêche pas en théorie de faire des choses comme de l'adressage dynamique, même si j'ai du mal à voir l'intérêt de la chose. En revanche, ça empêche certainement certains usages, par exemple la mise en place d'un proxy ARP ou NDP pour connecter plusieurs hôtes derrière un seul sans coopération de routage au niveau du serveur de VPN.

          • [^] # Re: Simple comme...

            Posté par  . Évalué à 1.

            Ça n'empêche pas en théorie de faire des choses comme de l'adressage dynamique, même si j'ai du mal à voir l'intérêt de la chose.

            Moi aussi, et c'est aussi l'avis de l'auteur. Mais malgré tout, il existe wg-dynamic pour la gestion des IP dynamiques.

            WG c'est plutôt comme un bridge à l'usage. Tu as ta carte Ethernet/Wifi connecté à l'internet et WG crée une interface virtuelle (wg0) avec une IP privée (type 10.x.x.x) et une règle de routage entre les réseaux de telle façon à ce que tu puisses parler, via ce réseau privé (10.x.x.x) aux autres membres du réseau (10.x.x.y et 10.x.x.z etc…).

            J'ai du mal à voir l'intérêt d'un proxy ARP ou NDP qui sont au niveau 2 (MAC) sur ce genre de montage, vu que ce genre de proxy sert justement lorsque tu n'as pas de table de routage (c'est quand même hachement plus simple de faire un ip route add via que d'avoir à mettre en place un proxy ARP). D'autant plus que l'ARP c'est du broadcast, donc pas top pour du VPN un peu étendu. Après si tu y tiens absolument, il y a OpenDaylight.

            • [^] # Re: Simple comme...

              Posté par  (site web personnel) . Évalué à 3.

              La mise en place d'un proxy ARP ou NDP sert sur un réseau physique Ethernet ou Wifi dont tu n'es pas administrateur, lorsque :

              • tu ne peux pas connecter une autre adresse MAC que celle de ton ordinateur ;
              • tu as plusieurs interfaces réseau ;
              • tu veux connecter un ou plusieurs hôtes supplémentaire derrière ton poste ;
              • tu ne veux pas faire de NAT.

              Le principe est de faire croire au réseau que c'est ton interface réseau qui a plusieurs adresses IP. Mais en réalité, tu routes tout le trafic qui leur est destiné vers les hôtes qui sont connecté sur un ou plusieurs de tes autres interfaces réseaux.

              C'est infaisable avec une interface qui n'a pas de niveau 2.

        • [^] # Re: Simple comme...

          Posté par  . Évalué à 2. Dernière modification le 24 août 2022 à 22:36.

          Tout dépend de quoi on parle. Si tu parles du protocole, oui ca n'a aucun rapport. Mais ici, je réponds à un commentaire qui parle de son utilisation en entreprise, ce qui sous-entend qu'on parle de l'implémentation officielle (qui est systématiquement reprise lorsque wireguard est intégré dans un équipement réseau).

          Rien ne t'empêche de faire de l'IP dynamique, du LDAP, du TURN, ce que tu veux.

          Bah le fait que ca ne soit pas géré dans l'implémentation en fait, soit le sujet du commentaire.

          Oublie WG un instant et demande toi comment faire ça avec une simple carte Ethernet, wg est une interface en plus, ça marche pareil.

          Bah du coup non, vu que de base il gère une authentification. Et les adresses IP sont bien fixées dans la configuration logicielle, il n'y a pas de possibilité de faire d'adressage dynamique. Ca a d'ailleurs été un gros sujet pour les sociétés de VPN comme Nord ou Proton, qui ont dû faire leurs propres implémentations pour compenser ca, tout en restant compatible avec l'implémentation officielle.
          Encore une fois, je ne parle pas du protocole, mais de l'implémentation.
          Ah, et si je ne m'abuse, une interface ethernet ou wifi ne serait pas une interface de niveau 2 ? Il ne me semble pas qu'un tun ait une adresse MAC.

          Donc oui, tu peux avoir un DHCP sur WG, ce serveur DHCP peut consulter un annuaire pour assigner les IP

          Tu as manqué le point ici. Le but d'intégrer un annuaire dans un premier temps, c'est de gérer l'authentification de façon centralisée.

          Ce n'est pas le rôle de WG de faire ça

          C'est le rôle de l'implémentation.

          D'ailleurs, je ne pense pas que OpenVPN ne le fasse aussi.

          OpenVPN, tout comme IPSec Ikev2, intègre l'assignation d'adresses IP fixes ou dynamiques aux clients, la gestion de l'authentification des utilisateurs depuis un annuaire centrale, et supporte plutôt pas mal la traversée de NAT multiple.

          Petit point qui est passé à la trappe, Wireguard supporte mal les traversées multiples de NAT. Après plusieurs tests, quand il y en a plus qu'un, ca devient délicat.

          Emacs le fait depuis 30 ans.

      • [^] # Re: Simple comme...

        Posté par  (Mastodon) . Évalué à 6.

        Dire que c'est juste un jouet, c'est se méprendre complètement sur les buts du projet.

        Wireguard ne cherche pas à être une solution clé en main pour du VPN d'entreprise. Le but est de fournir un protocole robuste et efficace, ainsi qu'une API pour permettre à des outils externes de fournir les fonctionnalités avancées. On trouve par exemple Tailscale, qui propose une solution complète avec toutes les fonctionnalités que tu mentionnes. Il y aussi pas mal de projets libres, avec différents niveaux d'avancement.

        • [^] # Re: Simple comme...

          Posté par  . Évalué à 3.

          Marrant cette levée de boucliers. Je réponds bien à un commentaire qui parle de son utilisation en entreprise, pas au journal. Donc le propos ici est bien son utilisation en entreprise (et du coup de son implémentation en fait), pas du protocole.

          J'entends bien que le but de l'implémentation n'est pas d'être un VPN d'entreprise, mais elle manque d'énormément de choses pour faire autre chose que des setup des plus basiques, d'où sa qualification de jouet, notamment par rapport à un OpenVPN ou un IPSec. En l'état, je lui préfère un bon vieux tunnel SSH, bien plus agréable à gérer et plus robuste sur les traversées de NAT.

          Emacs le fait depuis 30 ans.

          • [^] # Re: Simple comme...

            Posté par  . Évalué à 1.

            En l'état, je lui préfère un bon vieux tunnel SSH, bien plus agréable à gérer et plus robuste sur les traversées de NAT.

            Je ne vois pas en quoi c'est plus simple, puisque l'utilité n'est absolument pas la même. la consommation de ressources non plus d'ailleurs.
            Tu n'en as pas l'utilité, ça n'en fait pas pour autant un jouet, au contraire.

  • # Aucun besoin de bricoler la liste des serveurs DNS de la racine

    Posté par  (site web personnel, Mastodon) . Évalué à 8. 

    Téléchargement de la liste des serveurs DNS racines

    C'est inutile, Unbound (comme BIND et les autres) a tout ce qu'il faut (faites un strings sur /usr/bin/unbound si vous ne me croyez pas) et, de toute façon, utilise le "priming" (RFC 8109). Intervenir sur cette liste n'est utile que si on veut utiliser une racine alternative.

    On peut utiliser ce script pour mettre à jours les serveurs DNS racines

    Même remarque ici.

  • # Mauvais lien DKMS

    Posté par  . Évalué à 3.

    Le lien DKMS pointe vers une mauvaise page, voici la bonne : https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support

  • # Documentation annexe

    Posté par  . Évalué à 3. Dernière modification le 28 août 2022 à 07:17.

    Pour compléter l'article, voici une base de documentation qui reprend de manière très claire (schémas + commandes) différentes possibilités d'implémentation :
    https://www.procustodibus.com/blog/

  • # Reload

    Posté par  . Évalué à 1. Dernière modification le 17 septembre 2022 à 19:25.

    Petite commande utilse pour reloader la conf sans interruption (tire du manpage)

    The strip command is useful for reloading configuration files without disrupting active sessions:

    # wg syncconf wgnet0 <(wg-quick strip wgnet0)

  • # Yunohost

    Posté par  . Évalué à 2.

    À noter que wireguard peut-être mis en oeuvre simplement via une app disponible dans Yunohost : https://github.com/YunoHost-Apps/wireguard_ynh

    aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.