GuiGui's Show

Bien joué pour l'analyse du problème. :)

Le PC-P de @Lenny tout comme le mien ont une partition Ext4 chiffrée ! Or mon PC Fixe a une partition en clair et il faut savoir qu'une partoche Ext4 en claire permet des chemins de fichiers de 255 caractères tandis qu'une Ext4 chiffrée est limitée à 143 caractères ! Le voilà notre coupable...

Quel procédé utilises-tu pour chiffrer ta partition ext4 ?

Pour ma part, j'utilise dm_crypt+luks et je peux utiliser les 255 octets (oui, octets, pas caractères : si tu mets un caractère Unicode dans un nom de fichier, tu perds 2 octets alors qu'un seul caractère est affiché) autorisés par ext4 pour un nom de fichier. La longueur maximale du chemin d'un fichier permise par ext4 est de 4 096 octets. C'est logique que dm_crypt ne réduise pas cette limite d'ext4 car il se place au-dessous de tout système de fichiers.

J'en déduis que t'utilises probablement une surcouche cryptographique aux systèmes de fichier comme EncFS ou eCryptfs. La limite que tu rencontres viendrait donc de cette surcouche cryptographique, pas du fait que tu utilises de la crypto (regarde, j'en fais et je conserve la limite de 255 octets).

Grâce à toi, j'ai découvert qu'ext4 propose le chiffrement natif. J'ai essayé viteuf : c'est bien bien bien le bazar. La taille maximale du nom d'un fichier est toujours de 255 caractères.

J'ai voulu signaler leur problème DNS à la Banque Populaire et à la Caisse d'Épargne, mais impossible de leur envoyer un email.

Le serveur emails pour tous les domaines dont font partie les adresses emails techniques trouvées dans les bases de données publiques accessibles avec le protocole whois (et bientôt RDAP ?) est mail-in.bpce-it.fr.

Celui-ci refuse mes emails pour le motif suivant : « 550 #5.7.5 DKIM unauthenticated mail is prohibited. If you believe that this failure is in error, please refer to https://tools.ietf.org/html/rfc6376 or contact postmaster [à] bpce-it.fr for more information via alternate means. »

J'ai bien envoyé mon courriel via le seul serveur emails autorisé pour mon domaine.

Étrangement, un email envoyé par Stéphane depuis un domaine qui n'implémente pas DKIM passe très bien. Cela illustre que DKIM n'est pas obligatoire pour communiquer avec BPCE. Peut-être qu'une signature DKIM devient obligatoire quand la réputation de l'adresse IP ou du réseau du serveur emails émetteur est questionnable ? Mon serveur est hébergé chez OVH, émetteur de spam malgré lui, alors que celui de Stéphane est dans un réseau IP de bonne réputation.

Encore plus étrange : mes emails sont bien signés en suivant la norme DKIM. Peut-être y a-t-il un problème technique de mon côté ?

Je m'envoie un email à une autre adresse que je gère et qui met en œuvre la validation DKIM : à l'arrivée, les entêtes de l'email confirment qu'il comporte bien une signature DKIM et que celle-ci est valide : « Authentication-Results: viki.guiguishow.info; dkim=pass (3072-bit key; secure) header.d=[CENSURE] header.i=@[CENSURE] header.b="PGTxFJuT"; dkim-atps=neutral ».

Il existe des testeurs de serveur emails. J'en ai utilisé trois (plus que ça en vrai, mais certains ne fonctionnent plus) : https://www.mail-tester.com/ , auth-results [à] verifier.port25.com , et ping [à] stamper.itconsult.co.uk . Tous les trois confirment la présence et la validité d'une signature DKIM dans mes emails sortant. Il semble donc que le problème est du côté de BPCE.

De plus, j'ai configuré une politique ADSP souple, « dkim=all » qui signifie "normalement, tout courriel émanant de ce domaine sera signé, mais si ce n'est pas le cas, ne le jete pas à la corbeille, stp". Évidemment, elle a la valeur d'un conseil : le récepteur fait bien ce qu'il veut.

Pour signer les entêtes de mes emails sortant, mon serveur emails utilise une clé RSA 3072 bits. C'est la taille recommandée par l'ANSSI (document B1) pour mettre sérieusement en pratique de la cryptographie au long terme. Mais, c'est vrai que, pour signer des emails dans le cadre de la lutte anti-spam (c'est l'objet de DKIM), une clé de taille inférieure serait suffisante.

Je conçois bien un problème à ce niveau-là : ma clé est rejeté en raison de sa taille, donc mon email est considéré comme étant non signé, donc, soit la réputation du réseau de mon serveur emails joue contre lui, soit BPCE-IT est intransigeant avec les domaines qui ont une politique ADSP fût-elle souple.

A priori, ce souci a été signalé à BPCE-IT par Stéphane, merci. :)

Depuis au moins jeudi 28 mai 2020 à 22 h 45 (UTC+2), impossible d'accéder à certains sites web du groupe Banque Populaire Caisse d'Épargne :

• https://www.banquepopulaire.fr ne fonctionne pas (vitrine + SSO) ;
  
  
• https://www.ibps.loirelyonnais.banquepopulaire.fr ou https://www.ibps.bpaca.banquepopulaire.fr ou https://www.ibps.mediterranee.banquepopulaire.fr/ ne fonctionnent pas (accès à l'espace personnel) ;
  
  
• https://groupebpce.com/ fonctionne.
  
  
• ÉDIT DU 31/05/2020 À 14 H 05 : www.caisse-epargne.fr est également impacté, voir Problème DNS BPCE : la Caisse d'Épargne également impactée. FIN DE L'ÉDIT DU 31/05/2020.

Qu'est-ce qui ne fonctionne pas, précisément ? La résolution des noms DNS. Mon navigateur web Mozilla Firefox affiche « Recherche de […] » puis « Hum, nous **ne parvenons pas à trouver ce site. ».

Comme d'habitude, Twitter fournit des témoignages dont le plus savoureux relate :

Bonjour @BanquePopulaire impossible de se connecter avec l’application sur iPhone depuis hier soir et donc de déverrouiller ma carte bancaire... C’est un problème général?

À quel moment tu t'es dit que c'est génial de débloquer une carte bancaire avec un logiciel pour ordinateur de poche ?! Tout peut foirer ! Ton ordinateur de poche peut tomber en panne, ton opérateur de téléphonie mobile aussi, un opérateur Internet de transit idem, Banque Populaire également, etc. Ce choix d'une telle dépendance à une technologie est hallucinant.

J'ai mon accès à Internet fixe chez le Fournisseur d'Accès à Internet associatif FDN et j'utilise les serveurs DNS récursifs de ce dernier. Le problème est le même depuis un serveur OVH (en utilisant les serveurs DNS récursifs d'OVH). Le service de résolution des noms de CloudFlare parvient jamais à résoudre le nom. Celui de Google y parvient plutôt souvent, mais il y a encore des ratés.Depuis un accès à Internet Orange avec un dnsmasq local, ça fonctionne difficilement ou pas du tout.

La transmission réseau entre FDN (ou OVH ou Orange) et le réseau Banque Populaire est OK : un mtr -T -P 443 91.135.183.174 montre ni incident réseau ni perte de paquets.

Le niveau applicatif est OK : un openssl s_client -connect 91.135.183.174:443 -crlf permet de dialoguer en HTTPS avec l'un des serveurs de la Banque Populaire. Une mesure depuis le réseau RIPE Atlas confirme cela, voire la mesure numéro 25558553.

Enfin, ajouter une association IP pour les noms www.ibps.bpaca.banquepopulaire.fr et www.banquepopulaire.fr dans mon fichier /etc/hosts rend ces sites web parfaitement fonctionnels. Attention : utiliser ce contournement uniquement pour des tests ! Si Banque Populaire change les adresses IP de ses services, la surcharge locale rendra inaccessibles les services.

On confirme donc un problème de résolution de certains des noms DNS de la Banque Populaire.

Néanmoins, mes mesures avec le réseau RIPE Atlas montre un faible taux d'échec de la résolution DNS : mesure numéro 25556510, mesure numéro 25556573 et mesure numéro 25556574.

Effectuons la résolution DNS à la main :

$ dig @d.nic.fr www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
banquepopulaire.fr.        172800        IN        NS        dns2.bpce.fr.
banquepopulaire.fr.        172800        IN        NS        dns1.bpce.fr.

;; ADDITIONAL SECTION:
dns1.bpce.fr.                172800        IN        A        91.135.189.110
dns2.bpce.fr.                172800        IN        A        91.135.177.110
[…]

$ dig @91.135.189.110 www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.ibps.bpaca.banquepopulaire.fr. 3600        IN NS
nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.177.110 www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.ibps.bpaca.banquepopulaire.fr. 3600        IN NS
nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.182.250 www.ibps.bpaca.banquepopulaire.fr
[…]
;; ANSWER SECTION:
www.ibps.bpaca.banquepopulaire.fr. 30 IN A        91.135.183.174
[…]

$ dig @91.135.189.110 www.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.banquepopulaire.fr.        3600        IN        NS        nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.177.110 www.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.banquepopulaire.fr.        3600        IN        NS        nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.182.250 www.banquepopulaire.fr 
[…]
;; ANSWER SECTION:
www.banquepopulaire.fr.        30        IN        A        91.135.183.180
www.banquepopulaire.fr.        30        IN        A        91.135.183.180
[…]

$ dig @k.gtld-servers.net. groupebpce.com
[…]
;; AUTHORITY SECTION:
groupebpce.com.                172800        IN        NS        dns1.bpce.fr.
groupebpce.com.                172800        IN        NS        dns2.bpce.fr.
[…]

$ dig @91.135.189.110 groupebpce.com
[…]
;; ANSWER SECTION:
groupebpce.com.                3600        IN        A        151.101.194.133
groupebpce.com.                3600        IN        A        151.101.2.133
groupebpce.com.                3600        IN        A        151.101.66.133
groupebpce.com.                3600        IN        A        151.101.130.133
[…]

$ dig @91.135.177.110 groupebpce.com
[…]
;; ANSWER SECTION:
groupebpce.com.                3600        IN        A        151.101.130.133
groupebpce.com.                3600        IN        A        151.101.66.133
groupebpce.com.                3600        IN        A        151.101.2.133
groupebpce.com.                3600        IN        A        151.101.194.133
[…]

On constate trois choses :

• Les noms www.ibps.*.banquepopulaire.fr, www.*.banquepopulaire.fr et www.banquepopulaire.fr sont délégués à un seul serveur de noms DNS qui fait autorité ! C'est une très mauvaise pratique !
  
  
• Le nom corporate (présentation du groupe), groupebpce.com, dispose d'une qualité de service supérieure à celle des noms utilisés par les clients de la Banque Populaire (pour consulter leurs comptes, entrer en contact avec leur conseillère, etc.) : deux serveurs de noms, de multiples adresses IPs sur lesquelles récupérer le contenu du site web, etc. Amusant. Ça expose les priorités. Ça explique pourquoi je parviens à accéder au site web https://groupebpce.com tout en ne parvenant pas à accéder au site web de ma banque régionale Banque Populaire ;
  
  
• Un TTL (durée de vie de l'information associée à un nom DNS dans le cache des serveurs récursifs) très court (30 secondes). Si un tel délai est très utile lors d'une migration afin de rendre la bascule effective sous un court délai, il est très déconseillé le reste du temps, car, ne bénéficiant pas des caches, le moindre problème technique entraînera une panne d'une toute autre ampleur.

Jusque-là, le problème reste entier. Continuons à creuser.

Le serveur qui fait autorité pour les zones www.ibps.*.banquepopulaire.fr et www.banquepopulaire.fr , nsisp1.i-bp.banquepopulaire.fr , répond négativement aux requêtes de types NS et SOA :

$ dig @91.135.182.250 SOA www.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17798
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig @91.135.182.250 NS www.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 36129
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig @91.135.182.250 SOA www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31905
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig @91.135.182.250 NS www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17813
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

Cela est totalement contraire à la norme DNS et cela peut bloquer certaines implémentations de récursifs DNS (voire certaines versions d'une même implémentation), ce qui explique le côté aléatoire de la panne.

Les serveurs DNS dns1.bpce.fr et dns2.bpce.fr répondent aux requêtes de types NS et SOA pour la zone groupebpce.com, ce qui explique que le site web corporate fonctionne là où les autres sites web ne fonctionnent pas.

Le serveur DNS nsisp1.i-bp.banquepopulaire.fr ne répond pas aux requêtes DNS émises au-dessus du protocole TCP :

$ dig +tcp @91.135.182.250 A www.banquepopulaire.fr
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +tcp @91.135.182.250 A www.banquepopulaire.fr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.

C'est, là encore, totalement contraire à la norme DNS : tout serveur DNS doit être accessible sur udp/53 et tcp/53.

Cette absence de réponse aux requêtes de types SOA/NS posera encore plus de problèmes aux récursifs DNS qui implémentent la qname minimisation, un mécanisme qu'il faut activer car il participe à la préservation de la vie privée des utilisateurs d'un serveur DNS récursif. En effet, une divergence d'interprétation de la norme existe concernant la recherche des délégations. On rappelle au passage qu'une délégation DNS ne se voit pas à l'œil nu. Exemples : bpaca.banquepopulaire.fr n'est pas délégué par banquepopulaire.fr, ibps.bpaca.banquepopulaire.fr n'est pas non plus délégué par bpaca.banquepopulaire.fr. Bref : un point entre deux labels d'un nom de domaine ne marque pas forcément une délégation. Afin d'identifier les délégations, certaines implémentations, comme Unbound, effectuent des requêtes de type A (que le serveur DNS nsisp1.i-bp.banquepopulaire.fr accepte, pour rappel), d'autres des requêtes de type NS (qui sont refusées par nsisp1.i-bp.banquepopulaire.fr).

Concernant l'amplification du problème par certaines implémentations de qname minimisation dans les serveurs DNS récursifs , le mystère continue, car :

$ dig +short @80.67.169.40 version.bind chaos txt
"unbound 1.6.0"

$ dig +short @80.67.169.12 version.bind chaos txt
"unbound 1.9.0"

$ dig +short @::1 version.bind chaos txt
"unbound 1.9.0"

$ dig +short @80.67.169.12 www.ibps.bpaca.banquepopulaire.fr
;; connection timed out; no servers could be reached

$ dig @80.67.169.12 www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33639
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig +short @::1 www.ibps.bpaca.banquepopulaire.fr
91.135.183.174

En clair : une même version d'Unbound œuvrant sur le même réseau IP, deux comportements différents. Que j'active ou non la qname-minimisation sur mon Unbound local (sur mon accès à Internet fixe FDN, donc), ça fonctionne. Peu importe le type de qname-minimisation, souple ou stricte.

Même chose avec un BIND9.16 sur mon accès à Internet FDN : quelle que soit la configuration retenue pour la qname-minimisation (« strict » ou « relaxed »), ça fonctionne. J'ai réussi à obtenir un « SERVFAIL » en mode « relaxed », mais je n'arrive pas à le reproduire sur demande (même en redémarrant BIND, même en le stoppant+rallumant).

Dans le sens inverse, on peut exposer que le résolver de CloudFlare implémente la qname-minimisation (source) et que, justement, il ne parvient pas à résoudre les noms de la Banque Populaire sus-mentionnés.

Bref, on peut affirmer tout et son contraire.

Mais, pourquoi les sondes du réseau RIPE Atlas ne remontent-elles pas un taux d'échec de la résolution DNS plus élevé ? Concentration des serveurs DNS récursifs utilisés. Au sein d'un même réseau, celui d'Orange par exemple, tous les clients (au sens commercial du terme) vont utiliser le même serveur DNS récursif, celui d'Orange (ou celui de Google Public DNS ou celui de CloudFlare). Si le serveur DNS récursif parvient à résoudre le nom une fois, toutes les sondes Atlas situées dans ce réseau en bénéficieront le temps du TTL (durée de rétention de l'information dans le cache du serveur récursif, 30 secondes dans le cas présent). Rappelons que les serveurs DNS récursifs de certains réseaux, comme Free, sont connus pour ré-écrire les TTL jugés courts (les ignorer, donc), ce qui permet de limiter l'ampleur de l'effet "ça marche, ça marche plus, ça marche, etc.".

Les TTL courts amplifient l'aspect "ça marche, ça marche plus".

Alors, au final, quelle est l'origine du problème ?

Difficile à dire. On le saura jamais vraiment, toute entité (société commerciale, administration, association, personne) étant toujours très réticente à faire des retours sur ses erreurs / fautes / échecs.

Je pense qu'il y a une middlebox entre Internet et le serveur DNS qui fait autorité nsisp1.i-bp.banquepopulaire.fr qui, comme tout boîtier externalisé prétendument magique imposé au service informatique par la direction afin qu'elle puisse prétendre œuvrer pour la sécurité des clients sans investir ni comprendre / maîtriser la technique sous-jacente, doit bloquer certaines requêtes DNS de manière excessive (sur-blocage). Qu'est-ce qui me fait penser cela ? L'implémentation de serveur qui fait autorité est un BIND 9.11.5-P4 (dig @91.135.182.250 CH TXT version.bind ;) ). Ce logiciel refuse de charger une zone DNS dénuée de NS/SOA (« zone [CENSURE]/IN: has 0 SOA records […] zone [CENSURE]/IN: has no NS records […] zone [CENSURE]/IN: not loaded due to errors. »), donc, si l'on a des réponses, sauf pour les types NS et SOA, c'est probablement un intermédiaire entre nous et le serveur qui les vire.

Néanmoins, ça n'explique pas l'intégralité du problème. Pourquoi deux serveurs récursifs DNS avec la même version d'Unbound ne parviennent pas au même résultat ? Pourquoi la plupart des serveurs DNS récursifs de la planète parviennent à résoudre les noms de la Banque Populaire ? Les différentes implémentations de qname-minimisation amplifient-elles le problème ? Aucune idée…

La Banque Populaire est coutumière d'une configuration DNS défectueuse.

En 2015, le nom banquepopulaire.fr était délégué à deux serveurs de noms Orange Business Services (ex Oléane) qui n'étaient pas configurés pour ce nom (on nomme ça une lame delegation). Les deux autres serveurs DNS qui font autorité étaient internes au groupe BPCE et cessaient de répondre aux requêtes (UDP et TCP) au moins une fois par semaine, et notamment le dimanche matin entre 11 h et 12 h. Amusant, non ?

Comme ces derniers jours, il y avait des tweets (notamment celui-ci), mais ça n'a pas suffit. Stéphane Bortzmeyer et moi-même avons envoyé des emails à toutes les adresses BPCE pertinentes trouvées. Il a fallu deux mois avant d'avoir un acquittement (email acquitté le 24/08) et plusieurs mois pour que le problème soit corrigé…

Merci à Stéphane Bortzmeyer de m'avoir expliqué l'origine probable de cette panne partielle. L'outil dnsviz m'avait bien pointé l'absence de réponse aux requêtes de type SOA/NS de la part du serveur nsisp1.i-bp.banquepopulaire.fr , mais je ne l'ai pas interprété correctement.

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 trois suites cryptographiques toutes basées sur le chiffrement intègre (AEAD) afin de palier 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 c'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é 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) ;

  • 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).
• 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 Bort).

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.

Avec le sous-programme s_client d'OpenSSL, cette manip' ne fonctionne pas et 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. Comme la (ou les) bibliothèque TLS n'efface pas les secrets consignés lors de sessions précédentes ou par d'autres programmes (elle 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.

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…

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.