Depuis plusieurs mois, j'utilise quelques extensions Firefox supplémentaires par rapport à mon tas d'extensions :

• Redirect AMP to HTML : utiliser la version normale, pas AMP, d'une page web. AMP est une technologie d'optimisation pas vraiment normalisée pondue par Google. Construire des pages web selon la manière de faire de Google, avec du JavaScript de Google et les héberger, en option, chez Google = non merci ;
  
  
• I don't care about cookies : faire disparaître les demandes de stockage de cookies. Quand on les refuse ou qu'on les supprime à chaque fermeture du navigateur, ces demandes incessantes sont insupportables. Bonus : cette extension valide automatique les pop-up « Avant de continuer » sur Google Search ;
  
  
• Never-Consent : refuser le dépôt de cookies et le flicage auprès de quelques (trop rares) plateformes de gestion du consentement (CMP) genre Cookie Law Info / Quantcast / SirData (aka consentframework.com) utilisées par les sites web pour mutualiser la collecte du consentement ;
  
  
• First Party Isolation. First Party Isolation est une préfèrence de Firefox (que l'on peut donc activer dans about:config) importée du Tor Browser qui limite l'accès aux cookies, au cache, au stockage, etc. par domaine. Ainsi, le flicage inter-domaines par un même prestataire présent sur plusieurs sites web n'est plus possible. La fonctionnalité Total Cookie Protection de Firefox 86 est une amélioration de cela. Pourquoi une extension ? FPI casse certains mécanismes d'authentification centralisée (genre compte Google ou Facebook). De mon côté, cela casse NextInpact (car certains cookies sont en dehors du domaine visité) et le stockage de mes préférences sur Qwant (je ne comprends pas pourquoi). Donc avoir une extension pour activer / désactiver FPI à la demande, c'est très pratique. ÉDIT DU 23/04/2022 : il n'y a plus de problème sur NextInpact depuis quelques mois. FIN DE L'ÉDIT ;
  
  
• Cookie Autodelete : supprimer les cookies (ainsi que le cache, le stockage persistant, etc. en option) X secondes après avoir quitté un site web (en cliquant sur un lien ou en fermant un onglet) sauf pour ceux en liste blanche. Cette extension permet un nettoyage plus régulier que celui que l'on peut demander à la fermeture du navigateur web. Je l'ai installé après avoir constaté que le refus des cookies (sauf pour quelques domaines genre ma banque ou mes journaux) casse des sites web et que uMatrix, configuré pour tej les cookies (sauf liste blanche), en laisse passer.

Je recommande l'utilisation de ces extensions. Les trois premières peuvent être installées chez des novices car elles m'ont posé aucun problème.

Si tu me lis, tu sais que les certificats x509 ont plusieurs failles conceptuelles. La plus grande est que n'importe quelle autorité de certification (Let's Encrypt, DigiCert, etc.) reconnue par un logiciel peut signer / légitimer un certificat x509 pour n'importe quel nom Internet. Exemple : impots.gouv.fr achète ses certificats x509 auprès de la société commerciale Certigna. Pourtant, rien empêche Let's Encrypt de signer un certificat valide pour impots.gouv.fr (en réalité, il y a quelques mécanismes timides : DNS CAA, DANE TLSA, Certificate Transparency, etc.).

Ces """"faux"""" certificats peuvent être utilisés pour créer un faux site web impots.gouv.fr ou pour intercepter les communications entre un citoyen et impots.gouv.fr.

Or, quand on regarde les autorités de certification qui sont enregistrées dans le catalogue de certificats d'autorité d'un navigateur web, il y a de quoi s'interroger :

• China Financial Certification Autority, E-Tugra Certification Autority (Turquie), Hongkong Post, gouvernements de Taiwan, de Pologne, des Pays-Bas, Chambers of Commerce, Autoridad de Certificacion Firmaprofesional, etc. ;
  
  
• Atos TrustedRoot, Sonera Class 2, Google, etc.

Je ne conteste pas l'utilité de toutes ces autorités… pour les citoyens et les professionnels concernés. Mais, je ne suis pas concerné par tout ça : je ne consulte pas ces sites web-là, je ne suis pas citoyen de ces États-là, etc. TeliaSonera est un important transitaire Internet. Il est donc en bonne position pour intercepter des communications. Google est hégémonique. Je ne consulte pas de sites web Atos. Etc. Malgré ça, ces autorités peuvent émettre des certificats pour les sites web que je visite. C'est là tout le problème.

On peut donc retirer les autorités de certification que l'on n'utilise pas pour un gain variable en sécurité. Environ nul pour un ordinateur qui reste à domicile. Intéressant pour un ordinateur personnel qui utilise des points d'accès Wi-Fi gratuits ou pour un ordinateur professionnel qui se déplace chez les clients (et leurs équipements d'interception du trafic TLS) ou pour un séjour dans des pays autoritaires (et leurs équipements d'interception du trafic TLS).

Listes

En 2019, Aeris a publié sa liste des autorités de certification x509 qui lui suffisent pour aller sur les sites web qu'il veut. Comme elle n'est plus disponible, je la recopie ici :

COMODO ECC Certification Authority
Certplus Class 2 Primary CA
Certinomis - Root CA
Baltimore CyberTrust Root
Amazon Root CA 1
DigiCert Global Root CA
DigiCert Assured ID Root CA
DCertigna
Deutsche Telekom Root CA 2
COMODO RSA Certification Authority
Entrust Root Certification Authority - G2
DST Root CA X3
DigiCert Global Root G2
DigiCert High Assurance EV Root CA
GlobalSign Root CA
GlobalSign Root CA - R3
GeoTrust Primary Certification Authority - G2
GeoTrust Global CA
Go Daddy Root Certificate Authority - G2
Izenpe.com
QuoVadis Root CA 2
QuoVadis Root CA 2 G3
Starfield Root Certificate Authority - G2
SSL.com Root Certification Authority ECC
SSL.com Root Certification Authority RSA
T-TeleSec GlobalRoot Class 2
USERTrust RSA Certification Authority
USERTrust ECC Certification Authority
Certum Trusted Network CA

Depuis sept mois, j'utilise la liste réduite suivante :

Actalis Authentication Root CA
Baltimore CyberTrust Root
Buypass Class 2 Root CA
Comodo RSA Certification Authority
Comodo ECC Certification Authority
Dhimyotis Certigna
Digicert Global Root CA
Digicert Global Root G2
Digicert Global Root G3
Digicert Assured ID Root CA
Digicert High Assurance EV Root CA
Entrust Root Certification Authority - G2
Entrust Root Certification Authority - EC1
GlobalSign Root CA
GlobalSign Root CA - R2
GlobalSign Root CA - R3
Go Daddy Root Certificate Authority - G2
HARICA TLS RSA Root CA 2021
HARICA TLS ECC Root CA 2021
ISRG Root X1
QuoVadis Root CA 2 G3
Starfield Services Root Certificate Authority - G2
Starfield Root Certificate Authority - G2
UserTrust ECC Certification Authority
UserTrust RSA Certification Authority

ÉDIT DU 21/08/2021 : ajout de QuoVadis Root CA 2 G3. FIN DE L'ÉDIT.

ÉDIT DU 28/09/2022 : ajout de Entrust Root Certification Authority - EC1. FIN DE L'ÉDIT.

ÉDIT DU 22/01/2024 : DST Root CA n'est plus empaqueté, donc je le retire de la liste + j'ai ajouté Digicert Global Root G3. FIN DE L'ÉDIT.

ÉDIT DU 27/06/2025 : ajout de Digicert High Assurance EV Root CA. FIN DE L'ÉDIT.

MODIF du 08/01/2026 : ajout de HARICA TLS RSA Root CA 2021 et HARICA TLS ECC Root CA 2021. FIN DE MODIF.

MODIF du 24/07/2026 : ajout de Actalis Authentication Root CA. FIN DE MODIF.

Comment expliquer la différence entre ma liste et celle d'Aeris ? J'ai un usage très routinier du web. Je consulte peu de nouveaux sites web.

Comment je fais pour virer les autorités inutiles à mon usage ?

Dans Firefox : menu « Édition », « Préférences », « Vie privée et sécurité », « Afficher les certificats » (tout en bas), onglet « Autorités ». Je clique sur chaque certificat d'autorité puis sur « Modifier la confiance… » puis je décoche la case « Ce certificat peut identifier des sites web » puis « OK ».

De mémoire, il est vain de supprimer les certificats d'autorité car ils reviennent automatiquement.

Aeris retire sa confiance envers les autorités de certification en utilisant la commande certutil :

• Lister les certificats d'autorités : certutil -d ~/.mozilla/firefox/XXXXXXXX.default/ -L ;
  
  
• Retirer sa confiance à un certificat : certutil -d ~/.mozilla/firefox/XXXXXXXX.default/ -M -n '<NOM_CERTIFICAT' -t ',,'

Avantage de la ligne de commande : scriptable / automatisable.

Inconvénients de la ligne de commande :

• Le nom du certificat n'est pas le même que celui qui s'affiche dans le message d'erreur "certificat manquant" de Firefox, donc établir la correspondance est plus compliqué ;
  
  
• Firefox et certutil ne renvoient pas la même information en ce qui concerne la confiance accordée à un certificat (confiance accordée d'un côté, refusée de l'autre). Incohérence entre les deux outils que je n'explique pas.

Et les autres logiciels ?!

Dans Thunderbird, je retire toutes les autorités de certification sauf celles qui signent les certificats des serveurs emails que j'utilise. En clair, j'ai deux autorités au lieu de plusieurs dizaines. ÉDIT DU 24/09/2022 : il faut être plus prudent si 1) tu affiches tes emails en HTML ; 2) tu utilises OpenPGP (chiffrement des emails) car la recherche de clés utilise le protocole VKS qui est transporté chiffré au-dessus de TLS, donc il faut laisser actif le certificat x509 racine de celui du serveur de clés keys.openpgp.org, c'est-à-dire « ISRG Root X1 » (Let's Encrypt). FIN DE L'ÉDIT.

Il faudrait aussi nettoyer /etc/ssl/certs et les autres catalogues de certificats (celui utilisé par les applications Java, par exemple). Ça ne me semble pas être prioritaire : en dehors de Firefox / Thunderbird, peu de mes logiciels communiquent avec l'extérieur ou alors pour effectuer des tests (cas de wget, curl, openssl s_client, etc.).

TL;DR :

• « ca md too weak » : le certificat x509 utilisé est signé avec un algorithme cryptographique déprécié dans /etc/ssl/openssl.cnf (à la fin) ;
  
  
• « Packet size=XXXXXX too big » : rupture de compatibilité entre deux composants de Bacula car l'un est à jour alors que l'autre ne l'est pas.

L'un de nos prestataires met à jour, vers Debian 10, un serveur placé sous sa totale responsabilité. C'est notre premier serveur Debian 10. Depuis ce moment-là, nos sauvegardes Bacula de ce serveur ne se font plus.

Les journaux du directeur Bacula indiquent :

<CENSURE>-dir JobId XXXX: Warning: bsock.c:107 Could not connect to Client: <CENSURE>-fd on <CENSURE>:9102. ERR=Connection refused
<CENSURE>-dir JobId XXXX: Fatal error: bsock.c:113 Unable to connect to Client: <CENSURE>-fd on <CENSURE>:9102. ERR=Connection refused

Sur la machine à sauvegarder Debian 10, le file daemon de Bacula n'est pas démarré. Une erreur empêche de le démarrer :

<CENSURE>-fd: openssl.c:68 Error loading certificate file: ERR=error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak

OpenSSL = implémentation de TLS. « md » = message digest = fonction de condensation / hachage. Nous utilisons une autorité de certification x509 interne / privée / maison. Avant signature, les certificats émis / clients sont signés avec SHA-1. Cette fonction cryptographique est très fortement dépréciée car elle n'offre plus un niveau de sécurité acceptable. C'est l'un des changements entre Debian 9 Stretch et Debian 10 Buster.

Pour autoriser l'utilisation de SHA-1, il suffit de mettre en commentaire la ligne CipherString = DEFAULT@SECLEVEL=2 du fichier /etc/ssl/openssl.cnf. La solution durable sera de remplacer notre autorité de certification x509 maison par une nouvelle utilisant des algorithmes de signature plus récents.

Désormais, le file daemon de Bacula démarre. bconsole depuis le director fonctionne. Tout va bien. Enfin, on le croit…

La nuit suivant la réparation sus-rapportée, la sauvegarde de ce serveur Debian 10 ne se fait toujours pas. Le journal du directeur Bacula consigne :

<CENSURE>-sd JobId XXXX: Fatal error: bsock.c:569 Packet size=XXXXXX too big from "client:<CENSURE>:9103. Terminating connection.
<CENSURE>-sd JobId XXXX: Fatal error: Error creating JobMedia records: 1000 OK VolName=Inc-2881 VolJobs=1 VolFiles=0 VolBlocks=3 VolBytes=193738 VolABytes=0 VolHoleBytes=0 VolHoles=0 VolMounts=35 VolErrors=0 VolWrites=289795 MaxVolBytes=0 VolCapacityBytes=0 VolStatus=Used Slot=0 MaxVolJobs=1 MaxVolFiles=0 InChanger=0 VolReadTime=0 VolWriteTime=320926443 EndFile=1 EndBlock=3432546605 VolType=1 LabelType=0 MediaId=2881 ScratchPoolId=0
<CENSURE>-dir JobId XXXX: Error: getmsg.c:185 Malformed message: Jmsg JobId=XXXX type=4 level=1611790411 <CENSURE>-fd JobId XXXX: Error: bsock.c:388 Wrote 2134 bytes to Storage daemon:<CENSURE>:9103, but only 0 accepted.
<CENSURE>-dir JobId XXXX: Error: getmsg.c:185 Malformed message: Jmsg JobId=XXXX type=3 level=1611790411 <CENSURE>-fd JobId XXXX: Fatal error: backup.c:843 Network send error to SD. ERR=Connection reset by peer
<CENSURE>-dir JobId XXXX: Error: getmsg.c:185 Malformed message: Jmsg JobId=XXXX type=4 level=1611790411 <CENSURE>-fd JobId XXXX: Error: bsock.c:271 Socket has errors=1 on call to Storage daemon:<CENSURE>:9103
<CENSURE>-dir JobId XXXX: Fatal error: bsock.c:569 Packet size=XXXXXX too big from "Client: <CENSURE>-fd:<CENSURE>:9102. Terminating connection.
<CENSURE>-dir JobId XXXX: Fatal error: No Job status returned from FD.

Hum… Problème de communication entre la machine à sauvegarder et le serveur de stockage Bacula (storage daemon).

J'avoue, j'ai cru à une erreur TLS (genre version minimale de TLS imposée par Debian 10 = TLS 1.2 alors que le storage daemon ne sait pas parler cette version). Mais j'ai la même erreur sur une machine virtuelle Debian 10 montée à l'arrache dans laquelle je configure Bacula pour ne pas utiliser TLS.

Une recherche sur le web donne un diagnostic convergeant : Bacula Packet size too big | deranfangvomen.de, Bacula - Users - Packet size too big from client, Bacula Frequently Asked Questions.

Un démon de stockage en version 5.X (Debian 8) est incompatible avec un file daemon en version 9.X (Debian 10).

Solution à court terme : downgrader les paquets Bacula sur la machine Debian 10. Pour ce faire, il faut ajouter les dépôts Stretch dans /etc/apt/sources.list (ne pas oublier le dépôt security), apt-get upate, apt-get install bacula-fd=7.4.4+dfsg-6+deb9u2 bacula-common=7.4.4+dfsg-6+deb9u2.

Solution à long terme : installer une deuxième architecture Bacula pour nos machines >= Debian 10. L'infra actuelle continuera de s'occuper de nos serveurs < Debian 10…