GuiGui's Show

Le protocole TLS 1.3 a été publié en 2018. Ce protocole permet de sécuriser (confidentialité, authentification, intégrité) les communications sur Internet de tout type (web, emails, messagerie instantanée, téléphonie, etc.) de point à point (d'un client à un serveur, par opposition à un chiffrement de bout en bout, c'est-à-dire d'un internaute à un autre). Pour plus d'infos sur TLS 1.3, voir le billet de blog de tonton Bortzmeyer, l'article Prise en main de TLS 1.3 avec OpenSSL 1.1.1 publié dans le numéro 226 de GLMF et l'article RFC 8446 - TLS 1.3 : que faut-il attendre de cette nouvelle version ? publié dans le numéro 105 de MISC.

Pour ma part, je retiens :

• Grand nettoyage :

  • RSA n'est plus utilisable pour échanger des clés de session (nécessaires pour le chiffrement symétrique), donc il reste uniquement des échanges de clés DH qui garantissent la confidentialité persistante / future ;
    
    
  • Tous les algos démodés / foireux (RC4, algos de chiffrement par bloc dits CBC, MD5, SHA-1, etc.) dégagent. Il reste cinq suites cryptographiques (dont trois sont activées par défaut dans OpenSSL), toutes basées sur le chiffrement intègre (AEAD) afin de pallier aux attaques à texte choisi contre les algos CBC (genre BEAST) et aux attaques par rembourrage contre la manière d'implémenter la preuve d'intégrité dans les algos CBC (la dénommée Mac-then-Pad-then-Encrypt, voir l'article de tonton Bortz) genre POODLE, même si une extension TLS permet depuis plusieurs années de passer au mode plus sécurisé Encrypt-then-Pad-then-Mac). En résumé, les grandes familles d'algos à notre disposition sont les suivantes : échange de clés éphémères = DHE ou ECDHE, authentification (signature) = RSA ou ECDSA (DSA dégage, tout comme la possibilité de présenter des certificats OpenPGP) et chiffrement symétrique = AES AEAD. Enfin, si dans les versions précédentes de TLS, on peut négocier des courbes, leurs paramètres et des groupes finis de DH, avec TLS 1.3, il n'est plus possible d'utiliser des paramètres (courbes, points sur les courbes, groupes finis DHE, etc.) maison pour (EC)DHE, il faut utiliser exclusivement ceux normalisés. L'idée est d'éviter les paramètres foireux et/ou générés par une implémentation foireuse (ça s'est déjà vu) ;
    
    
  • La compression TLS et la renégociation des clés de session en cours de route n'existent plus. Vu les attaques les utilisant genre CRIME, ce n'est pas une perte. La reprise d'une session fonctionne désormais comme un échange de clé partagée, il n'y a plus de code informatique dédié à cette fonctionnalité ;
    
    
  • Pour l'authentification des messages TLS, si l'on utilise RSA, alors on l'utilise forcément avec le schéma / profil RSA-PSS (Probabilistic signature scheme) défini dans la version 2.1 du standard PKCS#1 qui est plus robuste que celui de la version 1.5 de PKCS#1 qui rendait possible des attaques par rembourrage genre ROBOT. Pour l'authentification du pair (serveur ou client), les implémentations doivent supporter RSA-PSS (c'est la nouveauté) et le prioriser dans la négociation, mais sans plus ;
• La poignée de main TLS est désormais partiellement confidentielle et intègre. Ça explique pourquoi, au sein d'un échange TLS, on voit très rapidement des messages du type « Application data » auparavant réservés au seul contenu applicatif protégé : ces messages contiennent désormais la fin de la poignée de main sous une forme chiffrée. C'est ça, qui rend envisageable ESNI, le chiffrement du SNI, c'est-à-dire le nom du serveur que l'on cherche à contacter (utile sur un serveur mutualisé afin que le serveur envoie le bon certificat x509, celui du service avec lequel on veut échanger). Les clés de session (je simplifie) sont échangées dans l'extension « Keyshare » des messages « (Client|Server)Hello » puis confirmées après l'échange du certificat du serveur (afin d'en garantir l'authenticité). L'authenticité de la poignée de main n'est garantie qu'à sa fin ;
  
  

• Afin d'éviter les pare-feux mal-conçus et les boitiers de sécurité foireux massivement déployés, TLS 1.3 imite, au niveau réseau, TLS 1.2 : la version présentée dans le message « ClientHello » est toujours 1.2 alors que la vraie version est négociée dans une extension, on conserve le champ « CompressionMethod » dans les messages « *Hello » alors qu'il n'y a plus de compression TLS (voir ci-dessus), et l'on conserve les messages « ChangeCipherSpec » qui servent pourtant plus à rien, etc. Voilà où nous en sommes pour quelques enfoirés qui font nawak :( ;

• Une poignée de main TLS < 1.3 se fait en 2 RTT (deux allers-retours entre le client et le serveur). Hors poignée de main TCP (1 RTT) et hors requête applicative (1 RTT). Je trouve cette présentation trompeuse, car, dans un même trajet (aller ou retour), plusieurs messages TLS seront échangés, potentiellement dans des paquets IP séparés. On tombe à 1 RTT lors de la reprise d'une session existante. Un mode O RTT (O-RTT / early-data) apparaît avec TLS 1.3 : lors de la reprise d'une session, on peut envoyer des données applicatives (chiffrées et intègres) dès le premier message. Cela a un coût : on perd la confidentialité persistante (car les données sont chiffrées avec la clé partagée, PSK, contenue dans le ticket de session) et on se rend vulnérable à un rejeu d'une requête capturée sur le réseau. L'application doit gérer cela… sauf qu'il est très compliqué de différencier une requête non-idempotente (donc problèmatique)… Sinon, le serveur TLS doit conserver un état… ce dont personne veut, toute la reprise d'une session est et a toujours été sans état. Je vois jamais une présentation de l'intérêt du mode O-RTT : je trouve qu'il est utile entre un reverse proxy et un serveur backend afin d'être certain d'une absence de perte de performance, par exemple, sauf si le réseau entre eux est multi-datacenters / international (auquel cas, un risque de surveillance externe existe, et encore, mieux vaut chiffrer + 0-RTT que de faire du trafic en clair) ;

  • Dans OpenSSL, le mode O-RTT / early-data est désactivé par défaut, une application doit demander explicitement son activation à la bibliothèque cryptographique qu'elle utilise. « By default the server does not accept early data; a server may indicate support for early data by calling SSL_CTX_set_max_early_data() or SSL_set_max_early_data() to set it for the whole SSL_CTX or an individual SSL object respectively » (source). Je n'ai pas vérifié le comportement des autres implémentations de TLS.
• Dans TLS < 1.3, un même champ permettait d'indiquer l'algo pour l'échange de clés, celui pour l'authentification (du pair et des messages TLS), celui pour le chiffrement symétrique et éventuellement celui pour garantir l'intégrité. Désormais, il y a trois champs : échange de clés = « supported groups » (anciennement « supported elliptic curves », mais vu qu'on peut aussi faire du DHE, ce nom ne se justifiait plus et il a sauté avec le RFC 7919), auth = « signature algorithms », chiffrement symétrique et intégrité = « cipher suites » (le vieux champ). Les versions précédentes de TLS utilisent aussi les extensions « supported groups » et « signature algorithms », donc TLS 1.3 acte seulement le changement sémantique du champ « cipher suites » ;
  
  
• Il n'y a plus d'ordre imposé dans la chaîne des certificats fournie à un client TLS à l'exception que le certificat du serveur doit être le premier. C'était déjà le cas en pratique, c'est désormais dans la norme ;
  
  
• On note l'apparition d'une extension TLS sympa nommée « certificate_authorities ». Elle indique la liste des autorités de certification connues du client, et elle peut aider le serveur à choisir un certificat qu'il enverra (par exemple en n'envoyant le certificat CAcert que si le client connait cette AC). (j'ai copié cette phrase depuis le blog de tonton Bortz).

La bibliothèque de fonctions cryptographiques OpenSSL implémente TLS v1.3 à partir de sa version 1.1.1. Celle-ci est disponible dans la version Buster (10) de Debian. Donc ma récente mise à jour vers Debian Buster (voir mes notes sur ce qui change et/ou qui pose problème entre Stretch et Buster) m'en ouvre les portes. \o/ Notons que la protection contre le rejeu possible du mode 0-RTT (avec des états côtés serveurs ?) et l'utilisation des groupes finis DHE, entre autres, ne sont pas disponibles dans cette version.

Pour activer TLS 1.3, il y a rien à faire, ni côté client, ni côté serveur, puisque la version de TLS est négociée lors de l'établissement d'une communication chiffrée afin d'en retenir la plus élevée.

Néanmoins, attention aux configurations de serveurs applicatifs qui listent explicitement les versions de TLS utilisables. Exemples : un serveur d'emails Postfix configuré avec smtpd_tls_protocols = !SSLv2, !SSLv3 utilisera automatiquement TLS 1.3 si le client la prend en charge ; Idem pour un serveur IMAP/POP Dovecot configuré avec ssl_min_protocol = TLSv1.2. En revanche, un Apache httpd configure avec SSLProtocol +TLSv1.1 +TLSv1.2 n'utilisera pas TLSv1.3, il faudra le configurer explicitement (SSLProtocol +TLSv1.1 +TLSv1.2 +TLSv1.3) ou exclure les protocoles non-fiables plutôt que de lister les protocoles fiables (voir l'exemple Postfix ci-dessus).

Comment vérifier qu'un serveur applicatif n'utilise pas le mode 0-RTT / early-data (il est désactivé par défaut, c'est aux serveurs applicatifs de l'activer, lire ci-dessus) ? En testant nous-même. Quand un serveur applicatif accepte le mode 0-RTT, il en informe tout client en positionnant l'extension « early_data » dans un ticket de session TLS. Voyons ça en pratique :

• D'un côté, on monte un serveur TLS : openssl s_server -accept 4433 -cert <chemin_vers_certificat_x509> -key <chemin_vers_clé_privée> ;
  
  
• De l'autre, on se connecte à ce serveur TLS : openssl s_client -connect <nom_serveur>:4433 -tlsv1_3. On remarque la ligne « Max Early Data: 0 » dans la section « New Session Ticket arrived » : 0-RTT n'est pas disponible ;
  
  
• On interrompt (ctrl+c) le serveur TLS et on en monte un avec le mode 0-RTT activé : openssl s_server -accept 4433 -cert <chemin_vers_certificat_x509> -key <chemin_vers_clé_privée> -early_data. On relance le client TLS. Cette fois-ci, on lit « Max Early Data: 16384 », donc 0-RTT est disponible ;
  
  
• On peut ensuite tester tous nos vrais serveurs (Apache httpd, Postfix, Dovecot, etc.) ainsi. Ne pas oublier -starttls <protocole> en fonction du cas. ;)
  
  
• Si l'on a un doute, on peut initier une première connexion TLS en conservant le ticket (-sess_out <nom_fichier_stockage_ticket_TLS>) puis une deuxième en donnant le ticket (-sess_in <nom_fichier_stockage_ticket_TLS>) et en envoyant du contenu (-early_data early_data.txt) qu'il faut créer d'abord (avec echo 'Bonjour' > early_data.txt, par exemple). Si le serveur a accepté nos données utilisateur, OpenSSL affichera « Early data was accepted ». Sinon, il affichera « Early data was not sent ». On peut contrôler tout ça avec Wireshark en déchiffrant l'échange TLS à l'aide de SSLKEYLOGFILE (puisque ces messages TLS sont désormais chiffrés).

On peut aussi désactiver le mode 0-RTT dans les logiciels clients. Pour Firefox et Thunderbird, cela se fait en attribuant la valeur « false » à la clé « security.tls.enable_0rtt_data » dans about:config.

La variable d'environnement « SSLKEYLOGFILE » permet d'indiquer un fichier où seront stockés les secrets cryptographiques (clés de session) échangés par un programme lors de communications TLS.

Ça fonctionne avec la majorité des bibliothèques TLS. J'ai testé avec Firefox (lib = NSS), Chromium (lib = BoringSSL), curl (lib = OpenSSL), wget et ldapsearch (lib = GnuTLS). A priori, ça fonctionne sous GNU/Linux, mais aussi sous winwin et Mac OSX.

C'est logique, car c'est à chaque programme de vérifier l'existence de la variable d'environnement, d'ouvrir le fichier, d'appeler la callback de la bibliothèque TLS, etc. Exemple : le sous-programme s_client d'OpenSSL ne prend pas en charge cette variable, il faut utiliser le paramètre -keylogfile.

On peut utiliser ces secrets afin de déchiffrer une communication avec Wireshark sans recourir à une attaque MitM. Généralement, le programme n'efface pas les secrets consignés lors de sessions précédentes ou par d'autres programmes (il ajoute ses secrets à la fin du fichier) , wireshark sera en mesure de déchiffrer tous les flux chiffrés qu'il a capturés, même si un logiciel a effectué plusieurs connexions chiffrées ou s'il a renégocié les clés.

Vu que j'ai déjà déchiffré des flux avec wireshark, j'ai l'impression de redécouvrir quelque chose que je savais autrefois… Curieuse sensation… Merci à l'article Prise en main de TLS 1.3 avec OpenSSL 1.1.1 pour le rafraîchissement de mémoire.

Lors de l'incrémentation du serial d'une zone DNS, je me trompe. Au lieu de saisir « 2020052205 », je saisis « 20200522050 » (un zéro en trop). Je demande à OpenDNSSEC de signer la zone (DNSSEC). Puis je me rends compte de mon erreur : dig SOA <domaine> affiche « 3020633059 ». Comment faire redescendre ce serial ?

Normalement, il suffit de décrémenter le serial, de redémarrer le serveur de noms (ou de forcer le chargement de la zone sans contrôle du serial) puis de faire de même sur les slaves. Mais, il y a OpenDNSSEC au milieu et, lui, a une mémoire du serial. Si je signe à nouveau la zone après avoir remis le serial comme il faut, le serial passe à 3020633060.

Essayons naïvement de préciser le serial sur la ligne de commande ?

# ods-signer sign guiguishow.info --serial 2020052206
Error: Unable to enforce serial 2020052206 for zone <CENSURE>.
Zone <CENSURE> scheduled for immediate re-sign.

Regardons les dates de modification dans /var/lib/opendnssec. Aucun fichier modifié récemment sauf une sauvegarde du fichier de zone avant sa dernière signature. Après vérification, OpenDNSSEC ne s'en sert pas comme référence pour le serial.

En fait, le serial est lu dans le fichier de zone non signé lors du démarrage du démon signer puis il est conservé en mémoire vive.

Il suffit donc de stopper le signer et l'enforcer (systemctl stop opendnssec-signer.service opendnssec-enforcer.service), puis de mettre le serial désiré dans le fichier de zone non signé puis de démarrer l'enforcer et le signer (systemctl start opendnssec-signer.service opendnssec-enforcer.service). Le journal d'OpenDNSSEC m'informe :

ods-signerd: [namedb] zone <CENSURE> unable to use datecounter as serial: 2020052200 does not increase 2020052206. Serial set to 2020052207
ods-signerd: [STATS] <CENSURE> 2020052207 RR[count=23 time=0(sec)] NSEC[count=14 time=0(sec)] RRSIG[new=37 reused=0 time=0(sec) avg=0(sig/sec)] TOTAL[time=0(sec)] 

« 2020052206 » est le serial que j'ai écrit dans le fichier de zone non signé.

Lors du chargement de la zone par OpenDNSSEC, BIND9 consigne error: zone <CENSURE>/IN: zone serial (2020052207/3020633062) has gone backwards, mais il recharge la zone.

Sur les serveurs DNS slaves, il faudra utiliser nsd-control force_transfer <nom_zone> ou rndc retransfer <nom_zone> afin de forcer le transfert de la zone réparée sans contrôle préalable du serial.

Fin de l'incident.

Résumé : activation de HTTP/2 sur ce serveur, donc migration vers mpm_event (car HTTP/2 = requêtes en parallèle dans une même connexion ce que ne peut pas gérer mpm_prefork), donc migration du module PHP pour Apache httpd (on rappellera que la fondation Apache publie d'autres logiciels que httpd : Tomcat, Storm, Ant, Kafka, Hadoop, etc.) vers PHP-FPM (car le module n'est pas multithreadé), donc suppression du chroot Apache httpd devenu inutile, donc suppression du chroot BIND9 par homogénéité entre tous les logiciels que j'utilise. Je termine par un joli bug Apache httpd quand on utilise h2c (HTTP/2 sur une connexion non chiffrée). Je rappelle que les navigateurs web prennent en charge uniquement HTTP/2 over TLS (HTTPS/2, quoi).

Il y a quelques mois, j'ai testé l'activation de la nouvelle version du protocole qui soutient le web, HTTP/2.

J'en avais déduis que son fonctionnement « plusieurs requêtes dans une même connexion TCP / HTTP » nécessite plutôt un module de traitement Apache httpd qui gère réellement les requêtes parallèles. Exit mpm_prefork, bonjour mpm_event (recommandé par la doc' officielle d'Apache httpd). Sauf que, le module PHP pour Apache n'est pas utilisable avec mpm_event, justement car il n'est pas multi-tâches. Il faut donc passer à PHP-FPM.

Par défaut, PHP-FPM n'est pas chrooté. Il peut l'être. Vu les emmerdes que ça m'a apporté au fil des ans (voir ici et là), ça en m'intéresse pas. Puisque PHP n'est plus un module d'Apache httpd, est-il encore utile de chrooter ce dernier ? Apache httpd va uniquement manipuler des fichiers statiques, pas de code dynamique avec des saisies utilisateur… Un chroot aura environ aucun intérêt.

J'ai déjà dé-chrooté MySQL car c'était la galère. Si je dé-chroote Apache httpd, il restera BIND9. Chrooter BIND9 m'a posé aucun souci pendant 10 ans. Mais, d'une part, il n'est pas chrooté par défaut, et, d'autre part, je ne l'ai pas totalement chrooté dans les règles de l'art (un chroot doit être hermétique et auto-suffisant, sans lien vers l'extérieur). Virer le chroot de BIND9, c'est assurer l'homogénéité de fonctionnement entre les logiciels que j'utilise, ce qui simplifie la mémorisation de l'architecture technique. Le seul logiciel encore chrooté sera Postfix, mais il est livré ainsi et le chroot m'a jamais posé problème.

Mon chroot MySQL aura tenu 7 ans, mes chroots Apache httpd et BIND9 auront tenu 10 ans. Le module PHP pour Apache httpd aura tenu plus de 10 ans. Pas si mal.

Au final, j'ai :

• Dé-chrooté BIND9 ;
  
  
• Dé-chrooté Apache httpd ;
  
  
• Migré du module PHP d'Apache httpd à PHP-FPM ;
  
  
• Activé HTTP/2 dans Apache httpd ;

Dé-chroot-er BIND9

Aucune difficulté : il suffit de copier (cp -a) les fichiers de zone, les clés, les journaux de transferts de zones, etc. du chroot vers l'emplacement hors chroot (/etc/bind par défaut, mais j'ai l'habitude de séparer la configuration du contenu en mettant la conf' dans /etc et le contenu dans /var/named comme l'on sépare le contenu d'un site web dans /var/www de la configuration d'un serveur web dans /etc∕) puis de retirer l'option « -t » dans /etc/default/bind9 puis de redémarrer BIND9. Si aucune erreur est consignée dans le journal, on peut supprimer le chroot avec un rm -r.

Dé-chroot-er Apache httpd

Il faut copier (cp -a) le contenu des sites web (les DocumentRoot) depuis l'emplacement du chroot vers /var/www puis retirer les directives de configuration ChrootDir et LoadFile du fichier /etc/apache2/apache2.conf. Dans chaque hôte virtuel (aka virtualhost), il faut s'assurer que les directives DocumentRoot et Directory sont toujours valables (si le chroot était bien fait, elles devraient l'être).

Côté module PHP pour Apache httpd, il faut annuler la bidouille du script de nettoyage régulier des sessions PHP et virer le paramétrage d'un magasin de certificats x509 interne au chroot plutôt que le magasin par défaut du système.

Enfin, on redémarre Apache httpd. Si aucune erreur est consignée dans le journal, on peut supprimer le chroot avec un rm -r.

Migrer du module PHP d'Apache httpd à PHP-FPM

J'ai déjà tout écrit dans mon shaarli sur mon test de HTTP/2 donc je vais faire court.

Il faut…

Installer PHP-FPM avec apt-get install php-fpm.

Dans la configuration des hôtes virtuels (aka virtualhosts) d'Apache httpd, il faut retirer les directives php_admin_value. Si l'on veut les conserver et que leur valeur est commune à tous les hôtes virtuels, on les déplace dans le php.ini (/etc/php/7.3/fpm/php.ini). Si non, il faut créer autant de pools que de virtualhosts et mettre les directives php_admin_value dans la définition d'un pool (/etc/php/7.3/fpm/pool.d/www.conf, par exemple).

Remplacer prefork par event : a2dismod mpm_prefork && a2enmod mpm_event.

Désactiver le module PHP et activer l'utilisation de PHP-FPM : a2dismod php7.3 && a2enconf php7.3-fpm. Si t'as plusieurs pools, il ne faut pas activer cette conf' généraliste, mais ajouter une directive de proxy fcgi spécifique (socket différente) à l'intérieur de chaque hôte virtuel.

Redémarrer Apache httpd. Si aucune erreur est consignée dans le journal, on peut désinstaller le module PHP pour Apache httpd : apt-get autoremove --purge libapache2-mod-php libapache2-mod-php7.3 && rm -r /etc/php/7.3/apache2.

Les erreurs / avertissements / notifications liées au code PHP (oubli d'un point virgule, mauvais échappement d'une chaîne de caractères, etc.) sont toujours consignées dans le fichier error.log d'un hôte virtuel. Les erreurs liées à PHP-FPM toutes pools confondus (nombre maximum de processus atteint, etc.) sont consignées dans le journal d'erreur de PHP, /var/log/php7.3-fpm.log). Il est possible d'avoir un journal par pool en surchargeant error_log dans la définition du pool.

Par défaut, le pool www est éxecuté sous le compte utilisateur www-data, c'est-à-dire… celui du serveur web. Comme avec le module PHP pour Apache httpd. On peut changer ça (ainsi que les droits sur les fichiers des sites web) mais, boarf, la motivation me manque.

Activer HTTP/2 dans Apache httpd

J'ai déjà tout écrit dans mon shaarli sur mon test de HTTP/2 donc je vais faire court : a2enmod http2 && systemctl restart apache2.

Je rappelle viteuf qu'il y a trois manières d'initier une connexion HTTP/2 : extension TLS ALPN, entête HTTP/1.1 « Upgrade: h2c » sur connexion non chiffrée ou entête HTTP/1.1 « HTTP Alternative Services ». **Les navigateurs web, notamment Mozilla Firefox, prennent en charge exclusivement la première méthode (HTTP/2 over TLS, HTTPS).

Lulz

On notera un truc rigolo dans le journal Apache httpd access.log de l'hôte virtuel lors d'un accès h2c (HTTP/2 sur une connexion en clair, non TLS, non chiffrée) :

2001:db8::1 - - [01/Jan/1970:01:00:00 +0100] "GET / HTTP/2.0" 200 132608 "-" "curl/7.64.0"
2001:db8::1 - - [15/Feb/2020:17:56:05 +0100] "GET / HTTP/1.1" 101 132733 "-" "curl/7.64.0"

La connexion HTTP/2 qui a forcément eu lieu après la connexion HTTP/1.1 est consignée avant… et avec un horodatage inexact.

Cette erreur se retrouve dans les entêtes transmis au client web :

HTTP/1.1 101 Switching Protocols
Upgrade: h2c
Connection: Upgrade

HTTP/2 200 
date: Thu, 01 Jan 1970 00:00:00 GMT
server: Apache
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
pragma: no-cache
last-modified: Sat, 15 Feb 2020 17:08:49 GMT
vary: Accept-Encoding,User-Agent
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: text/html; charset=utf-8

Évidemment, cela a un impact sur la durée du cache côté client web et sur tout ce qui utilise la date… ÉDIT DU 23/11/2020 À 22 H 40 : Cela impacte le calcul de la date dans l'entête « Expire » sur une image, par exemple, mais, dans cet exemple précis, la date qui apparaît dans l'entête « Expires » n'est pas une erreur de calcul liée à la date faussée par le bug h2c, mais une date symbolique passée choisie par les développeurs de PHP pour désactiver la mise en cache lors de l'ouverture d'une session sur un site web. FIN DE L'ÉDIT.

On a un VPN Cisco ASA. On voudrait changer sa configuration depuis chez soi. On pourrait le faire en CLI (ligne de commande, via SSH), mais la création d'un compte utilisateur et l'association de règles de filtrage est pénible à comprendre. Pas envie de faire un effort pour un équipement en fin de vie. Comme d'habitude, utilisons ASDM (Adaptive Security Device Manager), une GUI (interface graphique) sous forme d'applet java.

D'habitude, ça fonctionne, mais là, après la saisie de l'identifiant et du mot de passe, ça coince : Unable to launch device manager from vpn.mycompagny.example.

Il n'est pas difficile de deviner qu'on se fait dégager par une règle de filtrage. Hé oui, contrairement à d'habitude, on est côté WAN, la joie du télétravail. Il est normal de réserver l'administration d'un équipement (réseau ou non) à des connexions internes. Établir le VPN avant de tenter une connexion changera rien : le trafic à destination du VPN n'est pas encapsulé dans le VPN, sinon ça ferait une boucle infinie. ;)

On pourrait passer en CLI pour s'autoriser dans l'ACL appliquée sur l'interface WAN. Boarf. C'est un coup à oublier de la refermer. On aurait dû prévoir une interface réseau d'administration dédiée. Comme ça, une connexion à travers le VPN aurait fonctionné. Mais on ne l'a pas fait, on ne va pas revenir sur ça sur un équipement en fin de vie.

Utilisons la fonctionnalité port forwarding de SSH ?

En pratique :

• Établir le VPN ;
  
  
• sudo ssh -L443:<IP_du VPN>:443 <identifiant>@<nom_serveur_à_l'intérieur_du_réseau> ;
  
  
• echo -e '\n127.0.0.1\tvpn.mycompagny.example' | sudo tee -a /etc/hosts ;
  
  
• javaws "https://vpn.mycompagny.example/admin/public/asdm.jnlp".

Après usage, ne pas oublier de nettoyer : sudo sed -i '/vpn.mycompagny.example/d' /etc/hosts.

Ce qui me fait dire que c'est de l'intox, c'est que je le vois revenir avec l'argument du : "si ça se paye pas, ça tue le business". C'est tendancieux et généralement faux, non ?
Malgré de bonnes solutions libres (et souvent gratuites), je ne vois pas de domaine ou le business ne peux plus jouer le game. Au contraire même peut-être. (c'est un ressenti j'ai pas fait d'étude de marché lol).

Je ne discuterai pas des non arguments "pas sûr, pas pro", etc. : ils ont été démontés trouzemille fois.
Considérer que libre = gratuit, c'est partir sur de mauvaises bases, de toute façon. J'essaye de financer mes logiciels libres, même si c'est souvent impossible pour les petits logiciels qui n'ont pas de mécanismes de collecte de fonds et pour les logiciels piliers / cachés (FreeBSD / PF pour PFSense, par exemple. Le fait de payer une prestation + licence PFSense ne fait pas automatiquement remonter du pognon à FreeBSD -> il faut demander / faire pression sur la société commerciale éditrice de PFSense pour qu'elle le fasse systématiquement). J'essaye que mon employeur en fasse autant : BIRD, Proxmox, OpenVPN, PFSense, Asterisk, etc. tu peux acheter du support ou des licences à la société commerciale éditrice. Donc, oui, le libre, ça rogne potentiellement des parts de marchés aux autres solutions, mais comme autre tout produit ou service, libre ou non, quoi, ça n'empêche pas le business. Ça vit de modèles économiques différents (don, vente de support / prestations intellectuelles, mutualisation par la demande, licences, fonctionnalités supplémentaires, etc.). Donc, là encore, ce n'est pas le sujet, et encore moins pour les salariés puisque l'argent ne sortira pas de leur poche.

ça n'a pas tardé avant d'avoir des demandes auprès des managers... sans réponses. (alors qu'on nous casse les couilles toute l'année pour "se former"). Faut se former mais faut pas que ça coûte, surtout en temps, la ressource qui vaut plus cher que ton petit cul de travailleur. Bref, nos managers ne se mettent pas au niveau qu'il nous impose (comment les respecter à terme ?)...

J'ai aussi entendu ça : "il faut se former afin de continuer à produire de la valeur qui sera captée par l'employeur, mais ça serait bien de ne pas s'absenter pour autant parce que sinon la société commerciale perd du fric". Tu le sens, le bel avenir des MOOC et autres formations continues à distance que tu pourras faire en dehors du temps de travail ? :))))

Je rejoins le râlage de seb (ou de Framasoft, April, LQDN, ...) sur la priorité : que les pouvoirs publics ne soient pas sur ce registre affectif, certains fonctionnaires ont une responsabilité pour proposer de nouvelles solutions et ils doivent avoir les moyens en conséquences ! Le discours officiel est aussi une priorité : valoriser équitablement les solutions et LAISSER UNE MARGE aux utilisateurs.

Personnellement, je préfère m'attaquer aux serveurs de la fonction publique et à leurs logiciels : il y a énormément plus de données personnelles et d'intelligence de ce côté-là que sur le PC de Ginette qui, soit se connecte aux logiciels distants, soit saisit des documents qui seront par nature publics (compte-rendu du Conseil d'Administration, acte de nomination, etc.). En situation de sous-effectif voulu (on dégrade le service en privant de ressources ceux qui le font tourner -> le citoyen râle -> on impose l'externalisation en expliquant que ça va résoudre tous les problèmes), ça me semble plus pertinent de prioriser cet aspect-là. Laisser une marge, ça consiste aussi à ne pas râler en permanence, à ne pas vouloir imposer le libre dans le public (ce qui était la position de l'April sur la loi pour une République numérique), et à accepter qu'un utilisateur te dise "je ne veux pas de ta merde, même si c'est dans le référentiel bidule du ministère machin".

Je pose ça là, le jour où quelqu'un me montre encore des réticences à utiliser du Logiciel Libre dans le public sous prétexte que "gggnnn c'est pas professionnel gggnnn c'est pas approuvé ggggnnn c'est du libre donc le code source et lisible donc c'est piratable et c'est pas sûr aaannnnn".

Je ne comprends pas où tu veux en venir. Ce socle vaut rien. Il existe aucune obligation d'y recourir. C'est un annuaire comme un autre, on ne peut pas s'en servir comme argument d'autorité, ça ne passe pas dans les administrations (je parle en connaissance du terrain, tu ne feras pas changer de cap un administrateur système des fonctions publiques en sortant ce référentiel, c'est totalement hors sujet à ses yeux).

D'ailleurs, à côté de ça, les groupements d'intérêt public en charge de mutualisations logicielles / collaborations qui dépendent directement des ministères ne se gênent pas pour imposer du Oracle et autres merveilles privatrices afin d'utiliser leur solution mutualisée quasi-obligatoire, donc bon…

Enfin, quand tu vois la DINUM qui veut généraliser Qwant, tu comprends que ce genre de référentiel n'est pas réalisé uniquement sur des qualités techniques, mais aussi sur des enjeux politiciens, et, là, tu deviens prudent.

Je ne sais pas d'où viennent les propos "libre = piratable = pas sûr = pas pro", mais je présume qu'ils sont issus d'une causerie stérile entre informaticiens. Les utilisateurs ne disent pas ça. Ils n'ont même pas les compétences pour affirmer ce genre de choses, et surtout, ils s'en fichent complet et à raison. Tu ne vas pas demander à Jojo de savoir comment fonctionne la machine-outils dans l'atelier et de s'il existe des alternatives éthiques, gnagna. Jojo est payé pour suivre un algorithme (presser le bouton bleu, puis faire ci, puis le bouton triangulaire, puis…), rien à foutre du reste. De même, Ginette s'en fout de comment marche son ordinateur : elle est là pour empocher une somme de pognon précise en faisant un taff précis, comme chacun d'entre nous, salarié ou non. L'ordinateur (ou la machine-outils) est seulement un outil, un moyen pour parvenir à une fin.

Durant des années, des collègues ont sincèrement essayé de promouvoir un système GNU/Linux Ubuntu (totalement géré par le service informatique, comme les winwin qu'on distribue) et LibreOffice : la greffe n'a pas pris. Et les """"arguments"""" sont loin d'être une réflexion métaphysique sur le sens du libre, sa sécurité, blablabla. On a eu les retours suivants (j'exagère un peu, mais dans leurs tickets d'assistance, tu lis vraiment la colère, matérialisée, entre autres, par beaucoup de points d'exclamation) :

• "Je me suis fait chier à faire une formation MS Office, donc je veux un MS Office, faîtes pas chier !". Pour ceux que ça intéresse : oui, on propose des formations MS Office et des formations LibreOffice. Oui, la RH les annonce en même temps sur le même canal. Simplement, LibreOffice, ça parle à personne. Ceux qui lisent quand même l'offre de formation ne veulent pas prendre le risque d'apprendre un truc minoritaire qu'ils ne sont pas sûrs de pouvoir valoriser dans le temps (tout le monde dans le public n'est pas fonctionnaire, pour rappel) ;
  
  
• "J'ai le droit à mon MS Office, comme j'ai le droit à un bureau et à une chaise. Ça fait partie de mon environnement de travail, de mes conditions de travail, point ! Faites pas chier avec votre radinerie !" ;
  
  
• "Faire du graphisme / de la retouche avec GIMP ?! Vous êtes sérieux ?! Vous avez déjà essayé, au moins ?! Faites pas chier, je veux mon Mac, mon Illustrator et mon Photoshop. Laissez-moi exercer mon métier !".

Bref, arrêtons d'utiliser nos arguments d'informaticiens (libre = pas sûr, pas pro, gnagna), le débat avec les utilisateurs n'est pas du tout sur ce terrain. On est sur de l'affect (comme la deuxième personne sus-citée qui se sentait clairement dévalorisée de ne pas avoir de MS Office : pour elle, le prix qu'on met dans son environnement de travail est un indicateur de l'attention qu'on lui prête, et quand t'es payée que dalle sans possibilité d'évolution, je comprend qu'on se rattache à ce genre de choses), sur un effet de réseau / marketing (premier point), et sur un manque d'alternatives crédibles sur certains métiers couplé à un melon des libristes qui sont convaincus que leur solution fait le taff sans connaître celui de la personne à laquelle ils proposent une alternative trop-trop meilleure.

Je partage ton analyse mais je suis partagé sur ta conclusion :).

Je pense que tu te trompes (à moitié) sur ce que tu penses être ma conclusion. Elle n'est pas « c'est comme ça à l'état de nature, donc faisons rien », mais plutôt « arrêtons de blâmer un groupe social en particulier (LREM, PS, UMP, peu importe, tous ont pratiqué l'exclusion punitive) alors que les autres groupes sociaux dont nous sommes membres (emploi, famille, potes, associations) ont la même pratique ». Si tous les groupes sociaux observables ont cette pratique d'exclusion (et je rappelle que la prison est basée sur cette idée d'exclusion protectrice), alors blâmer un groupe qui la pratique est vain, ce n'est pas le bon discriminant pour porter une critique de ce groupe social.

Et surtout je sais que l'individu peut changer le groupe. Pour le pire te le meilleur. En fait y'a une balance ou un aller-retour entre ce qu'apportent les personnes au collectif et ce qu'impose le groupe à ses membres. AMHA.

Ça, c'est dans la théorie. Dans la pratique, il ne faut pas que les individus remuent trop / dépassent l'épaisseur du trait / partent dans tous les sens en permanence… sinon, par définition, il n'y a plus de cohérence, donc plus de groupe. C'est tout le paradoxe. Pour moi, l'injonction à être soi-même au sein d'un groupe (quel qu'il soit) est un mensonge (mais il est nécessaire), ça ne peut pas fonctionner sauf si peu d'individus sont eux-mêmes (les autres pourront alors tolérer ces orignaux) ou que les membres du groupe sont très similaires (et dans ce cas… ils ne sortiront pas de la norme du groupe, par définition même).

Je pense qu'il existe un bloqueur au niveau de l'espèce humaine afin que tous les membres de l'espèce ne désirent pas tout changer en même temps tout le temps. Je pense que ce bloqueur est facteur de stabilité, et donc qu'il est l'un des facteurs de la survie de l'espèce. C'est la grille de lecture que j'applique aux combats militants. Ils se plaignent (et je fais partie du lot) que les gens ne s'impliquent pas et préfèrent regarder Netflix, gagnagna. C'est une mauvaise lecture. En vrai, la masse est garante de la stabilité de la société en mode "ouais, ouais, testez votre idée entre vous, là, on vous regarde" (si ça foire, une petite partie de l'espèce sera sacrifiée dans le pire des scénarios).

Il faut bien se dire que si tout le monde bougeait sur tous les sujets possibles, ça serait impossible de suivre tous ces changements (déjà que, dans notre monde où relativement peu d'acteurs bougent, on n'arrive pas à suivre tous les projets en cours à notre taff, ni les projets de lois, les positions des associations et de la société civile, etc. …) et, surtout, chacun aurait plus de boulot (hé oui, car la personne qui milite avec toi sur la vie privée par exemple, ne partage pas ta vision de la société concernant l'agriculture, et comme elle se bouge… elle te nuit, donc va falloir bouger aussi sur les sujets autour de l'agriculture), ça serait juste éreintant.

Soit t'es godillot, soit tu te barres. Interdit de voter en son âme et conscience chez LREM. Si tu n'es pas du même avis que le Roy et que tu oses le dire au travers d'un vote --> la porte

C'est un reproche que je vois souvent formulé à l'encontre des partis politiques alors que ce mécanisme ("si t'es pas d'accord avec la majorité du groupe, tu te casses ou, à défaut, on va t'exclure soit formellement, soit de fait") est aussi en vigueur dans un emploi, dans une association, avec des potes (j'ai pas écrit « amis »), dans la famille, etc. C'est naturel : tout remettre en question en permanence contre le groupe rend ce groupe vulnérable en plus d'être juste chiant et épuisant. Il faut une forme de cohésion dans un groupe social, et ça passe par un mensonge / récit commun, des codes communs, des pratiques communes et un respect individuel des décisions du groupe. C'est la pensée de meute commune à tout groupe social.

Arf, en effet je travaille sur le site ça impacte un peu l'accès le temps que ça se tasse.

Hé bah bravo ! :P

Bon si tu as déjà testé alors je comprends, c'est très particulier et il vaut mieux éviter les gênes. Chacun son truc :).

C'est ça. ^^

Du coup l'hommage c'est que sur ma capture, il y a un onglet du navigateur avec ton logo, voilou :)

Ho, oui ! C'est le début du commencement du départ de ma célébrité universelle. \o/

(lol Le dictateur :P j'y ai même pas pensé)

Pourtant je travaille très dur pour en devenir un. :'(

Bonne nuit. :D