GuiGui's Show

Quels médias français ont mangé chez Google en 2018 ? La réponse est dans le rapport 2018 du Digital News Innovation Fund (DNI), la partie européenne du programme mondial Google News Initiative.

Je mets une copie de ce rapport de côté, au cas où il disparaîtrait, comme ceux du Fonds pour l'Innovation Numérique de la Presse (2013-2016, le précurseur du DNI).

France
TOTAL FUND €10.2m
PROJECTS 41

[…]

Funded organisations
20 MINUTES
AGENCE FRANCE PRESSE
ATANAS TCHOBANOV
BAYARD PRESSE
CAMERA LUCIDA PRODUCTIONS
CASUS LUDI
CCM BENCHMARK GROUP
COSAVOSTRA
EURONEWS
FRONTLINE MEDIA
GEN TRAINING & CONSULTING
GROUPE LA DÉPÊCHE DU MIDI
GROUPE LES ECHOS
IJSBERGPRESS
L’EQUIPE 24/24
LA NOUVELLE RÉPUBLIQUE DU CENTRE OUEST
LE FIGARO
LE MONDE
LE PARISIEN
LE PARISIEN LIBÉRÉ
LES JOURS (125 000 €)
M6
MELTYGROUP
METEO CONSULT
MONDAY NOTE
NEXTINTERACTIVE
PLAYPLAY
POOOL
PRISMA MEDIA
RADIO FRANCE
THE CONVERSATION FRANCE
USBEK & RICA
VOXEUROP
WEDODATA
WORLDCRUNCH

Sans oublier le fonds Google Youtube pour l'innovation / News on Youtube qui n'est pas inclut dans le rapport sus-mentionné (via le Canard enchaîné).

3 médias français ont participé :

HugoDécrypte
Le Monde
Société Brut SA

On ne sait pas encore combien de fric Google a mis sur la table pour ces trois-là, mais Google promet que leur audience Youtube a augmenté. Comment avoir confiance puisque Google est Youtube ?

TL;DR : HTTP/2 est possible uniquement au-dessus de TLS avec nginx. HTTP/2 est possible avec ou sans TLS avec Apache httpd, mais, avec un système Debian GNU/Linux Stretch cela nécessite mpm_event ou mpm_work (c'est recommandé par la fondation Apache pour Debian Buster et autres systèmes), ce qui, dans mon cas, signifie migrer préalablement vers PHP FPM. Bref, j'ai encore du taff.

Que faire en 2020 pour avoir la hype alors qu'on est un retardataire blasé par le progrès technique ? Activer TLS 1.3, la nouvelle version du protocole de sécurisation (confidentialité, authenticité et intégrité) des communications sur Internet ? Le retardataire a uniquement des systèmes Debian Stretch qui livrent la version 1.1.0 d'OpenSSL. Or, la version 1.3 de TLS nécessite la version 1.1.1 d'OpenSSL au minimum.

Bon bah alors, activer HTTP/2, le nouveau protocole qui soutient le web ? Faisons ça, avec Apache httpd et nginx.

Apache httpd

Avec la version d'Apache httpd packagée dans la version Stretch de Debian GNU/Linux, il n'est pas possible d'activer HTTP/2 avec le module de multitraitements mpm_prefork (source, confirmé par /usr/share/doc/apache2/NEWS.Debian.gz). Notons que la documentation officielle Apache httpd ne recommande pas d'activer HTTP/2 avec mpm_prefork et préconise plutôt l'utilisation de mpm_event.

Oui, mais avec mpm_event (ou mpm_worker), il n'est pas possible d'utiliser le module PHP pour Apached httpd (car mpm_event est multithread, pas le module PHP). Il faut utiliser FPM ou FastCGI. Hé ouais, le retardataire utilise encore le module PHP…

Du coup, le test de HTTP/2 se fait ainsi :

• Dans la configuration d'Apache httpd, retirer toutes les directives de conf' qui dépendent du module PHP, comme « php_admin_value » ;
  
  
• Désactiver le module PHP : a2dismod php7.0 ;
  
  
• Remplacer mpm_prefork par mpm_event : a2dismod mpm_prefork && a2enmod mpm_event ;
  
  
• mpm_event a besoin de la bibliothèque de fonctions libgcc_s sinon il ne traitera pas les requêtes et crachera en permanence ce qui suit dans le journal error.log : « child pid XXXXX exit signal Aborted (6) libgcc_s.so.1 must be installed for pthread_cancel to work ». Installons-la : apt-get install libgcc-6-dev ;
  
  
• Si, comme moi, tu as chrooté ton Apache httpd (quelle très mauvaise idée, bis), il faut activer le chargement de cette bibliothèque avant le chroot() en ajoutant la ligne suivante dans /etc/apache/apache2.conf : LoadFile /usr/lib/gcc/x86_64-linux-gnu/6/libgcc_s.so.1 ;
  
  
• On active HTTP/2 : a2enmod http2 ;
  
  
• HTTP/2 est activé par le module lui-même (Protocols h2 h2c http/1.1 dans /etc/apache2/mods-available/http2.conf). On peut surcharger ça dans un serveur virtuel. Pour un serveur virtuel HTTPS (TLS), la ligne de config' est Protocols h2 http/1.1. Pour un serveur virtuel HTTP, la ligne de config' est : Protocols h2c http/1.1. On peut aussi mettre du h2c dans du TLS, le module sait faire avec même si ça produira aucun effet ;
  
  
• HTTP/2 force l'utilisation de la version 1.2 de TLS et de SNI ainsi que la désactivation de la compression TLS et de la renégociation TLS. La norme impose également l'utilisation de suites de chiffrement décentes. L'agencement proposé par défaut par Apache httpd 2.4 dans Debian Stretch, « HIGH:!aNULL », fait le taff. Idem pour l'agencement que j'utilise : « ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM ». Mais si ton installation est un peu ancienne, peut-être devrais-tu y jeter un œil, car, actuellement, le module http2 d'Apache httpd ne vérifie / corrige pas cela. Je note que la norme veut que le serveur puisse rejeter la communication si ces exigences ne sont pas satisfaites, pas qu'il le doit, et, dans la pratique, j'ai testé du HTTP/2 au-dessus de TLS 1.0 (et TLS 1.1) sans problème ;
  
  
• On redémarre Apache httpd : systemctl restart apache2.

nginx

J'ai jamais eu de PHP sur mon serveur web géré par nginx et il y a jamais eu d'histoire de module de pré-traitement avec nginx. Du coup, l'activation d'HTTP/2 devrait être plus facile que pour Apache httpd, non ? Oui avec un serveur virtuel HTTPS (TLS), non avec un serveur virtuel HTTP.

Dans un serveur virtuel HTTPS

Source.

• Il suffit de compléter la directive « listen » avec l'option « http2 ». Exemple chez moi : avant = « listen [::]:443 default_server ipv6only=off ssl » ; après : « listen [::]:443 default_server ipv6only=off ssl http2; » ;
  
  
• HTTP/2 force l'utilisation de la version 1.2 de TLS et SNI ainsi que la désactivation de la compression TLS et de la renégociation TLS. La norme impose également l'utilisation de suites de chiffrement décentes. L'agencement proposé par défaut par nginx dans Debian Stretch, « HIGH:!aNULL:!MD5; », fait le taff. Idem pour l'agencement que j'utilise : « ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM ». Mais si ton installation est un peu ancienne, peut-être devrais-tu y jeter un œil, car, actuellement, nginx ne vérifie / corrige pas cela. Je note que la norme veut que le serveur puisse rejeter la communication si ces exigences ne sont pas satisfaites, pas qu'il le doit, et, dans la pratique, j'ai testé du HTTP/2 au-dessus de TLS 1.0 (et TLS 1.1) sans problème ;
  
  
• On redémarre nginx : systemctl restart nginx.

Dans un serveur virtuel HTTP

Sans TLS, le client web ne peut pas possible utiliser l'extension TLS ALPN (Application Layer Protocol Negociation) pour indiquer qu'il veut communiquer en HTTP/2.

Le client web pourrait causer HTTP/1.1 et positionner l'entête « Upgrade: h2c » qui est l'un des mécanismes permettant de monter en HTTP/2, mais nginx ne permet pas cela.

Il reste une possibilité : que le serveur positionne un entête HTTP Alternative Services qui indique au client que le même service est disponible en HTTP/2. Le client web cause alors en HTTP/2 en utilisant la méthode « prior knowledge » (différente de TLS + ALPN et de HTTP/1.1 + entête Upgrade). Sauf que, si l'on positionne la directive de configuration « http2 » sur une socket HTTP, nginx cause directement HTTP/2, donc pas de HTTP/1.1 (ou 1.0) avec un entête pour informer le client web. Donc le serveur virtuel devient accessible uniquement en HTTP/2. Il faudrait que le serveur virtuel port 80 positionne cet entête en redirigeant vers un serveur virtuel sur le port 81, par exemple. Sauf que, à ce jour, les clients web (cURL y compris) n'implémentent pas les services alternatifs HTTP.

Si l'on veut, on peut activer HTTP/2 comme dans un serveur virtuel HTTPS et tester avec curl -D - --http2-prior-knowledge <URL>. Mais, pour rappel, ton site web ne sera plus accessible en HTTP/1.1 ou HTTP/1.0. Ni en HTTP/2 avec la plupart des clients web actuels.

Tester

Apache httpd ou nginx, il faut tester le bon fonctionnement des manipulations décrites ci-dessus.

On peut tester avec curl -D - --http2 <URL> (« -D - » permet d'afficher les entêtes HTTP de la réponse, donc de vérifier la présence d'un « HTTP/2 » dès la première ligne).

On peut aussi utiliser l'onglet réseau des outils de développement de Firefox, mais, attention si tu utilises HTTP (non sécurisé) : Firefox ne positionne pas l'entête HTTP/1.1 « Upgrade: h2c » qui est l'un des mécanismes permettant de monter en HTTP/2. Curl le positionne. Bref, toujours avoir un wireshark en bandoulière.

On peut enfin regarder le journal des requêtes sur son serveur web, car la version y est mentionnée genre « GET / HTTP/2.0 ».

Bref, HTTP/2 avec Apache httpd, ça fonctionne, mais ça nécessite que je migre du module PHP à PHP-FPM ou que je mette à jour mon système vers la version Buster de Debian. Avec nginx, HTTP/2 fonctionne uniquement au-dessus de TLS en attendant que les clients web prennent en charge les services alternatifs HTTP ou que nginx gère h2c (« HTTP/2 in clear ») sans connaissance préalable de la part du client.

Comme je l'ai écrit mardi, ma banque me fait désormais utiliser une saloperie de clavier virtuel pour saisir mon mot de passe de connexion à mon espace client sur son site web. Un mot de passe d'exactement 8 chiffres… Une saloperie de clavier qui fait chier en réduisant le confort d'utilisation tout en diminuant la sécurité du client que je suis.

Un des points clés permettant de comprendre la diminution de la sécurité, c'est que ça fait belle lurette que les logiciels malveillants ne sont plus bloqués par les claviers virtuels. Il y a une multitude de méthodes pour récupérer le mot de passe malgré eux. Il y a les extensions malveillantes pour navigateurs web conçues pour retrouver la correspondance clic->image->chiffre. Il y a la traditionnelle capture vidéo de l'affichage. Il y a aussi la traditionnelle interception des flux réseaux, y compris ceux chiffrés (genre HTTPS). Les antivirus et les serveurs mandataires (proxy) d'entreprise / d'administration font ça depuis belle lurette aussi. Analyse HTTPS qu'ils disent. Pour notre sécurité qu'ils disent. Rien de nouveau : quand un attaquant est à l'une ou l'autre des extrémités d'une communication, il peut tout faire sans avoir à se donner la peine de casser le chiffrement soutenant la communication.

J'ai eu envie de voir le clavier virtuel de ma banque sous l'angle d'une interception du trafic HTTPS. Évidemment, sur mon propre identifiant + mot de passe, tout ça, tout ça.

Ça se fait très bien avec mitmproxy. J'ai découvert cet outil dans une causerie de l'ami Aeris au nom évocateur : Comment powned une application bancaire en 30 minutes.

On installe mitmproxy sur un système Debian GNU/Linux : sudo apt-get install mitmproxy.

On l'exécute : mitmproxy --socks ou mitmweb --socks si l'on veut l'interface web en suplément. --socks active le mode proxy SOCKS. Plusieurs modes sont disponibles.

Le certificat d'une autorité de certification x509 maison est automatiquement généré dans .~/mitmproxy/mitmproxy-ca-cert.pem. On l'importe dans le catalogue des autorités de certification reconnues de notre navigateur web (Firefox : Édition -> Préférences -> Vie privée et sécurité -> Certificats -> Afficher les certificats -> Autorités -> Importer… -> choisir -> Confirmer cette AC pour identifier des sites web -> OK). J'utilise un profile Firefox vierge (firefox -p pour en créer un) afin de ne pas pourrir le mien et pour que seul le site web de ma banque soit intercepté (ça rend l'analyse plus lisible, moins de flux interceptés).

Pour simplifier, je configure mitmproxy comme proxy SOCKS (127.0.0.1:8080) de mon navigateur web (Firefox : Édition -> Préférences -> Général -> bouton « Paramètres… » dans la rubrique « Paramètres réseau ». Comme ça, je n'ai pas besoin de conduire une "vraie" attaque de l'homme du milieu (sinon j'aurais choisi une machine virtuelle configuré en passerelle réseau de mon ordinateur et, pour une vraie de vraie attaque MitM, j'aurai sorti ettercap). Et ça nous permet de vivre comment agit un proxy installé dans une entreprise / administration au nom de la prétendue sécurité de celle-ci et au détriment de la vie privée des employés. ;)

Je me connecte au site web de ma banque. Je saisis mon identifiant et je valide le formulaire. Ho, une requête HTTP POST a été capturée par mitmproxy. Son contenu :

{
    "validate": {
        "<identifiant_unique_de_la_transaction>": [
            {
                "id": "<identifiant_unique_de_la_transaction>", 
                "login": "toto", 
                "type": "IDENTIFIER"
            }
        ]
    }
}

Intéressant (oui, j'avais bien saisi « toto » comme identifiant).

Le clavier virtuel s'est affiché. Je saisis mon code et je valide. Nouvelle requête HTTP POST :

{
    "validate": {
        "<identifiant_unique_de_la_transaction>": [ 
            {
                "type":"PASSWORD",
                "id":"<identifiant_unique_de_la_transaction>",
                "password":"9ad8e027-86d9-4f9e-8ae9-3114e6c6bc78 9ad8e027-86d9-4f9e-8ae9-3114e6c6bc78 9ad8e027-86d9-4f9e-8ae9-3114e6c6bc78 9ad8e027-86d9-4f9e-8ae9-3114e6c6bc78 9ad8e027-86d9-4f9e-8ae9-3114e6c6bc78 9ad8e027-86d9-4f9e-8ae9-3114e6c6bc78 0711f5af-3e90-449f-bbe9-c55f08450a7d 92e47c70-00ab-4b88-95af-ab19cbad6644"
            }
        ]
    }
}

On voit clairement qu'il y a 8 groupes de blocs de chiffres… Comme les 8 chiffres de mon mot de passe.

Si mon navigateur web a émis ceci, c'est qu'il a été préalablement informé de la marche à suivre. Il y a forcément une convention entre le serveur de ma banque et mon navigateur web. Regardons les échanges précédents dans mitmproxy :

GET […]/api/v1u0/medias/images/imgb6ad9545-e3be-455f-9dd6-7b9e0de59c25 Content-Type: image/png
GET […]/api/v1u0/medias/images/imgb7f60f3f-5dff-4ba8-a85c-9fbf938c03e0 Content-Type: image/png
GET […]/api/v1u0/medias/images/img32e8d95a-67b7-409a-92ae-e200aedb0961 Content-Type: image/png
GET […]/api/v1u0/medias/images/img9ad8e027-86d9-4f9e-8ae9-3114e6c6bc78 Content-Type: image/png
GET […]/api/v1u0/medias/images/img8971b94e-7f4c-49c1-acb4-bce2b0db4498 Content-Type: image/png
GET […]/api/v1u0/medias/images/img0711f5af-3e90-449f-bbe9-c55f08450a7d Content-Type: image/png
GET […]/api/v1u0/medias/images/img4710dc98-9eae-4492-9cd3-a8250ee7c827 Content-Type: image/png
GET […]/api/v1u0/medias/images/img92e47c70-00ab-4b88-95af-ab19cbad6644 Content-Type: image/png
GET […]/api/v1u0/medias/images/img93292639-12e1-45c8-ba22-16107ad657d3 Content-Type: image/png
GET […]/api/v1u0/medias/images/img9d799ee1-166a-43af-a750-bbe3e7286c6b Content-Type: image/png

Ho bah dis donc, 10 fichiers image, comme les 10 chiffres du clavier virtuels ! Exemple : le fichier img9ad8e027-86d9-4f9e-8ae9-3114e6c6bc78 est une image du chiffre 6. Des fichiers son sont nommés selon la même nomenclature. Exemple : /api/v1u0/medias/sounds/snd9ad8e027-86d9-4f9e-8ae9-3114e6c6bc78 = chiffre 6. Ils sont utilisés par la version du clavier virtuel accessible aux handicapés visuel.

Hum, dis donc, le nom d'un fichier contient un bloc de chiffres qui ressemble à ceux du JSON, non ? C'est bien ça. 9ad8e027-86d9-4f9e-8ae9-3114e6c6bc78 = 6. Donc mon mot de passe est 666666XX . 0711f5af-3e90-449f-bbe9-c55f08450a7d représente un 4 et 92e47c70-00ab-4b88-95af-ab19cbad6644 un 2. Donc mon mot de passe est 66666642. C'est bien ce que j'avais saisi sur le clavier virtuel, en tout cas.

Pour info, le nom des fichiers images changent à chaque tentative de saisie d'un mot de passe, tout de même.

Évidemment, l'utilisation de mitmproxy est de trop puisque les outils de dév' de Firefox permettent de voir le nom des images ainsi que le mot de passe encapsulé en JSON dans la requête POST. Mais ça nous a fourni un alibi pour jouer avec mitmproxy. :D

Du coup, ouais, n'importe quelle saloperie installée dans le navigateur web a accès à mon mot de passe, en JS ou autre… Et c'est à peine plus difficile à enregistrer que le contenu d'un champ XHTML standard. Les claviers virtuels, c'est du pipeau.

XiVo est une solution de téléphonie complète en logiciel libre (GPL, LGPL) développée en France. Elle est basée sur l'autocommutateur téléphonique Asterisk (je me suis déjà un peu amusé avec). XiVo propose une surcouche comme une interface web bien foutue et des API (pour changer les droits d'appel ‒ appels nationaux, internationaux, vers des numéros surtaxés, etc. ‒, pour changer le nom d'une ligne, etc.).

XiVo sait faire toute la téléphonie d'entreprise habituelle : appels, interception d'appel, renvoi d'appel (tout ou conditionné), filtrage d'appel (dit patron/secrétaire), files d'attente, messagerie vocale, diffusion d'un message éventuellement conditionné à un calendrier, salon de conférence, etc. Je crois que le seul truc que ça ne fait pas, c'est des rapports de facturation genre agréger la consommation des lignes téléphoniques d'un service afin de faire de la refacturation interne (le service informatique paye l'intégralité de la facture de téléphone et refacture leur consommation aux autres services) et de présenter aux chefs la consommation de leurs sous-fifres sous une forme kikoo-jolie.

Nous utilisons cette solution depuis 5 ans. Nous avons deux machines virtuelles Debian GNU/Linux + XiVo en failover sur deux sites géographiques pour la partie commutation, deux lignes téléphoniques T2 avec deux passerelles T2<>IP XiVo, des téléphones IP, des téléphones analogiques avec des rocades analogiques et des passerelles analogique<>IP Patton et Realtone, des logiciels de téléphonie (softphones) + XiVo client (qui permet des recherches dans l'annuaire, de voir qui nous appelle, de transférer simplement un appel, etc.), et des saloperies automatiques qui nécessitent une ligne de téléphone (ascenseurs, interphones, etc.) soit un total de 850-900 lignes.

L'éditeur de XiVo, Avencall, propose des prestations d'intégration et de support pour tout le périmètre sus-cité, une liste de matériels totalement compatibles (genre un téléphone IP avec les touches de fonction ‒ intercepter l'appel d'une autre ligne, par exemple ‒ fonctionnelles, genre des casques audio avec les boutons de fonction ‒ muet, sourd, etc. ‒ fonctionnels) et de la revente de matos (genre des téléphones IP, des cordons de téléphone, etc.). D'autres prestataires / revendeurs existent sur le marché, mais nous avons été déçu par le précédent.

Merci Seb' d'avoir monté et entretenu tout ça toutes ces années. :)

Des collègues se plaignent que les modifications qu'ils effectuent dans notre IPAM (interface web de gestion des adresses IP et de la conf' DHCP et DNS ‒ quelle IP est utilisée ? À qui est-elle attribuée ? Dans quel VLAN ? Etc. ‒) maison ne deviennent pas effectifs dans le DNS. Un collègue diagnostique l'usage d'un underscore dans le nom d'une machine, caractère qui serait invalide dans le DNS et bloquerait nos serveurs de noms BIND.

Je tique. À l'école Bortzmeyer, on a appris que le DNS impose une seule limitation concernant les noms, c'est leur taille. De plus, de nos jours, l'underscore est utilisé dans plein de noms DNS. DKIM (signature électronique de l'entête des emails afin d'authentifier le domaine d'émission), DANE TLSA (réparer l'énorme faille conceptuelle des certificats x509 utilisés pour authentifier les parties d'un échange chiffré ‒ TLS, par exemple ‒, voir un exemple d'utilisation ici). Jabber (protocole de messagerie instantanée textuelle libre et fédéré). Tous utilisent l'underscore, et ça se passe très bien.

Je regarde le journal de notre serveur DNS (BIND) : « nom-de-machine_a_suppr.mon-organisation.example: bad owner name (check-names) ». C'est donc vrai. Whaaat ?! :O Il y a donc une contradiction entre la théorie et la pratique.

Un essai me montre que, sur un BIND récent (9.10, packagé dans Debian Stretch), on peut ajouter un nom contenant un underscore si son type est SRV ou TXT, mais pas si son type est A ou AAAA. Cela met en exergue un comportement qui va au-delà de la norme, qui est sans doute spécifique à une implémentation.

L'école Bortzmeyer nous a aussi appris qu'il y a une différence entre un nom de machine et un nom de domaine et que les caractères autorisés pour un nom de machine sont beaucoup plus restreints que pour un nom de domaine. Mais… ça ne change rien, BIND manipule bien un nom de domaine, donc il devrait autoriser l'underscore, qui est un caractère valide pour un nom de domaine (mais pas pour un nom de machine).

Il devrait, oui, mais, par défaut, BIND vérifie que les noms associés à un type A ou AAAA respectent la syntaxe d'un nom de machine. L'idée est de dire que, 99 % du temps, l'administrateur voudra associer une IP à un nom de machine, car ce nom sera manipulé par des programmes qui manipulent des noms de machines et l'admin voudra que ça fonctionne. On peut débrayer ce comportement avec les directives de configurations « check-names ».

Un essai avec nsd 4, autre implémentation d'un serveur DNS qui fait autorité, montre aucun problème : il est parfaitement possible d'associer un nom de domaine avec un underscore à une adresse IP.

Si l'on résume : un nom de domaine a bien aucune limite concernant les caractères qui le composent, mais une implémentation de serveur DNS comme une autre, BIND, a fait le choix de bloquer les noms DNS qui ne respectent pas la syntaxe d'un nom de machine (lettres + chiffres + tiret) quand ils sont associés à un type A ou AAAA ou MX. D'après la doc', BIND vérifie également la syntaxe de la valeur d'un nom de domaine (le RDATA) pour les types SOA, NS, MX, SRV et PTR.

Un autre point m'échappe. Avant de pousser en production le fichier de zone généré par notre IPAM, nous utilisons un script de contrôle maison qui se repose, entre autres, sur named-checkzone. Il s'agit d'un outil livré avec BIND. Pourquoi a-t-il rien détecté ?

Le contrôle de la syntaxe des noms a été introduit dans la version 9.2 de BIND 9, mais il n'est pas activé par défaut. Sur les serveurs DNS maîtres, il est activé par défaut depuis la version 9.3.

named-checkzone vérifie la syntaxe des noms à partir de la version 9.3 de BIND 9, mais il se contente d'émettre un avertissement. C'est toujours le cas dans la dernière version stable (9.14).

Donc, forcément… Vu qu'il écrit tout sur stdout, si named-checkzone ne sort pas en erreur, notre script considère que tout est OK et met le fichier de zone en production. Tout s'explique.

Solutions ? Soit débrayer le contrôle de la syntaxe des noms dans la conf' de BIND, soit forcer named-checkzone à sortir en erreur si le contrôle de la syntaxe des noms échoue en utilisant son option -k fail, soit utiliser une autre implémentation de serveur DNS (BIND veut assurer les deux grands services distincts du DNS ‒ serveur qui fait autorité et serveur récursif ‒ + il veut implémenter toutes les fonctionnalités à la mode + il est monolithique = il est plus difficile à sécuriser).

Pour moi, ce contrôle de la syntaxe des noms de domaine est illégitime en cela qu'il n'est pas conforme à la norme, même s'il évite des prises de tête aux administrateurs (mais il en donne à d'autres, comme moi…).

C'est dans ce genre de moments que je me réjouis d'avoir une monoculture de serveurs DNS (d'utiliser que du BIND au sein d'une même architecture) : si l'on avait eu une diversité de serveurs de noms, certains auraient accepté le fichier de zones et d'autres non, ce qui aurait causé quelques instabilités sur le réseau et aurait rendu la mise en exergue du problème compliquée (le diagnostic n'aurait pas changé : un coup de check-soa, on aurait vu un numéro de série différent, on aurait analysé les journaux, etc.).

Je voudrais savoir si les utilisateurs de notre Wi-Fi 802.1X (WPA2-EAP / WPA2-Enterprise) indiquent leur identifiant complet, c'est-à-dire avec le realm. Comment journaliser ce dernier avec freeRADIUS ?

Dans le protocole réseau RADIUS, un realm joue le rôle d'un domaine. Il désigne une organisation, une entité. Ainsi, un identifiant est composé d'une partie locale, d'un (ou plusieurs) délimiteur, et d'un (ou plusieurs) realm. Ça ressemble à l'email ou à Jabber, hein ? Le principe est le même. Dans l'email, la partie à droite de l'arobase désigne l'organisation dans l'Internet et la partie de gauche, un identifiant unique au sein de cette organisation. Ce realm permet de transmettre une requête d'authentification à un RADIUS plus compétent.

Exemple concret ? Eduroam est un service Wi-Fi qui permet à un membre d'une université (étudiant, enseignant, personnel, etc.) de se connecter en Wi-Fi depuis une autre université. C'est ce qu'on nomme itinérance. Comment ça fonctionne ? Le contrôleur Wi-Fi de l'université d'accueil reçoit la demande de connexion d'un client Wi-Fi (ordinateur, ordiphone, etc.). Il transmet la requête d'authentification aux serveurs RADIUS de l'université. Ceux-ci analysent un realm qui n'est pas le leur. Ils transmettent la requête aux serveurs RADIUS nationaux (en France, ils sont gérés par RENATER, le fournisseur d'accès à Internet ‒ et bien plus ‒ des entités d'enseignement supérieur et de recherche, par exemple). Ceux-ci analysent également le realm. Si l'université d'affectation est française, la requête est transmise à ses serveurs RADIUS. Sinon, on remonte à la racine d'eduroam, et on redescend jusqu'à l'université d'affectation en passant par le pays. C'est donc l'université d'affectation qui autorise (ou non) la connexion sur le Wi-Fi de l'université d'accueil. L'université d'accueil n'a pas a connaître le mot de passe de l'utilisateur. Mieux, elle ne le voit pas passer puisque l'on utilise PEAP ou EAP-TTLS, c'est-à-dire des tunnels chiffrés entre le client Wi-Fi et le serveur RADIUS de l'entité d'affectation.

C'est aussi comme cela que fonctionnent les accès à Internet (ADSL, fibre, etc.) quand on est chez un Fournisseur d'Accès à Internet qui ne dispose pas de machines dans chaque répartiteur téléphonique. Exemple : l'opérateur associatif FDN utilise une offre de l'opérateur commercial Liazo qui loue les lignes à Orange ou SFR. Un identifiant imaginaire "toto/fdn@liazo.sfr" (notons la présence de deux realms, chaque opérateur, Liazo et SFR, utilisant un realm différent, « / » pour Liazo, « @ » pour SFR) permet aux RADIUS de SFR (qui répondent aux équipements réseaux de SFR qui sont à l'autre bout de la ligne de l'abonné, dans le central téléphonique) d'envoyer la requête d'authentification vers les serveurs RADIUS de Liazo qui enverront à FDN pour validation et pour savoir où envoyer le trafic de l'abonné. Ainsi SFR n'a pas à enregistrer les clients de Liazo dans son système d'information ni les membres de FDN.

Bref, on nomme proxy RADIUS cette fonctionnalité de renvoi des requêtes.

Je pense que tu auras compris pourquoi nous voulons journaliser temporairement l'identifiant complet saisi par nos utilisateurs : certains ne mettent pas le realm et se plaignent que "Internet marche pas quand je suis en déplacement !!! c'est un scandale d'envergure internationale !!! J'exige que…". Forcément, sans realm, le RADIUS de l'organisation d'accueil croit que l'identifiant est local, donc il cherche dans ses bases de données locales (LDAP, etc.), trouve rien et envoie bouler. L'idée est donc d'avoir des statistiques sur le nombre d'utilisateurs concernés, leur type, etc. afin d'envisager (ou non) des campagnes de prévention ciblées plus ou moins automatisées.

Par défaut, RADIUS journalise ce genre de message : « Auth: Login OK: [guigui] ». Il reste donc que la partie locale, plus le realm.

On pourrait ajouter l'option nostrip dans la définition de notre realm ? Erreur, car, alors, notre RADIUS cherchera, dans notre annuaire LDAP, un utilisateur dont l'identifiant sera identifiant + realm. Notre annuaire LDAP ne trouvera pas un tel objet et l'authentification sera refusée.

Ce qu'on va faire, c'est journaliser les attributs contenus dans la requête RADIUS d'authentification (Access-Request) émise par le contrôleur Wi-Fi (ou un proxy RADIUS connu) avant son traitement.

Pour ce faire, on va se reposer sur le module « detail » de freeRADIUS, l'implémentation libre la plus connue d'un serveur RADIUS.

Si l'on le souhaite, on peut modifier la configuration du module « detail », mais ce n'est pas obligatoire. La conf' qui nous intéresse est dans le fichier /etc/freeradius/3.0/mods-enabled/detail.log (dans les vieilles versions de freeRADIUS, c'est dans modules/detail.log). Perso, je change :

• Dans le bloc « detail auth_log », je commente « detailfile = ${radacctdir}/%{Client-IP-Address}/auth-detail.log » et j'ajoute une ligne « detailfile = ${logdir}/realm.log ». Motif : je n'ai pas envie d'avoir un dossier par utilisateur, ça va être ingérable. Je veux un unique journal pour tous mes utilisateurs et tous mes NAS ;

• Dans le sous-bloc « Suppress » qui prévoit déjà de ne pas journaliser l'attribut « User-Password », j'ajoute les lignes suivantes afin de supprimer tous les attributs sauf le User-Name et ainsi de maîtriser l'occupation disque de mon journal :

  Packet-Type
  FreeRADIUS-Proxied-To
  EAP-Message
  MS-CHAP-Challenge
  MS-CHAP2-Response
  State

Il nous reste à déclencher la journalisation là où nous en avons besoin. Le commentaire dans la conf' nous indique que ça se passe dans le bloc authorize. Oui, mais dans quel serveur virtuel ? Default ou inner-tunnel ?

Si nous journalisons dans le serveur virtuel default, nous allons récolter toutes les demandes d'authentification adressées à notre RADIUS, y compris celles émanant de notre portail captif. Or, sur ce dernier, il est normal de ne pas saisir son realm, car il n'est pas accessible en mobilité. Au contraire, saisir son realm ne fonctionne pas. Pour nos stats, nous voulons uniquement les clients WPA2-EAP.

De plus, avec EAP, il est possible d'indiquer une identité anonyme, qui sera émise avant que soit établi le tunnel chiffré qui, lui, contiendra le vrai identifiant ainsi que le mot de passe. Ce mécanisme protège d'une interception passive du trafic (bah, ouais, les ondes Wi-Fi, c'est super simple à intercepter. Une interface Wi-Fi en mode monitor et un wireshark et hop). Parfois, on n'a pas envie de crier qui l'on est tout autour de soi. Notons que, dans un système d'itinérance comme eduroam, il est nécessaire indiquer a minima le realm dans l'identité anonyme afin que les proxy RADIUS intermédiaires transmettent la requête EAP jusqu'au RADIUS de l'organisation d'affectation. Il s'agit donc d'une identité anonyme toute relative.

Pour ces deux raisons, nous comprenons que nous voulons journaliser à l'intérieur du tunnel EAP. Nous modifions donc le fichier /etc/freeradius/3.0/sites-enabled/inner-tunnel. Au début du bloc authorize, nous ajoutons une ligne auth_log.

Un petit redémarrage du serveur (systemctl restart freeradius) et c'est prêt. Le journal sera créé lorsque le premier utilisateur se présentera.

Si l'on a peur que le journal occupe beaucoup d'espace disque (pour 3 000 utilisateurs réguliers, j'ai journalisé environ 3 mo/jour), on peut demander à logrotate de compresser les vieux journaux tous les jours. Pour ce faire, on ajoute les lignes suivantes dans /etc/logrotate.d/freeradius :

/var/log/freeradius/realm.log {
        copytruncate
}

Voilà.

Sources d'inspiration : freeradius-sp et freeradius-idp.

TL;DR : si t'as un boîtier VPN Cisco ASA ou Fortinet qui ne fonctionne plus (établissement du VPN bloqué à 98 %) ou qui fonctionne partiellement (quand il est établit, des sites web ne s'affichent plus, des connexions SSH ne s'établissent plus) lorsqu'il est utilisé avec un partage d'une connexion 4G Bouygues pro et que tu n'as pas déployé IPv6 sur ton réseau (côté serveur VPN, donc), alors tu as un problème de MTU lié aux mécanismes de traduction IPv6<>IPv4 (NAT64, DNS64, 464XLAT, etc.). Je n'explique pas cela puisque la traduction IPv4->IPv6 consomme seulement 20 à 28 octets supplémentaires alors qu'il m'a fallu descendre la MTU de 114 octets. Nous constaterons, sans savoir l'expliquer, que la MTU possible à l'intérieur d'un même VPN établi au-dessus d'une traduction IPv6<>IPv4 diffère entre la version 7 et la version 9 d'Android. Peut-être que tous ces problèmes résident dans la manière dont Android gère le partage de connexion (genre filtrage excessif d'ICMPv6) ? Configurer, sur un Cisco ASA, une MTU de 1288 octets à l'intérieur des VPN TLS corrige le tir. Pas d'idée pour Fortinet. OpenVPN sur UDP n'est pas impacté (TCP non testé). :)

Nous avons un boîtier VPN Cisco ASA que nous utilisons pour établir des VPN TLS. En octobre 2019, un collègue informaticien en déplacement établit une connexion VPN en utilisant le client libre openconnect sur son ordinateur GNU/Linux raccordé à Internet via le partage Wi-Fi de connexion 4G de son ordiphone professionnel. Il ne parvient pas à accéder à l'interface web de notre Mattermost (Slack-like libre et auto-hébergé) ni à d'autres sites web internes (nous ne permettons pas d'accéder à Internet à travers notre VPN). Il ne parvient pas non plus à se connecter en SSH à plusieurs de nos serveurs : il n'a pas la demande de saisie du mot de passe (le déploiement de l'authentification par clé progresse lentement…). En revanche, ça fonctionne pour d'autres serveurs. Tous les serveurs testés sont dans le même réseau et une même règle de filtrage est appliquée par notre pare-feu en ce qui concerne SSH et le web. Il peut ping les serveurs avec lesquels il ne peut pas établir de session SSH.

J'emprunte son ordiphone, j'active partage de connexion, et je reproduis le problème avec mon ordinateur GNU/Linux. Un coup de wireshark est sans appel : il s'agit d'un problème de MTU. Je t'ai déjà expliqué ce qu'est la MTU, son origine et les problèmes associés. Quand tu essayes d'accéder à une ressource web, que la poignée de main TCP se passe bien, mais que le navigateur web ne reçoit plus de réponse du serveur web après lui avoir envoyé une requête GET, c'est très souvent un problème de MTU. Et pour le comportement de SSH ? J'ai mis du temps à comprendre. Il était possible d'établir une session SSH avec de vieux serveurs (Debian 8 ou inférieur), mais pas avec des serveurs Debian 9. Wireshark montrait un blocage dès la poignée de main SSH (quand le client et le serveur s'échangent leur bannière). Le paquet « Key Exchange Init » du serveur n'arrivait jamais au client. Normal, SSH sur Debian 9 propose plus de suites de chiffrement, donc le paquet SSH « Key Exchange Init » est plus gros (1076 octets contre 948 octets).

Comment expliquer ce changement de MTU ? Rancid montre aucun changement dans la configuration de notre boîtier VPN depuis des années. Même chose côté routage et pare-feu (mais s/années/mois/). Je suis étonné que personne se soit plaint plus tôt. Je pense à un problème partiel visant uniquement certains équipements. J'emprunte l'ordiphone d'une collègue, partage de connexion, tout ça, et là, ça fonctionne. Le client VPN est le même (openconnect sur mon ordinateur GNU/Linux), donc il est à exclure. Le boîtier VPN est identique, donc il est à exclure. Il reste le réseau entre les deux. Un des ordiphones fonctionne avec Android (marche pas), l'autre avec IOS (marche). L'un utilise un forfait Bouygues pro (marche pas), l'autre un forfait Orange perso (marche). Il y a donc quelque chose avec Android + Bouygues Pro.

Intuitivement (on verra plus loin que je bluffe), je pense au déploiement d'IPv6 sur le réseau Bouygues. Sur le moment, je trouve, sur le web, un article qui expose que, bien que Bouygues a proposé IPv6 très tôt (mi-2017), l'opérateur était en train de le forcer progressivement comme protocole réseau par défaut. Évidemment, à l'heure de rédiger ce shaarli, je ne retrouve pas ledit article, graaah. :( IPv6 n'est pas du tout déployé dans mon organisation (oui, je sais, je sais… On ne déploiera pas dans les prochaines années :( ). Donc, depuis un réseau IPv6, une connexion à notre serveur VPN utilise forcément un mécanisme de traduction IPv6<>IPv4 mis en place par l'opérateur (Bouygues, Orange, Free, SFR, etc.).

À titre de comparaison, l'ARCEP, l'autorité administrative de régulation des télécoms, nous informe que, sur les offres mobiles, Bouygues est le principal acteur a avoir activé IPv6 à la mi-2019 (configuration automatique et à distance des ordiphones par l'opérateur pour ce faire) et que la majorité des offres mobiles à mi-2019 sont uniquement IPv6, ce qui suppose un mécanisme de traduction. Dans ces documents de l'ARCEP, on lit qu'Orange a fait un effort pour activer IPv6 sur les iPhone en septembre/octobre 2019, donc que mon test Android versus IOS aurait pu échouer.

Je désactive IPv6 sur l'ordiphone : Paramètres -> Connexions -> Réseaux mobiles -> Nom des points d'accès -> cliquer sur le seul APN proposé -> Protocole APN -> Changer la valeur d'IPv6 à IPv4. Je réactive le partage de connexion, je monte le VPN ASA et… tout fonctionne. Je retire le VPN, je désactive le partage de connexion, je réactive IPv6 sur l'ordiphone, j'active à nouveau le partage de connexion et le VPN : les problèmes reviennent. La cause du changement de la MTU est donc bien liée à IPv6 et à l'utilisation d'un mécanisme de traduction IPv6<>IPv4 sur nos forfaits mobiles Bouygues Pro. C'est difficile à croire, puisque NAT64 implique une surcharge de 20 ou 28 octets seulement et uniquement dans le sens IPv4->IPv6, mais les faits sont là…

Actuellement, la MTU appliquée à l'intérieur de nos VPN ASA est de 1406 octets. J'identifie la nouvelle MTU avec ping -M do -s <taille_variante_en_octets> <destination> (avec le VPN établi, donc). La nouvelle MTU est de 1352 octets. Pour l'appliquer, il faut aller dans ASDM -> Configuration -> Remote Access VPN -> Network (Client) Access -> Group Polices -> double-cliquer sur un groupe -> Advanced -> AnyConnect client -> champ « MTU ».

Je croyais en avoir terminé, mais non. Quelques jours plus tard, un autre collègue informaticien me rapporte ne pas avoir pu se connecter à certains de nos serveurs via le VPN sur un partage de connexion 4G. Il a un ordiphone Android et le même forfait mobile Bouygues pro que le collègue précédent. Ça devrait donc fonctionner !

Je teste avec mon ordinateur et son ordiphone : en effet, ça ne fonctionne pas. J'identifie la MTU : 1288 octets. Je désactive IPv6 sur son ordiphone et ça fonctionne. Je configure cette nouvelle MTU dans notre Cisco ASA, je ré-active IPv6 sur l'ordiphone, et ça fonctionne. Puisque le forfait mobile est identique et que les ordiphones sont de même marque (Samsung), je regarde les versions d'Android : ce collègue a Android 9. Le premier a Android 7. Entre la version 7 et la version 9 d'Android, y a-t-il un réglage différent côté partage de connexion ou une implémentation différente de la traduction d'adresses IPv6<>IPv4 en lien avec l'opérateur ? Aucune idée. :- Je n'arrive pas à expliquer cette différence. J'arrive encore moins à expliquer comment l'activation d'IPv6 sur Android 9 peut faire perdre 114 octets de MTU (1406-1288).

Parallèlement à ces ennuis du quotidien, je testais un produit Fortinet avec le premier ordiphone décrit ci-dessus (Android 7, donc). Aucun souci en partage de connexion 4G avec openfortivpn (implémentation libre d'un FortiClient VPN pour GNU/Linux vu la déplorable implémentation digne d'un étudiant en première année d'informatique livrée par Fortinet). Aucun souci avec l'application mobile officielle pour Android. En revanche, impossible d'établir le VPN depuis un ordinateur winwin 7 ou 10 : FortiClient VPN reste bloqué à 98 % de l'établissement de la connexion avant de revenir au formulaire identifiant+mdp sans afficher un quelconque message d'erreur (classe pour un produit professionnel, non ?). Notre intégrateur Fortinet ne nous a pas proposé de solution.

En désactivant IPv6 sur l'ordiphone, cela fonctionne. Le VPN met longtemps à s'établir, plus de 30 secondes, mais il fonctionne. Donc, on est toujours face à la même cause. Pourquoi le client GNU/Linux fonctionne-t-il ? Probablement pas la même implémentation. L'implémentation libre utilise PPP sur TLS sur TCP. Qu'utilise la privatrice ? TCP, mais après ? En revanche, l'application officielle qui fonctionne sur Android nous oblige à constater que l'origine de tous les problèmes décrits dans ce shaarli pourrait être du côté Android, de son implémentation du partage de connexion 4G, et pas du côté de l'opérateur. Un changement de paramètre côté Android ou quelque chose du genre.

Parallèlement, je testais une solution PFSense+OpenVPN. Force est de constater qu'OpenVPN, dans une configuration UDP (TCP non testé), n'a pas bronché, même sur un partage de connexion 4G avec IPv6 activé. C'est même son journal détaillé qui m'a mis sur la piste IPv6 puisqu'il affichait un « UDP link remote » suivi d'une IPv6 fabriquée par DNS64 reconnaissable par son préfixe « 64:ff9b:: » réservé à l'IANA.

TL;DR : route <réseau> <masque> net_gateway. « net_gateway » est un mot-clé qui désigne l'IP de la passerelle par défaut du réseau local. Elle sera récupérée automatiquement dans la table de routage du système par OpenVPN.

D'habitude, quand j'utilise OpenVPN, c'est pour encapsuler tout mon trafic dans un VPN. Sur le client, j'utilise donc la directive de configuration redirect-gateway def1.

Son effet ? Lorsque le VPN est activé, elle ajoute une route vers l'IP du serveur VPN dont le prochain saut est l'IP de la passerelle par défaut du réseau auquel je suis connecté à l'instant T, puis, elle ajoute deux routes, 0.0.0.0/1 et 128.0.0.0/1, dont le prochain saut est le serveur VPN. Ces deux routes l'emportent sur la route par défaut, 0.0.0.0/0, ajoutée par le client DHCP ou à la mano, car elles sont plus spécifiques (0.0.0.0/0 = tout l'adressage IPv4, 0.0.0.0/1 = seulement la première moitié de cet adressage). Ainsi, tout le trafic est encapsulé dans le VPN sauf le flux qui le soutient qui est envoyé au serveur VPN en utilisant la route dédiée qui envoie le trafic à la passerelle par défaut du réseau.

Aujourd'hui, je ne veux pas donner un accès à Internet aux utilisateurs de mon VPN. Je veux que seuls les réseaux de l'organisation soient accessibles via le VPN. Dans la configuration d'OpenVPN, j'ajoute donc route 198.18.0.0 255.255.0.0. En vrai, j'ajoute une ligne de ce type pour chaque réseau de l'organisation. Sauf que l'IP publique du serveur VPN, 198.18.0.42 est dans le réseau 198.18.0.0/16). Donc, quand le VPN deviendra actif, la route ainsi ajoutée dirigera le flux soutenant le VPN… à l'intérieur du VPN ! Boucle. Le VPN cessera de fonctionner.

Ce qu'il faudrait, c'est ajouter une route plus spécifique vers le serveur VPN… Mais ça suppose de connaître l'IP de la passerelle par défaut du réseau local auquel l'utilisateur du VPN est connecté. Ça change en fonction du réseau ! On pourrait coder un script qui se lancerait lorsque le VPN devient actif (c'est la directive de configuration `route-up'). Mais il faudrait qu'il fonctionne sur winwin, Mac OS, GNU/Linux, Android, IOS, etc. Infaisable.

Heureusement, OpenVPN a tout prévu. Il propose le mot-clé net_gateway pour la directive de configuration route. Ce mot-clé désigne l'IP de la passerelle par défaut du réseau local. Elle sera récupérée automatiquement dans la table de routage du système par OpenVPN.

Ainsi, pour faire ce que je veux, je mets les deux lignes suivantes dans la configuration de mon OpenVPN :

route 198.18.0.0 255.255.0.0
route 198.18.0.42 255.255.255.255 net_gateway

Tout le trafic destiné au réseau 198.18.0.0/16 sera envoyé dans le VPN. Tout échange avec le serveur VPN (198.18.0.42) sera envoyé en dehors du VPN. Le flux UDP ou TCP chifffré échangé avec le serveur VPN sera donc envoyé en dehors du VPN. Il n'y a plus de problème de boucle.

Même le plus récent manuel d'OpenVPN indique que le mot-clé « net_gateway » ne fonctionne pas sur tous les systèmes. Cela me semble être exagéré. J'ai essayé et je peux affirmer que cela fonctionne sur winwin 7, winwin 10, Mac OS X 10.11, GNU/Linux Debian Stretch, Ubuntu 16.04, Android (7 ?) et IOS (version ?).

Évidemment, pour ne pas encombrer le fichier de configuration de mes clients et pour rendre facile l'ajout et la suppression de routes (sans avoir besoin de faire récupérer un nouveau fichier de configuration à tous mes utilisateurs VPN), je configure les clients depuis la configuration du serveur. Les deux lignes précédentes deviennent donc :

push "route 198.18.0.0 255.255.0.0"
push "route 198.18.0.42 255.255.255.255 net_gateway"

Notons que ce mot-clé permet également de ne pas encapsuler des destinations spécifiques dans un VPN avec route par défaut (redirect-gateway def1). Genre ne pas encapsuler Netflix (qui bloque les VPN, proxy, etc.). Genre ne pas encapsuler le trafic vers un résolveur DNS local (parfois, on peut avoir une bonne raison de ne pas utiliser les DNS du fournisseur de VPN genre continuer à pouvoir résoudre des noms locaux au réseau auquel on est connecté). Genre ne pas encapsuler le trafic vers les plages d'adresses RFC1918 (privées) utilisées sur le réseau local, etc.

J'avais entendu parler de la PFR, mais sans plus, en effet. Je débute dans l'boulot, chef. :D Merci pour cette explication et l'historique, du coup. :)

J'évite de parler du RIFSEEP, car le mot « sujétions » déclenche en moi de profondes envies de botter des culs. Ordonnance de 1946, les agents de la fonction publique ne sont pas là pour être les sujets des chefs. « C'est con comme la lune ». Haha, on explique aux gens les trouzemilles petits détails que même les services RH galèrent à comprendre et à appliquer (genre l'intégration de la PFI) ? :-

J'avais bien noté que je peux faire chier mon chef avec ce genre d'astuce, oui. Mais 0) ça me fait chier aussi ; 1) c'est pas tellement lui que je vise, mais plutôt le système d'entretien bidon en lui-même (mais d'un autre côté, il fait le choix, tout en étant fonctionnaire, de les pratiquer, même si la qualité de son rendu semble laisser à désirer du point de vue du service RH) ; 2) mon credo est justement d'affirmer que moins de temps passé en entretien pro (et autres futilités), c'est plus de temps consacré à des choses utiles pour nos usagers. Faire durer l'entretien va à l'encontre de ça.

Les syndicats qui s'accrochent à l'entretien individuel, c'est peut-être lié au fait que l'entretien pro est arrivé dans le privé (puis dans le public) via un Accord National Interprofessionnel, c'est-à-dire une causerie entre syndicats de patrons et de salariés. Tout ça pour un droit à la formation continue (y'a beaucoup à redire sur cette notion : qualité des formations, les magouilles derrière tant côté formateurs que syndicats, la notion même de former des gens afin qu'ils survivent aux fermetures de leurs usines plutôt que de botter le cul des patrons véreux, etc.).

Bah, j'aime bien trancher les choses. J'aimerai beaucoup qu'un tribunal tranche le point que je soulève. On le remplit déjà "pour moi" (pas vraiment pour moi, car même si j'y assistais, la procédure veut que ça soit le chef qui remplisse) et je signe sans relire.

Contester un entretien pro devant un tribunal c'est compliqué. Pognon et temps de dingue pour un résultat environ nul. Car les petites phrases seront interprétées dans un sens comme dans l'autre (jusque-là, c'est l'un des buts d'une justice impartiale) pour leur faire dire ce qu'on veut bien leur faire dire, et surtout dans le sens de la doxa (c'est là que je remets en question l'impartialité de la justice au motif qu'elle baigne dans son époque, dans les pensées de son époque). Vu mon langage et d'autres paramètres, c'est juste mort.
Et puis ton chef écrit ce qu'il a envie d'écrire. Oui, tu peux écrire des réserves (qui ne donnent pas lieu à contestation du chef), mais « la raison du plus fort est toujours la meilleure » (big up Jean), et, dans notre monde, et dans ce contexte, le plus fort c'est le chef. On le paye pour qu'il fasse autorité. Donner raison à un sous-fifre, c'est aller contre ça, c'est destituer le chef, donc ça n'arrivera pas.
Et c'est tellement facile de virer un CDD : il suffit de ne pas renouveler son contrat… Va prouver que y'a un lien avec le refus répété d'entretien pro (ou autre sujet, hein)…
Pour parer d'éventuelles sanctions pour refus d'entretien pro (ou autre), je préfère miser sur le fait que je suis ingénieur en informatique, donc que je retrouverai un emploi sans problème (c'est déjà du vécu). Et surtout, le privé me payait 495 € net/mois de plus que le public, donc, vu la faible probabilité d'être titularisé un jour dans mon organisation actuelle, j'ai tout intérêt à repartir dans le privé après avoir acquis des années dans le public, années qui augmentent l'écart entre ma rémunération actuelle et la future.

Je suis un contractuel de la fonction publique d'État depuis plusieurs années. J'ai donc un CDD. Après le CDD initial, mon employeur m'a toujours proposé des CDD de deux ans. J'ai toujours refusé, préférant cumuler des CDD d'un an. Pourquoi ? Pour éviter une perte de rémunération.

En fonction de ta date d'embauche, tu vas te faire carotter une partie de ta rémunération. La grille des contractuels de la catégorie A prévoit une hausse de l'indice après 1 an d'ancienneté (+ 4 points), après 3 ans (+ 8 points), après 6 ans (+ 10 points), et tous les 3 ans au-delà de 6 ans (+ 14 points). Si les contrats de ton administration vont du 01/09 d'une année (N) au 31/08 de l'année suivante (N+1) et que t'arrives en novembre N, ton premier contrat ira de novembre N au 31/08/N+1 (c'est donc un CDD de dix mois, pas d'un an, conçu pour t'aligner sur le cycle normal). Si tu choisis de le prolonger avec un contrat d'un an, ce dernier ira du 01/09/N+1 au 31/08/N+2.

Tu auras un an d'ancienneté en novembre N+1, mais, comme t'auras signé ton nouveau contrat (pour 01/09/N+1-31/08/N+2) en juin/juillet N+1, tu auras ton augmentation à partir de septembre N+2 (en supposant que t'es re-signé en juin N+2). On te carottera donc de novembre N+1 à août N+2 (10 mois). Si tu choisis un contrat de 2 ans en juin N+1, on te carottera de novembre N+1 à août N+3 (22 mois) ! Le service RH ne va pas s'embêter à te faire un avenant en novembre N+1 pour 4 points, qu'est-ce que tu crois ! Sauf que 4 points, c'est 15 € net/mois en cette saison. La perte de rémunération s'élève donc à 150 € net sur un contrat d'un an et à 330 € net sur un contrat de deux ans. Je te laisse faire les calculs pour les autres étapes de l'ancienneté. Oui, ça pique bien plus, un de mes collègues a "testé pour nous" (comme on dit). Bien sûr, un rappel de rémunération est possible, mais il faut penser à le demander (bah non, c'pas automatique, qu'est-ce que tu crois !).

Bref, un contrat annuel force un nouvel examen de ton dossier par le service RH. Oui, ça lui fait du boulot en plus mais j'estime que ce n'est pas à moi de leur courir après pour réclamer un avenant ou un rappel de rémunération !

Au début, j'avais un deuxième argument, mais il est basé sur une erreur. Je pensais que, comme dans le privé, il n'était pas possible de démissionner d'un CDD. Ni de signer une rupture conventionnelle. N'étant pas sûr d'avoir trouvé l'emploi qui me conviendrait, je me voyais mal m'engager sur 2 ans après mon CDD initial. En vrai, on peut démissionner d'un CDD de la fonction publique (c'est hallucinant… le CDD privé est précaire, donc on empêche la démission et le licenciement classique, mais pas dans le CDD public, deux poids, deux mesures…), donc cet argument est caduc.

Mais il n'est pas déplaisant de faire le point tous les ans sur sa situation professionnelle, ses envies, tout ça. Ça donne une mesure du temps qui passe pendant que tu ne bouges pas.