DON'T PANIC.
(Je suis en train de lire "The hitch-hiker's guide to the galaxy" de Douglas Adams, livre que j'ai rapporté de mon séjour à Londres le weekend dernier ; je me régale.)
Le sujet de ce post reprend une communication qui m'a valu de vives réactions pour certaines très sympathiques. Ce commentaire était mal formulé, il fallait lire "La mise à jour automatique des certificats LE est /potentiellement/ un cheval de Troie".
Alors non, les certificats LE ne sont pas dangereux, évidemment !
Je m'en suis d'ailleurs beaucoup servi dès que c'était disponible ou presque (début 2017) mais uniquement sur des blogs WordPress installés tout seuls sur des VPS, c'est à dire pour des informations publiques sans données sensibles et dans un contexte sans importance. De toute façon les mises à jour automatiques de WordPress sont à peine moins fiables :-) Hé, pas taper si vous n'êtes pas d'accord !
A lire mes notes, la mise en œuvre des certificats LE était effectivement super simple sauf qu'il y avait dans le crontab :
32 6 * * 0 /root/certbot-auto renew -q
Apparemment, il n'est plus nécessaire de renouveler le certificat avec root (et peut-être est-ce que cela a toujours été le cas) quoique sinon je ne vois pas comment concilier ça avec la gestion d'un serveur web qui appartiennent à root. Oui, je sais qu'il serait possible de configurer un serveur apache hors root mais ce n'est pas standard, notamment parce que seul root peut accéder aux ports 80 ou 443.
Quoiqu'il en soit, avoir un script obscur qui revoit potentiellement la configuration de mon serveur toutes les semaines, cela ne me plait pas. Je n'ai pas cherché plus loin et j'ai profité des certificats LE pour des contextes sans conséquences. Ce qui ne veut pas dire que l'on ne peut pas utiliser les certificats LE pour des cas autres que ceux où il n'y a pas d'enjeu…
J'ai aussi une préférence et une grande confiance a priori dans les produits du logiciel libre (mais pas parce qu'ils sont "revus"). Je les utilise évidemment le plus possible mais j'ai suffisamment d'expérience en développement logiciel (à peu près 40 ans…) pour savoir à quel point il est plus facile de produire du code malveillant que des traitements fiables et robustes y compris pour les cas limites.
Donc pour le cas de l'alternative entre un certificat d'une dizaine d'euros annuel et l'hébergement d'un processus hebdomadaire et /potentiellement/ faillible, personnellement, le choix est vite fait. D'autant que je n'ai qu'une petite poignée de certificat SSL à gérer. Oui, cela change tout.
Pour ce qui est de chiffrer les échanges avec un serveur web, tous les certificats se valent qu'ils soient auto-signés, wildcards, gratuits ou payants, même très chers. A la base, une clé publique c'est juste le produit de deux nombres premiers si grands que sa factorisation prendrait a priori un temps infini par rapport aux calculs modulo n dans un corps Z/nZ avec n premier qui sont faits pour chiffrer et déchiffrer les échanges… d'une clé symétrique qui sera exploité ensuite. Le recours aux clés asymétriques a simplement déplacé le problème : au lieu d'avoir à assurer le partage confidentiel d'une clé symétrique, il faut s'assurer qu'une clé publique appartient bien à celui qui prétend en être le propriétaire. C'est là où les CA interviennent et l'opportunité d'en faire un racket. Racket soutenu par l'obligation artificielle de tout chiffrer. Pour cela la disponibilité des certificats LE est effectivement une bénédiction !
Car non, en vrai cela ne sert à rien de chiffrer une recette d'Irish coffe partagée sur un blog, à part pour lui éviter d'être totalement ostracisée par ggl. Quant à chiffrer une librairie JS publique, je n'y avais jamais pensé mais je n'en vois pas non plus l'intérêt, d'autant moins que sous couvert de minimisation (mais en vrai pour les protéger d'une réutilisation) la plupart des librairies JS sont quasiment illisibles :-) Par contre conforter l'origine d'une librairie externe par la validation d’authenticité d'un CA est effectivement intéressant mais ce n'est pas le certificat du site qui l'utilise qui le fait.
Ah et sinon, pour répondre à la remarque du petit jeune qui m'a gentiment dit d'arrêter de raconter n'importe quoi sur des sujets que je ne connais manifestement pas, je dirais qu'il a au moins à moitié tort. L'expérience a ceci de particulier qu'il ne me rattrapera jamais pour ce qui est de la durée sur laquelle je l'ai accumulée ; je serai certainement mort avant :-))
Bon, désolé, mais il y a beaucoup de choses qui me posent problème, et que je ne souhaite pas laisser sans réponse pour les éventuels lecteurs qui ne seraient pas forcément à l'aise avec le sujet ou habitués à celui-ci.
Laurent Barme 2551@barme.fr wrote on 19/03/2024 at 20:34:20+0100:
A lire mes notes, la mise en œuvre des certificats LE était effectivement super simple sauf qu'il y avait dans le crontab :
32 6 * * 0 /root/certbot-auto renew -q
Apparemment, il n'est plus nécessaire de renouveler le certificat avec root (et peut-être est-ce que cela a toujours été le cas) quoique sinon je ne vois pas comment concilier ça avec la gestion d'un serveur web qui appartiennent à root.
Tu peux donner le droit de reload ton serveur web à un utilisateur non privilégié (merci sudoers). certbot marche très bien sans droit root mais doit pouvoir travailler dans les dossiers dont il dépend (par défaut /etc/letsencrypt, /var/log/lestencrypt et /var/lib/letsencrypt).
Tes workers sur un serveur web ne tournent jamais en tant que root, seul le master process le fait. Et donc il peut reloader des certifs SSL qui n'appartiennent pas à root. Par ailleurs même sans ça, c'est une question d'ACLs UNIX, et tu pourrais donner un droit de lecture sur tes certifs SSL à www-data.
Oui, je sais qu'il serait possible de configurer un serveur apache hors root mais ce n'est pas standard, notamment parce que seul root peut accéder aux ports 80 ou 443.
Cela semble hors sujet (et un redirect du port 80/443 via un firewall trivial, mais idem, hors sujet, pas nécessaire).
Quoiqu'il en soit, avoir un script obscur qui revoit potentiellement la configuration de mon serveur toutes les semaines, cela ne me plait pas.
"qui revoit" ? Que veux-tu dire ?
Je n'ai pas cherché plus loin
Et c'est bien le problème : tu as émis un avis très définitif sans avoir cherché plus loin.
et j'ai profité des certificats LE pour des contextes sans conséquences. Ce qui ne veut pas dire que l'on ne peut pas utiliser les certificats LE pour des cas autres que ceux où il n'y a pas d'enjeu…
Du coup pour ceux que ça intéresse, c'est tout à fait faisable d'utiliser du LE automatisé en prod sans compromettre sa sécurité numérique.
Et si vraiment ça vous tracasse, un reverse proxy pour servir du SSL c'est pas la mer à boire, et ça ôte bien des soucis.
Pour ce qui est de chiffrer les échanges avec un serveur web, tous les certificats se valent qu'ils soient auto-signés, wildcards, gratuits ou payants, même très chers. A la base, une clé publique c'est juste le produit de deux nombres premiers si grands que sa factorisation prendrait a priori un temps infini par rapport aux calculs modulo n dans un corps Z/nZ avec n premier
Déjà tu ne décris que RSA, il existe quand même pléthore d'algos crypto asym largement utilisés dont des moins consommateurs en ressources.
Ensuite, ce que tu décris de l'algo RSA et des maths derrière est faux¹.
qui sont faits pour chiffrer et déchiffrer les échanges… d'une clé symétrique qui sera exploité ensuite.
En effet, dans un échange SSL/TLS on crée une clef symétrique, mais la clef n'est jamais échangée dans un algo moderne². Elle est déduite, et c'est vital car ça préserve les échanges d'un replay si les clefs asym sont cassées/divulguées.
Le recours aux clés asymétriques a simplement déplacé le problème : au lieu d'avoir à assurer le partage confidentiel d'une clé symétrique, il faut s'assurer qu'une clé publique appartient bien à celui qui prétend en être le propriétaire. C'est là où les CA interviennent et l'opportunité d'en faire un racket. Racket soutenu par l'obligation artificielle de tout chiffrer. Pour cela la disponibilité des certificats LE est effectivement une bénédiction !
Car non, en vrai cela ne sert à rien de chiffrer une recette d'Irish coffe partagée sur un blog, à part pour lui éviter d'être totalement ostracisée par ggl.
La confidentialité, fortement connecté au respect de l'intimité et de la vie privée me semblent être un bon argument pour, si. De même, cela évite qu'un malandrin fasse du MITM et te fasse faire un Irish Coffee avec du méthanol.
Quant à chiffrer une librairie JS publique, je n'y avais jamais pensé mais je n'en vois pas non plus l'intérêt, d'autant moins que sous couvert de minimisation (mais en vrai pour les protéger d'une réutilisation) la plupart des librairies JS sont quasiment illisibles :-)
On se fiche de leur lisibilité, le but c'est d'éviter du MITM et une potentielle altération de ladite bibliothèque à toute fin malveillante. Le chiffrement c'est autant la confidentialité que l'authenticité que l'intégrité en fait.
Par contre conforter l'origine d'une librairie externe par la validation d’authenticité d'un CA est effectivement intéressant mais ce n'est pas le certificat du site qui l'utilise qui le fait.
Non, mais sans le certificat du site qui l'utilise tu ne peux pas valider l'authenticité du contenu de la page que tu affiches, et donc tu ne sais pas quelles libs tu vas te faire refiler.
Ah et sinon, pour répondre à la remarque du petit jeune
Aux âmes bien nées…
qui m'a gentiment dit d'arrêter de raconter n'importe quoi sur des sujets que je ne connais manifestement pas, je dirais qu'il a au moins à moitié tort. L'expérience a ceci de particulier qu'il ne me rattrapera jamais pour ce qui est de la durée sur laquelle je l'ai accumulée
C'est sans rapport avec le fait de ne pas raconter d'âneries sur un sujet qu'on ne maîtrise pas, et ton courriel renforce cette impression que tu ne maîtrises effectivement pas le sujet.
Par ailleurs, on peut avoir accumulé 40 ans d'expérience en culture des betteraves, ça ne fait pas de soi un expert en lancement de fusées.
On peut même acquérir 40 ans d'expérience en ingénierie systèmes, si celle-ci est faite de convictions erronnées, de raisonnements hâtifs, et d'un certain manque de curiosité, elle ne vaudra /in fine/ pas nécessairement plus que 15 ans bien investis dans le même domaine.
Tout est souvent une question de curiosité, un des plus grands moteurs de l'espèce humaine.
; je serai certainement mort avant :-))
Il n'est jamais interdit de changer d'approche jusqu'au dernier jour.
o/
Hello,
Juste mes 2 centimes pour ajouter à la discussion qu'il n'est pas nécessaire d'être root pour faire tourner un serveur sur les ports privilégiés. La capability CAP_NET_BIND_SERVICE suffit, et peut généralement être attribuée à l'aide de setcap. Ça fonctionne depuis Linux 2.quelquechose (la flemme d'aller retrouver la version exacte à cette heure).
Certaines des capabilities existantes permettent clairement à un processus d'obtenir facilement un root complet, je pense notamment à la tristement célèbre CAP_SYS_ADMIN ou à la triviale CAP_SETUID, mais ça, ça mériterait une discussion à part entière.
William
Le mercredi 20 mars 2024 à 01:37, Pierre-Elliott Bécue becue@crans.org a écrit :
Bon, désolé, mais il y a beaucoup de choses qui me posent problème, et que je ne souhaite pas laisser sans réponse pour les éventuels lecteurs qui ne seraient pas forcément à l'aise avec le sujet ou habitués à celui-ci. Laurent Barme 2551@barme.fr wrote on 19/03/2024 at 20:34:20+0100:
A lire mes notes, la mise en œuvre des certificats LE était effectivement super simple sauf qu'il y avait dans le crontab : 32 6 * * 0 /root/certbot-auto renew -q Apparemment, il n'est plus nécessaire de renouveler le certificat avec root (et peut-être est-ce que cela a toujours été le cas) quoique sinon je ne vois pas comment concilier ça avec la gestion d'un serveur web qui appartiennent à root.
Tu peux donner le droit de reload ton serveur web à un utilisateur non privilégié (merci sudoers). certbot marche très bien sans droit root mais doit pouvoir travailler dans les dossiers dont il dépend (par défaut /etc/letsencrypt, /var/log/lestencrypt et /var/lib/letsencrypt). Tes workers sur un serveur web ne tournent jamais en tant que root, seul le master process le fait. Et donc il peut reloader des certifs SSL qui n'appartiennent pas à root. Par ailleurs même sans ça, c'est une question d'ACLs UNIX, et tu pourrais donner un droit de lecture sur tes certifs SSL à www-data.
Oui, je sais qu'il serait possible de configurer un serveur apache hors root mais ce n'est pas standard, notamment parce que seul root peut accéder aux ports 80 ou 443.
Cela semble hors sujet (et un redirect du port 80/443 via un firewall trivial, mais idem, hors sujet, pas nécessaire).
Quoiqu'il en soit, avoir un script obscur qui revoit potentiellement la configuration de mon serveur toutes les semaines, cela ne me plait pas.
"qui revoit" ? Que veux-tu dire ?
Je n'ai pas cherché plus loin
Et c'est bien le problème : tu as émis un avis très définitif sans avoir cherché plus loin.
et j'ai profité des certificats LE pour des contextes sans conséquences. Ce qui ne veut pas dire que l'on ne peut pas utiliser les certificats LE pour des cas autres que ceux où il n'y a pas d'enjeu…
Du coup pour ceux que ça intéresse, c'est tout à fait faisable d'utiliser du LE automatisé en prod sans compromettre sa sécurité numérique. Et si vraiment ça vous tracasse, un reverse proxy pour servir du SSL c'est pas la mer à boire, et ça ôte bien des soucis.
Pour ce qui est de chiffrer les échanges avec un serveur web, tous les certificats se valent qu'ils soient auto-signés, wildcards, gratuits ou payants, même très chers. A la base, une clé publique c'est juste le produit de deux nombres premiers si grands que sa factorisation prendrait a priori un temps infini par rapport aux calculs modulo n dans un corps Z/nZ avec n premier
Déjà tu ne décris que RSA, il existe quand même pléthore d'algos crypto asym largement utilisés dont des moins consommateurs en ressources. Ensuite, ce que tu décris de l'algo RSA et des maths derrière est faux¹.
qui sont faits pour chiffrer et déchiffrer les échanges… d'une clé symétrique qui sera exploité ensuite.
En effet, dans un échange SSL/TLS on crée une clef symétrique, mais la clef n'est jamais échangée dans un algo moderne². Elle est déduite, et c'est vital car ça préserve les échanges d'un replay si les clefs asym sont cassées/divulguées.
Le recours aux clés asymétriques a simplement déplacé le problème : au lieu d'avoir à assurer le partage confidentiel d'une clé symétrique, il faut s'assurer qu'une clé publique appartient bien à celui qui prétend en être le propriétaire. C'est là où les CA interviennent et l'opportunité d'en faire un racket. Racket soutenu par l'obligation artificielle de tout chiffrer. Pour cela la disponibilité des certificats LE est effectivement une bénédiction ! Car non, en vrai cela ne sert à rien de chiffrer une recette d'Irish coffe partagée sur un blog, à part pour lui éviter d'être totalement ostracisée par ggl.
La confidentialité, fortement connecté au respect de l'intimité et de la vie privée me semblent être un bon argument pour, si. De même, cela évite qu'un malandrin fasse du MITM et te fasse faire un Irish Coffee avec du méthanol.
Quant à chiffrer une librairie JS publique, je n'y avais jamais pensé mais je n'en vois pas non plus l'intérêt, d'autant moins que sous couvert de minimisation (mais en vrai pour les protéger d'une réutilisation) la plupart des librairies JS sont quasiment illisibles :-)
On se fiche de leur lisibilité, le but c'est d'éviter du MITM et une potentielle altération de ladite bibliothèque à toute fin malveillante. Le chiffrement c'est autant la confidentialité que l'authenticité que l'intégrité en fait.
Par contre conforter l'origine d'une librairie externe par la validation d’authenticité d'un CA est effectivement intéressant mais ce n'est pas le certificat du site qui l'utilise qui le fait.
Non, mais sans le certificat du site qui l'utilise tu ne peux pas valider l'authenticité du contenu de la page que tu affiches, et donc tu ne sais pas quelles libs tu vas te faire refiler.
Ah et sinon, pour répondre à la remarque du petit jeune
Aux âmes bien nées…
qui m'a gentiment dit d'arrêter de raconter n'importe quoi sur des sujets que je ne connais manifestement pas, je dirais qu'il a au moins à moitié tort. L'expérience a ceci de particulier qu'il ne me rattrapera jamais pour ce qui est de la durée sur laquelle je l'ai accumulée
C'est sans rapport avec le fait de ne pas raconter d'âneries sur un sujet qu'on ne maîtrise pas, et ton courriel renforce cette impression que tu ne maîtrises effectivement pas le sujet. Par ailleurs, on peut avoir accumulé 40 ans d'expérience en culture des betteraves, ça ne fait pas de soi un expert en lancement de fusées. On peut même acquérir 40 ans d'expérience en ingénierie systèmes, si celle-ci est faite de convictions erronnées, de raisonnements hâtifs, et d'un certain manque de curiosité, elle ne vaudra /in fine/ pas nécessairement plus que 15 ans bien investis dans le même domaine. Tout est souvent une question de curiosité, un des plus grands moteurs de l'espèce humaine.
; je serai certainement mort avant :-))
Il n'est jamais interdit de changer d'approche jusqu'au dernier jour. o/ -- PEB ¹ La clef publique c'est la donnée d'un couple (m, e) où m=pq, avec p, q premiers très grands et de n'importe quel nombre e premier avec φ(m)=(p-1)(q-1). La clef privée, elle, est la donnée du couple (m, d) avec d l'inverse de e dans ℤ/φ(m)ℤ. Par ailleurs, les calculs de chiffrement et déchiffrement ne se font pas dans Z/nZ avec n premier (puisque comme vu au dessus, on part d'un *produit* de nombres premiers), mais dans ℤ/pqℤ avec p et q premiers. ² PFS, eg Diffie-Hellman _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
J'ai failli écrire une réponse similaire moi même. mais puisque elle est faite,
+1 à toutes les remarques de Pierre-Eliott.
et +1000 à "Et c'est bien le problème : tu as émis un avis très définitif sans avoir cherché plus loin."
Après tout certbot, ça n'est que quelques centaines de Ko de python open source.
Et sans être un crac en python, je peux quand même dire que c'est relativement lisible.
Rien à voir avec du JS minifié.
Le 20/03/2024 à 01:37, Pierre-Elliott Bécue a écrit :
Bon, désolé, mais il y a beaucoup de choses qui me posent problème, et que je ne souhaite pas laisser sans réponse pour les éventuels lecteurs qui ne seraient pas forcément à l'aise avec le sujet ou habitués à celui-ci.
Laurent Barme 2551@barme.fr wrote on 19/03/2024 at 20:34:20+0100:
A lire mes notes, la mise en œuvre des certificats LE était effectivement super simple sauf qu'il y avait dans le crontab :
32 6 * * 0 /root/certbot-auto renew -q
Apparemment, il n'est plus nécessaire de renouveler le certificat avec root (et peut-être est-ce que cela a toujours été le cas) quoique sinon je ne vois pas comment concilier ça avec la gestion d'un serveur web qui appartiennent à root.
Tu peux donner le droit de reload ton serveur web à un utilisateur non privilégié (merci sudoers). certbot marche très bien sans droit root mais doit pouvoir travailler dans les dossiers dont il dépend (par défaut /etc/letsencrypt, /var/log/lestencrypt et /var/lib/letsencrypt).
Tes workers sur un serveur web ne tournent jamais en tant que root, seul le master process le fait. Et donc il peut reloader des certifs SSL qui n'appartiennent pas à root. Par ailleurs même sans ça, c'est une question d'ACLs UNIX, et tu pourrais donner un droit de lecture sur tes certifs SSL à www-data.
Oui, je sais qu'il serait possible de configurer un serveur apache hors root mais ce n'est pas standard, notamment parce que seul root peut accéder aux ports 80 ou 443.
Cela semble hors sujet (et un redirect du port 80/443 via un firewall trivial, mais idem, hors sujet, pas nécessaire).
Quoiqu'il en soit, avoir un script obscur qui revoit potentiellement la configuration de mon serveur toutes les semaines, cela ne me plait pas.
"qui revoit" ? Que veux-tu dire ?
Je n'ai pas cherché plus loin
Et c'est bien le problème : tu as émis un avis très définitif sans avoir cherché plus loin.
et j'ai profité des certificats LE pour des contextes sans conséquences. Ce qui ne veut pas dire que l'on ne peut pas utiliser les certificats LE pour des cas autres que ceux où il n'y a pas d'enjeu…
Du coup pour ceux que ça intéresse, c'est tout à fait faisable d'utiliser du LE automatisé en prod sans compromettre sa sécurité numérique.
Et si vraiment ça vous tracasse, un reverse proxy pour servir du SSL c'est pas la mer à boire, et ça ôte bien des soucis.
Pour ce qui est de chiffrer les échanges avec un serveur web, tous les certificats se valent qu'ils soient auto-signés, wildcards, gratuits ou payants, même très chers. A la base, une clé publique c'est juste le produit de deux nombres premiers si grands que sa factorisation prendrait a priori un temps infini par rapport aux calculs modulo n dans un corps Z/nZ avec n premier
Déjà tu ne décris que RSA, il existe quand même pléthore d'algos crypto asym largement utilisés dont des moins consommateurs en ressources.
Ensuite, ce que tu décris de l'algo RSA et des maths derrière est faux¹.
qui sont faits pour chiffrer et déchiffrer les échanges… d'une clé symétrique qui sera exploité ensuite.
En effet, dans un échange SSL/TLS on crée une clef symétrique, mais la clef n'est jamais échangée dans un algo moderne². Elle est déduite, et c'est vital car ça préserve les échanges d'un replay si les clefs asym sont cassées/divulguées.
Le recours aux clés asymétriques a simplement déplacé le problème : au lieu d'avoir à assurer le partage confidentiel d'une clé symétrique, il faut s'assurer qu'une clé publique appartient bien à celui qui prétend en être le propriétaire. C'est là où les CA interviennent et l'opportunité d'en faire un racket. Racket soutenu par l'obligation artificielle de tout chiffrer. Pour cela la disponibilité des certificats LE est effectivement une bénédiction !
Car non, en vrai cela ne sert à rien de chiffrer une recette d'Irish coffe partagée sur un blog, à part pour lui éviter d'être totalement ostracisée par ggl.
La confidentialité, fortement connecté au respect de l'intimité et de la vie privée me semblent être un bon argument pour, si. De même, cela évite qu'un malandrin fasse du MITM et te fasse faire un Irish Coffee avec du méthanol.
Quant à chiffrer une librairie JS publique, je n'y avais jamais pensé mais je n'en vois pas non plus l'intérêt, d'autant moins que sous couvert de minimisation (mais en vrai pour les protéger d'une réutilisation) la plupart des librairies JS sont quasiment illisibles :-)
On se fiche de leur lisibilité, le but c'est d'éviter du MITM et une potentielle altération de ladite bibliothèque à toute fin malveillante. Le chiffrement c'est autant la confidentialité que l'authenticité que l'intégrité en fait.
Par contre conforter l'origine d'une librairie externe par la validation d’authenticité d'un CA est effectivement intéressant mais ce n'est pas le certificat du site qui l'utilise qui le fait.
Non, mais sans le certificat du site qui l'utilise tu ne peux pas valider l'authenticité du contenu de la page que tu affiches, et donc tu ne sais pas quelles libs tu vas te faire refiler.
Ah et sinon, pour répondre à la remarque du petit jeune
Aux âmes bien nées…
qui m'a gentiment dit d'arrêter de raconter n'importe quoi sur des sujets que je ne connais manifestement pas, je dirais qu'il a au moins à moitié tort. L'expérience a ceci de particulier qu'il ne me rattrapera jamais pour ce qui est de la durée sur laquelle je l'ai accumulée
C'est sans rapport avec le fait de ne pas raconter d'âneries sur un sujet qu'on ne maîtrise pas, et ton courriel renforce cette impression que tu ne maîtrises effectivement pas le sujet.
Par ailleurs, on peut avoir accumulé 40 ans d'expérience en culture des betteraves, ça ne fait pas de soi un expert en lancement de fusées.
On peut même acquérir 40 ans d'expérience en ingénierie systèmes, si celle-ci est faite de convictions erronnées, de raisonnements hâtifs, et d'un certain manque de curiosité, elle ne vaudra /in fine/ pas nécessairement plus que 15 ans bien investis dans le même domaine.
Tout est souvent une question de curiosité, un des plus grands moteurs de l'espèce humaine.
; je serai certainement mort avant :-))
Il n'est jamais interdit de changer d'approche jusqu'au dernier jour.
o/
Liste de diffusion du %(real_name)s http://www.frsag.org/
D'autant plus qu'il est tout à fait possible d'utiliser certbot pour lui faire simplement renouveler les certificats, sans lui donner les droits sur la conf apache/nginx/...
Un script maison qui lance le renouvellement, vérifie si les fichiers ont changé (par hash, par IssueDate, etc), et si ils ont changé recharger la conf du serveur web, ça prend pas non plus 50 ans à écrire. Il y a même un module ansible acme_certificate qui permet d'intégrer le renouvellement des certificats dans ses playbooks.
C'est d'ailleurs une bonne pratique pour les infras distribuées, avoir une seule machine qui renouvelle les certificats et ensuite les déploie sur tous les frontaux. Ça limite le nombre de requêtes envoyées aux serveurs Let'sEncrypt, c'est bon pour l'écologie et pour les ressources de cet outil qui sont gratuitement mises à disposition des utilisateurs.
Le 20/03/2024 à 10:45, Pierre Colombier via FRsAG a écrit :
J'ai failli écrire une réponse similaire moi même. mais puisque elle est faite,
+1 à toutes les remarques de Pierre-Eliott.
et +1000 à "Et c'est bien le problème : tu as émis un avis très définitif sans avoir cherché plus loin."
Après tout certbot, ça n'est que quelques centaines de Ko de python open source.
Et sans être un crac en python, je peux quand même dire que c'est relativement lisible.
Rien à voir avec du JS minifié.
Le 20/03/2024 à 01:37, Pierre-Elliott Bécue a écrit :
Bon, désolé, mais il y a beaucoup de choses qui me posent problème, et que je ne souhaite pas laisser sans réponse pour les éventuels lecteurs qui ne seraient pas forcément à l'aise avec le sujet ou habitués à celui-ci.
Laurent Barme 2551@barme.fr wrote on 19/03/2024 at 20:34:20+0100:
A lire mes notes, la mise en œuvre des certificats LE était effectivement super simple sauf qu'il y avait dans le crontab :
32 6 * * 0 /root/certbot-auto renew -q
Apparemment, il n'est plus nécessaire de renouveler le certificat avec root (et peut-être est-ce que cela a toujours été le cas) quoique sinon je ne vois pas comment concilier ça avec la gestion d'un serveur web qui appartiennent à root.
Tu peux donner le droit de reload ton serveur web à un utilisateur non privilégié (merci sudoers). certbot marche très bien sans droit root mais doit pouvoir travailler dans les dossiers dont il dépend (par défaut /etc/letsencrypt, /var/log/lestencrypt et /var/lib/letsencrypt).
Tes workers sur un serveur web ne tournent jamais en tant que root, seul le master process le fait. Et donc il peut reloader des certifs SSL qui n'appartiennent pas à root. Par ailleurs même sans ça, c'est une question d'ACLs UNIX, et tu pourrais donner un droit de lecture sur tes certifs SSL à www-data.
Oui, je sais qu'il serait possible de configurer un serveur apache hors root mais ce n'est pas standard, notamment parce que seul root peut accéder aux ports 80 ou 443.
Cela semble hors sujet (et un redirect du port 80/443 via un firewall trivial, mais idem, hors sujet, pas nécessaire).
Quoiqu'il en soit, avoir un script obscur qui revoit potentiellement la configuration de mon serveur toutes les semaines, cela ne me plait pas.
"qui revoit" ? Que veux-tu dire ?
Je n'ai pas cherché plus loin
Et c'est bien le problème : tu as émis un avis très définitif sans avoir cherché plus loin.
et j'ai profité des certificats LE pour des contextes sans conséquences. Ce qui ne veut pas dire que l'on ne peut pas utiliser les certificats LE pour des cas autres que ceux où il n'y a pas d'enjeu…
Du coup pour ceux que ça intéresse, c'est tout à fait faisable d'utiliser du LE automatisé en prod sans compromettre sa sécurité numérique.
Et si vraiment ça vous tracasse, un reverse proxy pour servir du SSL c'est pas la mer à boire, et ça ôte bien des soucis.
Pour ce qui est de chiffrer les échanges avec un serveur web, tous les certificats se valent qu'ils soient auto-signés, wildcards, gratuits ou payants, même très chers. A la base, une clé publique c'est juste le produit de deux nombres premiers si grands que sa factorisation prendrait a priori un temps infini par rapport aux calculs modulo n dans un corps Z/nZ avec n premier
Déjà tu ne décris que RSA, il existe quand même pléthore d'algos crypto asym largement utilisés dont des moins consommateurs en ressources.
Ensuite, ce que tu décris de l'algo RSA et des maths derrière est faux¹.
qui sont faits pour chiffrer et déchiffrer les échanges… d'une clé symétrique qui sera exploité ensuite.
En effet, dans un échange SSL/TLS on crée une clef symétrique, mais la clef n'est jamais échangée dans un algo moderne². Elle est déduite, et c'est vital car ça préserve les échanges d'un replay si les clefs asym sont cassées/divulguées.
Le recours aux clés asymétriques a simplement déplacé le problème : au lieu d'avoir à assurer le partage confidentiel d'une clé symétrique, il faut s'assurer qu'une clé publique appartient bien à celui qui prétend en être le propriétaire. C'est là où les CA interviennent et l'opportunité d'en faire un racket. Racket soutenu par l'obligation artificielle de tout chiffrer. Pour cela la disponibilité des certificats LE est effectivement une bénédiction !
Car non, en vrai cela ne sert à rien de chiffrer une recette d'Irish coffe partagée sur un blog, à part pour lui éviter d'être totalement ostracisée par ggl.
La confidentialité, fortement connecté au respect de l'intimité et de la vie privée me semblent être un bon argument pour, si. De même, cela évite qu'un malandrin fasse du MITM et te fasse faire un Irish Coffee avec du méthanol.
Quant à chiffrer une librairie JS publique, je n'y avais jamais pensé mais je n'en vois pas non plus l'intérêt, d'autant moins que sous couvert de minimisation (mais en vrai pour les protéger d'une réutilisation) la plupart des librairies JS sont quasiment illisibles :-)
On se fiche de leur lisibilité, le but c'est d'éviter du MITM et une potentielle altération de ladite bibliothèque à toute fin malveillante. Le chiffrement c'est autant la confidentialité que l'authenticité que l'intégrité en fait.
Par contre conforter l'origine d'une librairie externe par la validation d’authenticité d'un CA est effectivement intéressant mais ce n'est pas le certificat du site qui l'utilise qui le fait.
Non, mais sans le certificat du site qui l'utilise tu ne peux pas valider l'authenticité du contenu de la page que tu affiches, et donc tu ne sais pas quelles libs tu vas te faire refiler.
Ah et sinon, pour répondre à la remarque du petit jeune
Aux âmes bien nées…
qui m'a gentiment dit d'arrêter de raconter n'importe quoi sur des sujets que je ne connais manifestement pas, je dirais qu'il a au moins à moitié tort. L'expérience a ceci de particulier qu'il ne me rattrapera jamais pour ce qui est de la durée sur laquelle je l'ai accumulée
C'est sans rapport avec le fait de ne pas raconter d'âneries sur un sujet qu'on ne maîtrise pas, et ton courriel renforce cette impression que tu ne maîtrises effectivement pas le sujet.
Par ailleurs, on peut avoir accumulé 40 ans d'expérience en culture des betteraves, ça ne fait pas de soi un expert en lancement de fusées.
On peut même acquérir 40 ans d'expérience en ingénierie systèmes, si celle-ci est faite de convictions erronnées, de raisonnements hâtifs, et d'un certain manque de curiosité, elle ne vaudra /in fine/ pas nécessairement plus que 15 ans bien investis dans le même domaine.
Tout est souvent une question de curiosité, un des plus grands moteurs de l'espèce humaine.
; je serai certainement mort avant :-))
Il n'est jamais interdit de changer d'approche jusqu'au dernier jour.
o/
Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/
On Wed, Mar 20, 2024, at 11:14, Barth DELUY wrote:
C'est d'ailleurs une bonne pratique pour les infras distribuées, avoir une seule machine qui renouvelle les certificats et ensuite les déploie sur tous les frontaux. Ça limite le nombre de requêtes envoyées aux serveurs Let'sEncrypt, c'est bon pour l'écologie et pour les ressources de cet outil qui sont gratuitement mises à disposition des utilisateurs.
Et accessoirement il y a un rate-limit en place : https://letsencrypt.org/docs/rate-limits/
Le 20/03/2024 à 11:14, Barth DELUY a écrit :
D'autant plus qu'il est tout à fait possible d'utiliser certbot pour lui faire simplement renouveler les certificats, sans lui donner les droits sur la conf apache/nginx/...
Un script maison qui lance le renouvellement, vérifie si les fichiers ont changé (par hash, par IssueDate, etc), et si ils ont changé recharger la conf du serveur web, ça prend pas non plus 50 ans à écrire. Il y a même un module ansible acme_certificate qui permet d'intégrer le renouvellement des certificats dans ses playbooks.
C'est d'ailleurs une bonne pratique pour les infras distribuées, avoir une seule machine qui renouvelle les certificats et ensuite les déploie sur tous les frontaux. Ça limite le nombre de requêtes envoyées aux serveurs Let'sEncrypt, c'est bon pour l'écologie et pour les ressources de cet outil qui sont gratuitement mises à disposition des utilisateurs.
Ou alors une machine qui renouvelle les certifs et les insère dans une db que les frontaux viennent poller régulièrement, via du puppet ou autres. Cela limite les interractions directes et l'impact d'un problème de communication transitoire (par exemple, le nouveau certif est inséré en db X jours avant expiration, et ton puppet/ansible/whatever check plusieurs fois par jour et déploie/reload si besoin). Ça marche depuis des années en prod dans mon taf actuel, que ce soit sur du haproxy ou du service "load balancing" managé accessible via API.
Le 20/03/2024 à 10:45, Pierre Colombier via FRsAG a écrit :
J'ai failli écrire une réponse similaire moi même. mais puisque elle est faite,
+1 à toutes les remarques de Pierre-Eliott.
et +1000 à "Et c'est bien le problème : tu as émis un avis très définitif sans avoir cherché plus loin."
Après tout certbot, ça n'est que quelques centaines de Ko de python open source.
Et sans être un crac en python, je peux quand même dire que c'est relativement lisible.
Rien à voir avec du JS minifié.
Le 20/03/2024 à 01:37, Pierre-Elliott Bécue a écrit :
Bon, désolé, mais il y a beaucoup de choses qui me posent problème, et que je ne souhaite pas laisser sans réponse pour les éventuels lecteurs qui ne seraient pas forcément à l'aise avec le sujet ou habitués à celui-ci.
Laurent Barme 2551@barme.fr wrote on 19/03/2024 at 20:34:20+0100:
A lire mes notes, la mise en œuvre des certificats LE était effectivement super simple sauf qu'il y avait dans le crontab :
32 6 * * 0 /root/certbot-auto renew -q
Apparemment, il n'est plus nécessaire de renouveler le certificat avec root (et peut-être est-ce que cela a toujours été le cas) quoique sinon je ne vois pas comment concilier ça avec la gestion d'un serveur web qui appartiennent à root.
Tu peux donner le droit de reload ton serveur web à un utilisateur non privilégié (merci sudoers). certbot marche très bien sans droit root mais doit pouvoir travailler dans les dossiers dont il dépend (par défaut /etc/letsencrypt, /var/log/lestencrypt et /var/lib/letsencrypt).
Tes workers sur un serveur web ne tournent jamais en tant que root, seul le master process le fait. Et donc il peut reloader des certifs SSL qui n'appartiennent pas à root. Par ailleurs même sans ça, c'est une question d'ACLs UNIX, et tu pourrais donner un droit de lecture sur tes certifs SSL à www-data.
Oui, je sais qu'il serait possible de configurer un serveur apache hors root mais ce n'est pas standard, notamment parce que seul root peut accéder aux ports 80 ou 443.
Cela semble hors sujet (et un redirect du port 80/443 via un firewall trivial, mais idem, hors sujet, pas nécessaire).
Quoiqu'il en soit, avoir un script obscur qui revoit potentiellement la configuration de mon serveur toutes les semaines, cela ne me plait pas.
"qui revoit" ? Que veux-tu dire ?
Je n'ai pas cherché plus loin
Et c'est bien le problème : tu as émis un avis très définitif sans avoir cherché plus loin.
et j'ai profité des certificats LE pour des contextes sans conséquences. Ce qui ne veut pas dire que l'on ne peut pas utiliser les certificats LE pour des cas autres que ceux où il n'y a pas d'enjeu…
Du coup pour ceux que ça intéresse, c'est tout à fait faisable d'utiliser du LE automatisé en prod sans compromettre sa sécurité numérique.
Et si vraiment ça vous tracasse, un reverse proxy pour servir du SSL c'est pas la mer à boire, et ça ôte bien des soucis.
Pour ce qui est de chiffrer les échanges avec un serveur web, tous les certificats se valent qu'ils soient auto-signés, wildcards, gratuits ou payants, même très chers. A la base, une clé publique c'est juste le produit de deux nombres premiers si grands que sa factorisation prendrait a priori un temps infini par rapport aux calculs modulo n dans un corps Z/nZ avec n premier
Déjà tu ne décris que RSA, il existe quand même pléthore d'algos crypto asym largement utilisés dont des moins consommateurs en ressources.
Ensuite, ce que tu décris de l'algo RSA et des maths derrière est faux¹.
qui sont faits pour chiffrer et déchiffrer les échanges… d'une clé symétrique qui sera exploité ensuite.
En effet, dans un échange SSL/TLS on crée une clef symétrique, mais la clef n'est jamais échangée dans un algo moderne². Elle est déduite, et c'est vital car ça préserve les échanges d'un replay si les clefs asym sont cassées/divulguées.
Le recours aux clés asymétriques a simplement déplacé le problème : au lieu d'avoir à assurer le partage confidentiel d'une clé symétrique, il faut s'assurer qu'une clé publique appartient bien à celui qui prétend en être le propriétaire. C'est là où les CA interviennent et l'opportunité d'en faire un racket. Racket soutenu par l'obligation artificielle de tout chiffrer. Pour cela la disponibilité des certificats LE est effectivement une bénédiction !
Car non, en vrai cela ne sert à rien de chiffrer une recette d'Irish coffe partagée sur un blog, à part pour lui éviter d'être totalement ostracisée par ggl.
La confidentialité, fortement connecté au respect de l'intimité et de la vie privée me semblent être un bon argument pour, si. De même, cela évite qu'un malandrin fasse du MITM et te fasse faire un Irish Coffee avec du méthanol.
Quant à chiffrer une librairie JS publique, je n'y avais jamais pensé mais je n'en vois pas non plus l'intérêt, d'autant moins que sous couvert de minimisation (mais en vrai pour les protéger d'une réutilisation) la plupart des librairies JS sont quasiment illisibles :-)
On se fiche de leur lisibilité, le but c'est d'éviter du MITM et une potentielle altération de ladite bibliothèque à toute fin malveillante. Le chiffrement c'est autant la confidentialité que l'authenticité que l'intégrité en fait.
Par contre conforter l'origine d'une librairie externe par la validation d’authenticité d'un CA est effectivement intéressant mais ce n'est pas le certificat du site qui l'utilise qui le fait.
Non, mais sans le certificat du site qui l'utilise tu ne peux pas valider l'authenticité du contenu de la page que tu affiches, et donc tu ne sais pas quelles libs tu vas te faire refiler.
Ah et sinon, pour répondre à la remarque du petit jeune
Aux âmes bien nées…
qui m'a gentiment dit d'arrêter de raconter n'importe quoi sur des sujets que je ne connais manifestement pas, je dirais qu'il a au moins à moitié tort. L'expérience a ceci de particulier qu'il ne me rattrapera jamais pour ce qui est de la durée sur laquelle je l'ai accumulée
C'est sans rapport avec le fait de ne pas raconter d'âneries sur un sujet qu'on ne maîtrise pas, et ton courriel renforce cette impression que tu ne maîtrises effectivement pas le sujet.
Par ailleurs, on peut avoir accumulé 40 ans d'expérience en culture des betteraves, ça ne fait pas de soi un expert en lancement de fusées.
On peut même acquérir 40 ans d'expérience en ingénierie systèmes, si celle-ci est faite de convictions erronnées, de raisonnements hâtifs, et d'un certain manque de curiosité, elle ne vaudra /in fine/ pas nécessairement plus que 15 ans bien investis dans le même domaine.
Tout est souvent une question de curiosité, un des plus grands moteurs de l'espèce humaine.
; je serai certainement mort avant :-))
Il n'est jamais interdit de changer d'approche jusqu'au dernier jour.
o/
Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/
Merci PEB pour ton mail, que je ne peux que +1 aussi.
J'irais même plus loin que ça pour la question du "trojan" : on ne parle en fait pas de Certbot, mais de ACME, un protocole défini par la RFC 8555. Certbot n'est que son implémentation la plus courante et historique, mais j'ai par exemple l'habitude d'utiliser Dehydrated [1] à la place, relativement concis (et donc auditable si on le souhaite) et à mon sens plus léger que Certbot. (Je fais par ailleurs tourner Dehydrated en user non privilégié, avec des droits bien choisis pour pouvoir écrire les certificats et les challenges, et des droits bien choisis pour les applications qui ont besoin de ces certificats : personne n'est root dans l'histoire).
En suivant le raisonnement d'origine, on pourrait dire la même chose de tout protocole. BGP, quel cheval de troie incroyable, tout AS le fait tourner !
Le 20/03/2024 à 12:09, Théophile Bastian a écrit :
Merci PEB pour ton mail, que je ne peux que +1 aussi.
J'irais même plus loin que ça pour la question du "trojan" : on ne parle en fait pas de Certbot, mais de ACME, un protocole défini par la RFC 8555. Certbot n'est que son implémentation la plus courante et historique, mais j'ai par exemple l'habitude d'utiliser Dehydrated [1] à la place, relativement concis (et donc auditable si on le souhaite) et à mon sens plus léger que Certbot. (Je fais par ailleurs tourner Dehydrated en user non privilégié, avec des droits bien choisis pour pouvoir écrire les certificats et les challenges, et des droits bien choisis pour les applications qui ont besoin de ces certificats : personne n'est root dans l'histoire).
Donc tu as quand même préféré utiliser un autre dispositif de renouvellement plus facile à auditer et tu le fais tourner dans un contexte plus sécurisé qu'avec root. Tiens donc :-)
En suivant le raisonnement d'origine, on pourrait dire la même chose de tout protocole. BGP, quel cheval de troie incroyable, tout AS le fait tourner !
Je ne souscrits pas à ce point de vue pour le moins exagéré ni d'ailleurs aux autres affabulations de mes propos.
[1] https://github.com/dehydrated-io/dehydrated _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Mon cher Laurent,
Comme les colistiers te l'ont détaillé, ce combat me semble un mauvais fight et il y a mille manières de régler éventuellement les points que tu évoques.
Pour ma part, étant un faignant professionnel, ma génération de certs (acme.sh + acmemgr.sh en DNS01 only) est confinée dans un serveur de clés isolé et ces certs sont ensuite distribués par ssh via le réseau privé (vrack ovh pour nous) reliant toutes nos bestioles physiques sur les différentes instances concernées. Ça marche ainsi pour nos proxies web, nos (feu) serveurs de mails et autres services zarbis et stranges de nos devs. Tout ceci ne voit pas le jour du réseau public avant d'arriver à destination et c'est bien ainsi.
Au bout du compte, LE est juste une bénédiction des dieux car mettre un radis (voire un champ de carottes) chez ces dealers de certs s’insupportait.
Pourquoi payer un dealer pour utiliser un pot à miel totalement vérolé ? Ces histoires d'autorités de certification sont une blague. Du foutage de gueule absolu. Évidemment que les éléments secrets sont depuis le premier jour dans les jupes de toutes les agences à 3 ou 4 lettres, sinon ces chiffrements ne seraient juste pas permis car le déchiffrement en temps réel relève du monopole des états et de la négation de la vie privée. Mais c'est commercialement nécessaire, le grand voleur étatique ne tolère pas le petit arnaqueur privé, donc cert pour la sécu des transactions bancaires et pour le MITM et pour le SEO aussi afin d'éviter de se faire défoncer par le gougle & co.
Mais au moins c'est désormais gratuit et avec les bons outils totalement automatique et non chronophage.
Bonjour Stéphane,
Merci pour ta réponse bienveillante et apaisée…
Il n'y a pas de "fight" pour moi, juste un échange de point de vue ; c'est dommage que cela empêche certains de dormir :-)
Je suis aussi surpris par les réactions enthousiastes que l'expression de mon point de vue a suscitées ; j'ai quand même l'impression que mes propos sont mal interprétés (sans parler de ceux qui les déforment).
A la base, j'ai juste dit que je préférais dépenser 10 € pour être tranquille pendant un an plutôt que de dépendre d'un processus externe qui est potentiellement faillible ou compliqué à sécuriser. Il y d'ailleurs déjà eu des soucis (https://www.agwa.name/blog/post/last_weeks_lets_encrypt_downtime) et il suffit de chercher "bug let's encrypt" dans ton moteur de recherche préféré pour étayer cette possibilité.
Cela dit, tout choix est une question d'arbitrage qui dépend du contexte. Non seulement je ne remets pas en cause ta gestion (ni celle des autres colistiers !) de tes multiples certificats SSL mais je la trouve très bien adaptée à ton cas. Et ce n'est pas un petit bug de LE de temps en temps qui va remettre en cause ton dispositif par rapport aux milliers d'euros que tu économises.
Indépendamment, je trouve cela surprenant cette limite de validité à 90 jours pour les certificats LE. Sans parler d'une sollicitation moindre de leurs serveurs, si cela avait été un an, nous n'aurions jamais eu cette discussion.
En tout cas LE aura au moins eu un effet très bénéfique pour tout le monde en réduisant considérablement le racket des CA.
Par contre je reste médusé par ceux qui sont capables de repérer des "vunls" à toute vitesse ou de conclure qu'un traitement open source est fiable rien qu'en constatant qu'une "centaine de ko" de code sont bien lisibles ! Pour avoir exploré les sources d'openssh à la recherche de la signification de messages d'erreur inhabituels dans les logs, je n'ai clairement pas eu cette impression.
C'est une autre idée qui semble largement partagée qu'un traitement est fiable /juste/ parce qu'il est "open source". Il y a pourtant tellement de travail à faire pour _vraiment_ s'en assurer ! Et si la disponibilité des sources est indissociable de la liberté d'utilisation (et de maintenance) d'un logiciel libre, ce serait plutôt un défaut potentiel pour sa sécurité ; la possibilité d'y repérer des failles de sécurité l'est aussi pour les pirates.
A toutes fins utiles, je ne dis et ne pense pas que les logiciels open source ne sont pas fiables !
Le 20/03/2024 à 11:23, Stéphane Rivière a écrit :
Mon cher Laurent,
Comme les colistiers te l'ont détaillé, ce combat me semble un mauvais fight et il y a mille manières de régler éventuellement les points que tu évoques.
Pour ma part, étant un faignant professionnel, ma génération de certs (acme.sh
- acmemgr.sh en DNS01 only) est confinée dans un serveur de clés isolé et ces
certs sont ensuite distribués par ssh via le réseau privé (vrack ovh pour nous) reliant toutes nos bestioles physiques sur les différentes instances concernées. Ça marche ainsi pour nos proxies web, nos (feu) serveurs de mails et autres services zarbis et stranges de nos devs. Tout ceci ne voit pas le jour du réseau public avant d'arriver à destination et c'est bien ainsi.
Au bout du compte, LE est juste une bénédiction des dieux car mettre un radis (voire un champ de carottes) chez ces dealers de certs s’insupportait.
Pourquoi payer un dealer pour utiliser un pot à miel totalement vérolé ? Ces histoires d'autorités de certification sont une blague. Du foutage de gueule absolu. Évidemment que les éléments secrets sont depuis le premier jour dans les jupes de toutes les agences à 3 ou 4 lettres, sinon ces chiffrements ne seraient juste pas permis car le déchiffrement en temps réel relève du monopole des états et de la négation de la vie privée. Mais c'est commercialement nécessaire, le grand voleur étatique ne tolère pas le petit arnaqueur privé, donc cert pour la sécu des transactions bancaires et pour le MITM et pour le SEO aussi afin d'éviter de se faire défoncer par le gougle & co.
Mais au moins c'est désormais gratuit et avec les bons outils totalement automatique et non chronophage.
Le 20 mars 2024 à 14:40, Laurent Barme 2551@barme.fr a écrit :
Indépendamment, je trouve cela surprenant cette limite de validité à 90 jours pour les certificats LE. Sans parler d'une sollicitation moindre de leurs serveurs, si cela avait été un an, nous n'aurions jamais eu cette discussion.
https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html
C’est un point de vue qui se défend.
Le 20/03/2024 à 14:51, David Ponzone a écrit :
Le 20 mars 2024 à 14:40, Laurent Barme <2551@barme.fr mailto:2551@barme.fr> a écrit :
Indépendamment, je trouve cela surprenant cette limite de validité à 90 jours pour les certificats LE. Sans parler d'une sollicitation moindre de leurs serveurs, si cela avait été un an, nous n'aurions jamais eu cette discussion.
https://letsencrypt.org/2015/11/09/why-90-days.html
C’est un point de vue qui se défend.
Intéressant ; merci pour le lien.
Mais l'automatisation systématique est-elle vraiment un gage de sécurité absolue ?
Mais l'automatisation systématique est-elle vraiment un gage de sécurité absolue ?
L'auteur principal du protocole ACME s'appelle Barnes. Vu de loin, c'est comme ton nom ;)
L'automatisation est un gage de sûreté (de fonctionnement), une notion différente mais complémentaire de la sécurité.
Le 20 mars 2024 à 14:59, Laurent Barme 2551@barme.fr a écrit :
Mais l'automatisation systématique est-elle vraiment un gage de sécurité absolue ?
Tu vois un autre moyen ? J’imagine un FAI/intégrateur ou même un grand compte qui gère plusieurs centaines ou milliers de certificats, il fait comment ?
C’est pas la faute de LE si on est passés à 13 mois max, c’était plutôt un coup de pression (=décision unilatérale) des GAFAM non ? Ca a quand même initié un truc: l’automatisation, et j’ai l’impression que les gros CA étaient un peu à la bourre sur le sujet avant que LE prenne le marché. Le côté négatif de LE c’est que ça permet à n’importe quel margoulin de présenter un site avec une facade clean en apparence.
David
Le 20/03/2024 à 15:22, David Ponzone a écrit :
Le côté négatif de LE c’est que ça permet à n’importe quel margoulin de présenter un site avec une facade clean en apparence.
Tout à fait. Du temps où les navigateurs distinguaient les certificats EV d'une barre verte, il y avait une vrai valeur ajoutée pour ces certificats apportée par un contrôle /humain/, rigoureux et approfondi de la légitimité d'un site.
Existe-t-il des certifications ISO ou autres labellisations de qualité qui soient entièrement automatisées ?
Bonsoir,
Très franchement, entre les PME où les équipes d'infras sont réduites et assez prises par les incendies à éteindre ou des utilisateurs un peu trop insistants, et les grosses structures qui ont trop de certificats à gérer pour le faire à la main, l'automatisation c'est pas si mal.
On peut rigoler, mais j'ai bien souvent vu en PME les certificats TLS renouvelés dans la semaine après leur expiration. Et ca, c'est quand l'équipe responsable n'a pas sa semaine réservée pour un workshop dans un coin sans internet.
Une bonne automatisation, avec une bonne supervision pour valider que tout marche, c'est ca en moins dans les tâches d'exploitations courantes, pour quelque chose qui n'a que peu de valeur ajoutée quand c'est fait manuellement, au même titre que personne ne va non plus lancer les backups de son infra manuellement tout les matins.
Le 20/03/2024 à 14:59, Laurent Barme a écrit :
Le 20/03/2024 à 14:51, David Ponzone a écrit :
Le 20 mars 2024 à 14:40, Laurent Barme <2551@barme.fr mailto:2551@barme.fr> a écrit :
Indépendamment, je trouve cela surprenant cette limite de validité à 90 jours pour les certificats LE. Sans parler d'une sollicitation moindre de leurs serveurs, si cela avait été un an, nous n'aurions jamais eu cette discussion.
https://letsencrypt.org/2015/11/09/why-90-days.html https://letsencrypt.org/2015/11/09/why-90-days.html
C’est un point de vue qui se défend.
Intéressant ; merci pour le lien.
Mais l'automatisation systématique est-elle vraiment un gage de sécurité absolue ?
Liste de diffusion du %(real_name)s http://www.frsag.org/
Le 20/03/2024 à 14:51, David Ponzone a écrit :
Le 20 mars 2024 à 14:40, Laurent Barme 2551@barme.fr a écrit :
Indépendamment, je trouve cela surprenant cette limite de validité à 90 jours pour les certificats LE. Sans parler d'une sollicitation moindre de leurs serveurs, si cela avait été un an, nous n'aurions jamais eu cette discussion.
https://letsencrypt.org/2015/11/09/why-90-days.html
C’est un point de vue qui se défend.
J'ai entendu, et c'est confirmé par une petite recherche, que Google imposerait bientôt des certificats de 90 jours. Il vaudra mieux à ce moment là avoir une procédure de renouvellement automatique.
https://techbeacon.com/security/90-day-ssltls-validity-coming
Alain
Le 21/03/2024 à 14:37, Alain Péan via FRsAG a écrit :
J'ai entendu, et c'est confirmé par une petite recherche, que Google imposerait bientôt des certificats de 90 jours. Il vaudra mieux à ce moment là avoir une procédure de renouvellement automatique.
https://techbeacon.com/security/90-day-ssltls-validity-coming
Alain
Et bien voilà une information qui clos le débat sur l'automatisation de la mise à jour des certificats SSL !
Merci Alain.
Le 21/03/2024 à 15:20, Laurent Barme a écrit :
J'ai entendu, et c'est confirmé par une petite recherche, que Google imposerait bientôt des certificats de 90 jours. Il vaudra mieux à ce moment là avoir une procédure de renouvellement automatique.
https://techbeacon.com/security/90-day-ssltls-validity-coming
Alain
Et bien voilà une information qui clos le débat sur l'automatisation de la mise à jour des certificats SSL !
Voir aussi, en français :
https://www.journaldunet.com/solutions/dsi/1523885-cycles-de-vie-raccourcis-...
Alain
Et bien voilà une information qui clos le débat sur l'automatisation de la mise à jour des certificats SSL !
Oui !
Voir aussi, en français :
https://www.journaldunet.com/solutions/dsi/1523885-cycles-de-vie-raccourcis-...
/Certes l'ACME (Automated Certificate Management Environment) peut aider les entreprises à adopter l'automatisation, il ne s'agit pas d'une solution universelle. Les équipes informatiques et de sécurité ont besoin d'une approche pluridimensionnelle de l'automatisation, comprenant l'utilisation de protocoles d'inscription standard comme ACME, SCEP et EST, ainsi que d'outils d'automatisation du cycle de vie des certificats, afin de s'assurer qu'elles peuvent répondre à tous les cas d'usage. /
Plus haut...
En réalité, ce ne sont pas les certificats qui posent problème mais le facteur humain. /Les gens ont tendance à oublier de les renouveler et ne peuvent se concentrer que sur un nombre limité de tâches. Ce constat est clé à l’heure où la durée de vie des certificats diminue et que la charge de travail liée à leur renouvellement est multipliée par 4 ou 5./
La seule chose qui ne change pas en IT, c'est que le journaldunet, 01info, etc. sont toujours des lectures de décideurs ;>
Dans la vraie vie du monde réel, ACME/LE nous ont permis de tout automatiser. C'est devenu totalement transparent dans un cadre plus large de tâches à un niveau au dessus (créer/supprimer un site web, une interface d'admin, etc.).
Avé Laurent,
Merci pour ta réponse bienveillante et apaisée…
Mouarf :)))
Cela dit, tout choix est une question d'arbitrage qui dépend du contexte. Non seulement je ne remets pas en cause ta gestion (ni celle des autres colistiers !) de tes multiples certificats SSL mais je la trouve très bien adaptée à ton cas. Et ce n'est pas un petit bug de LE de temps en temps qui va remettre en cause ton dispositif par rapport aux milliers d'euros que tu économises.
En fait, tout automatisme LE correctement implémenté va réessayer. En 5 ans, j'ai jamais eu de renouvellement foiré. C'est transparent. On s'occupe de rien. Ça juste marche.
Indépendamment, je trouve cela surprenant cette limite de validité à 90 jours pour les certificats LE. Sans parler d'une sollicitation moindre de leurs serveurs, si cela avait été un an, nous n'aurions jamais eu cette discussion.
C'est 90 jours volontairement. Ils auraient posé 30 jours, ça ne m'aurait pas dérangé, bien au contraire. Je préfère du poisson frais à de l'avarié. Un certificat, c'est le même esprit. LE a posé la fraîcheur à 90 jours... En soit, c'est beaucoup plus propre qu'un cert valable un an... Et moins propre qu'un cert valable 30 jours. C'est un compromis. De toute façon, le précédent message a bien précisé mon point de vue sur les certs dont le certificat racine est "quelque part" dans un espace-temps "incontrôlé" :)
Par contre je reste médusé par ceux qui sont capables de repérer des "vunls" à toute vitesse ou de conclure qu'un traitement open source est fiable rien qu'en constatant qu'une "centaine de ko" de code sont bien lisibles ! Pour avoir exploré les sources d'openssh à la recherche de la signification de messages d'erreur inhabituels dans les logs, je n'ai clairement pas eu cette impression.
OpenSSH, t'as pris un bon exemple de simplicité :>>> Dans le cas de LE, il s'agit de l'implémentation du RFC8555 qui reste modeste. Il y a des clients ACME qui sont tous petits. Ici on a prévu de remplacer acme.sh et acmemgr.sh par un package et un utilitaire codés en Ada/Spark (programmation par contrat - https://en.wikipedia.org/wiki/SPARK_(programming_language). Ça fera un sujet qualitatif pour un stagiaire curieux.
Laurent Barme 2551@barme.fr wrote on 20/03/2024 at 14:40:01+0100:
Bonjour Stéphane,
Merci pour ta réponse bienveillante et apaisée…
Il n'y a pas de "fight" pour moi, juste un échange de point de vue ; c'est dommage que cela empêche certains de dormir :-)
Rassure-toi, l'intérêt que je porte à cet échange n'est pas la cause de ma courte nuit.
Je suis aussi surpris par les réactions enthousiastes que l'expression de mon point de vue a suscitées ; j'ai quand même l'impression que mes propos sont mal interprétés (sans parler de ceux qui les déforment).
Tu veux dire que quand tu écris que c'est un cheval de Troie il fallait lire "ce n'est PAS un cheval de Troie" ? Ou que "Z/nZ avec n premier" signifiait "Z/pqZ avec p et q premiers" ? Ou que quand tu disais que "le tout SSL est inutile", tu voulais dire "qu'il était inutile uniquement pour la partie confidentialité des données quand celles-ci sont publiques, mais qu'il était néanmoins totalement utile totalement pour l'intégrité et l'authenticité" ?
Ou bien tu essaies de te rattraper aux branches en constatant l'énormité des bêtises que tu as énoncées ? Je trouve l'inversion accusatoire assez caractérisée : tu essaies de ranger ceux qui ne laissent pas passer tes propos délirants qui peuvent avoir un impact fort sur des juniors qui tomberaient sur ce thread dans la case des malhonnêtes.
A la base, j'ai juste dit que je préférais dépenser 10 € pour être tranquille pendant un an plutôt que de dépendre d'un processus externe qui est potentiellement faillible ou compliqué à sécuriser.
Tu n'as pas dit cela comme ça, et surtout tu l'as argumenté par des arguments au mieux exagérés, voire bidons.
Il y d'ailleurs déjà eu des soucis (https://www.agwa.name/blog/post/last_weeks_lets_encrypt_downtime) et il suffit de chercher "bug let's encrypt" dans ton moteur de recherche préféré pour étayer cette possibilité.
C'est vrai qu'aucun provider payant de certificats n'a eu de soucis, que ce soit des bugs ou des outage, ou des émissions de certificats impersonnalisant des sites bien connus au profit d'autorités malveillantes. Non, vraiment, c'est jamais arrivé¹.
Indépendamment, je trouve cela surprenant cette limite de validité à 90 jours pour les certificats LE. Sans parler d'une sollicitation moindre de leurs serveurs, si cela avait été un an, nous n'aurions jamais eu cette discussion.
Le lien t'ayant déjà été communiqué je ne le remettrai pas, vu que l'article est public depuis des années (certes derrière du https, brrr), j'imagine que c'est à ranger derrière "je n'ai pas cherché plus loin".
Par contre je reste médusé par ceux qui sont capables de repérer des "vunls" à toute vitesse ou de conclure qu'un traitement open source est fiable rien qu'en constatant qu'une "centaine de ko" de code sont bien lisibles ! Pour avoir exploré les sources d'openssh à la recherche de la signification de messages d'erreur inhabituels dans les logs, je n'ai clairement pas eu cette impression.
Ce n'est pas ce qui a été dit. Ce qui a été dit c'est que la transparence est là, donc tu sais dans quoi tu mets les pieds, et qu'il est bien plus facile de trouver rapidement une vuln dans un code ouvert que dans un code auquel tu n'as pas accès.
C'est une autre idée qui semble largement partagée qu'un traitement est fiable juste parce qu'il est "open source".
Non. L'idée couramment partagée c'est qu'un traitement open source/libre est auditable. Et oui, pléthore de gens utilisent des tools sans les avoir étudiés/audités. C'est leur problème. Mais s'en remettre à un outil fermé/privé ne change rien, et enlève beaucoup de possibilités d'audit.
Il y a pourtant tellement de travail à faire pour vraiment s'en assurer ! Et si la disponibilité des sources est indissociable de la liberté d'utilisation (et de maintenance) d'un logiciel libre, ce serait plutôt un défaut potentiel pour sa sécurité ; la possibilité d'y repérer des failles de sécurité l'est aussi pour les pirates.
Et encore un poncif bien éculé.
C'est donc ça d'avoir 40 ans de métier ? En remettre une couche même quand on a les yeux sur les âneries qu'on a déjà raconté ?
Pas pressé de te rattraper dans ce cas.
Bref, j'arrête là en ce qui concerne mon interaction avec toi, ta mauvaise foi rend la chose non constructive.
J'espère juste avoir dissuadé quiconque de te faire confiance sur le sujet de la crypto et de la sécurisation d'un site web.
Et comme dit, je suis inquiet pour tes clients, mais en définitive, ce n'est pas mon problème, c'est le leur.
Le 20/03/2024 à 15:26, Pierre-Elliott Bécue a écrit : … Mais quelle agressivité ! Mal dormi peut-être ?
Bref, j'arrête là en ce qui concerne mon interaction avec toi
Ah, enfin une bonne nouvelle. J'espère que tu t'y tiendras, du moins tant que tu liras mes propos avec un esprit aussi vindicatif.
, ta mauvaise foi rend la chose non constructive.
Là je suis d'accord : ta mauvaise foi rend la discussion non constructive.
Mais quelle agressivité !
C'est clair que t'as pris cher. C'était pas mérité quand on te connais... T'avais juste un avis taquin et non consensuel (ce mot est remarquable ;).
Il faut quand même préciser que ces dealers de certs payants sont parfois/souvent des passoires. Ils peuvent apporter plus de problèmes que de solutions, tout du moins pour un service payant.
Affichant une préférence pour une engeance qu'on aime pas trop (voire qu'on déteste carrément, mon cas), ça peut déclencher des réactions épidermiques car ce fut un très long combat de tranchées pour arriver à la LE !
Aujourd'hui LE est peut-être (probablement ?) mieux audité que pas mal de ces dealers.
Et (imho) LE est extraordinairement simple et fiable quand on le prend par le bon bout (automatisation par la méthode DNS01, la seule qui permet de scaler et d'avoir une reconnaissance de la propriété du domaine sans que le site web soit opérationnel, ce qui est généralement le cas quand on a une automation complète : on créée le certificat de préférence avant de faire monter le site).
Pour bricoler, le bac à sable est parfait. Et enfin c'est devenu un process standardisé par une RFC. Santé bonheur.
Comme a dit un colistier, ça a mis un coup de pied dans un petit monde bien assoupi sur un matelas de dollars bien mal acquits...
Si un jour t'as envie de goûter, je te filerais quelques infos et tu seras étonné de la simplicité.
Hello,
Stéphane Rivière stef@genesix.org wrote on 20/03/2024 at 17:20:33+0100:
Mais quelle agressivité !
C'est clair que t'as pris cher. C'était pas mérité quand on te connais... T'avais juste un avis taquin et non consensuel (ce mot est remarquable ;).
Alors histoire de remettre les choses dans leur contexte, je n'ai aucun problème avec les avis non-consensuels pertinents et argumentés, ou avec les trolls quand ils en sont (même si ça peut être chiant dans une discussion sérieuse).
Mais quand quelqu'un énonce des conneries avec tout le sérieux du monde, persiste et signe avec un ton péremptoire (l'argument d'autorité du petit jeune c'est toujours une bonne blague quand je vois le nombre de types avec 3x mon expérience pro qui sont pas foutus de faire le tiers de ce que je fais, et des jeunes plus jeunes que moi qui ont un meilleur niveau que celui que j'avais à leur âge) et tente de faire passer les autres pour ceux qui comprennent pas et déforment les propos, ben là c'est all-in. On a déjà assez de problèmes de bonnes pratiques en sécu sans en rajouter par le biais de tenants de la profession.
Alors ptet que Laurent est un très bon convive de PMU pour boire un verre et faire des hypothèses sur l'avenir géopolitique et climatique, mais il n'empêche qu'il énonce connerie sur connerie sur le sujet de la crypto, et que, le nez dedans, il continue. Je serais ravi de l'ignorer si cela n'avait pas d'impact sur les croyances de gens qui n'ont pas encore l'expérience pour se faire un avis sur le sujet, mais c'est pas le cas : FRSAG est lue par des novices.
Il faut quand même préciser que ces dealers de certs payants sont parfois/souvent des passoires. Ils peuvent apporter plus de problèmes que de solutions, tout du moins pour un service payant.
Affichant une préférence pour une engeance qu'on aime pas trop (voire qu'on déteste carrément, mon cas), ça peut déclencher des réactions épidermiques car ce fut un très long combat de tranchées pour arriver à la LE !
Aujourd'hui LE est peut-être (probablement ?) mieux audité que pas mal de ces dealers.
Et (imho) LE est extraordinairement simple et fiable quand on le prend par le bon bout (automatisation par la méthode DNS01, la seule qui permet de scaler et d'avoir une reconnaissance de la propriété du domaine sans que le site web soit opérationnel, ce qui est généralement le cas quand on a une automation complète : on créée le certificat de préférence avant de faire monter le site).
Pour bricoler, le bac à sable est parfait. Et enfin c'est devenu un process standardisé par une RFC. Santé bonheur.
Comme a dit un colistier, ça a mis un coup de pied dans un petit monde bien assoupi sur un matelas de dollars bien mal acquits...
Comme les vendeurs de NDD, que Gandi (dont on parlait il y a une semaine) a historiquement contribué à remettre au pas.
Dommage qu'elle n'ait pas continué dans ce sens.
Le 20/03/2024 à 17:20, Stéphane Rivière a écrit :
Mais quelle agressivité !
C'est clair que t'as pris cher.
T'as vu ça, c'est impressionnant comme notre ami PEB a de l'agressivité à revendre, en tout cas beaucoup plus que de subtilité ou d'humour.
Mais heureusement qu'il est là pour protéger les novices qui lisent FRsAG et qui sont évidement incapables de se faire une idée par eux même. Quoique je doute qu'un ton aussi vindicatif soit très pédagogique.
Parfois je me demande quand même s'il se rend compte de ce qu'il écrit. Par exemple quand il dit "/qu'il est bien plus facile de trouver rapidement une vuln dans un code ouvert que dans un code auquel tu n'as pas accès./" il ne fait que conforter mon point de vue sur le fait que l'open source serait plus facile à pirater. Aurais-je dit autre chose que des "conneries" ?
J'ai pas bien compris non plus où il va chercher des "inversion accusatoire", "argument d'autorité" et encore moins que j’essaierai de le "ranger … dans la case des malhonnêtes" !! Mais bon, c'est pas grave.
…
Si un jour t'as envie de goûter, je te filerais quelques infos et tu seras étonné de la simplicité.
Ah, LE présenté comme ça, c'est tout de suite plus attractif.
Parfois je me demande quand même s'il se rend compte de ce qu'il écrit. Par exemple quand il dit "qu'il est bien plus facile de trouver rapidement une vuln dans un code ouvert que dans un code auquel tu n'as pas accès." il ne fait que conforter mon point de vue sur le fait que l'open source serait plus facile à pirater. Aurais-je dit autre chose que des "conneries" ?
Bon, je ne suis pas intervenu dans ton troll LE mais je me dois d intervenir su celui ci . Oui il a surement été un peu agressif ( mais sans insultes ) et en gros il avait raison a 99% sur tout. La tu attaque l open source. Je suppose que tu n es QUE sysadmin et pas du tout codeur ? ( ici un sysadmin de 50 ans qui est aussi développeur C, et j en passe )
Oui avec l open source il est facile de decouvrir une faille ! DONC : * Il est tres probable que la faille sera decouverte RAPIDEMENT , car plein de gens qui sont aussi paranos que toi et moi, vont jeter un oeil au code, et les plus autiste d entre nous y passeront peut etre plusieurs jours ( ou nuits ), dans le cas d un truc que tu CROIE .devoir faire tourner en root. * Le mec qui voudrait mettre une backdoor dans un logiciel choisira la boite noire, car si il a un minimum d intelligence, il sait que sa backdoor sera vite decouverte et qu il perdra au minimum sa reputation, et au maximum . . . beaucoup plus.
DONC : * inserer volontairement une backdoor dans un logiciel FOSS est tellement risqué que c est rare.
AU PIRE : * parfois une faille ou une backdoor se retrouve dans un logiciel open source * elle est decouverte 1000 fois plus vite que dans une boite noire. * res peu de gens , voire aucun, se feront pirater par cette faille open source. * le probleme sera réglé tres rapidement pour les milliers d autres utilisateurs qui se seraient fait pirater si cette backdoor etait dans une boite noire.
EXCEPTION : des gens qui ont de très gros moyens, comme par exemple la N SA, sont capables de t' inventer des backdoors multi niveau très complexes et quasiment introuvables, car elles n' existent pas à première vue. depuis 30 ans je n ai vu personnellement passer qu une seule faille de ce genre : https://grsecurity.net/~spender/exploits/exploit2.txt et ca date ( en gros ) de l epoque du hard fork agressif de gcc 2.95.2 par redhat.
/* super fun 2.6.30+/RHEL5 2.6.18 local kernel exploit in /dev/net/tun A vulnerability which, when viewed at the source level, is unexploitable! But which, thanks to gcc optimizations, becomes exploitable :) Also, bypass of mmap_min_addr via SELinux vulnerability! (where having SELinux enabled actually increases your risk against a large class of kernel vulnerabilities) */
Le 20/03/2024 à 20:58, neo futur a écrit :
Bon, je ne suis pas intervenu dans ton troll LE mais je me dois d intervenir su celui ci .
Merci d'intervenir ; je suis intéressé par toute discussion constructive qui pourrait faire progresser mes connaissances, surtout lorsque c'est fait sans agressivité.
Non, je n'ai jamais eu l'intention de troller quoique ce soit. Bien au contraire, je n'imaginais pas que suggérer sur FrsAG qu'exécuter un processus en root ne serait pas une bonne pratique au niveau sécurité puisse déclencher une telle réaction.
La tu attaque l open source. Je suppose que tu n es QUE sysadmin et pas du tout codeur ? ( ici un sysadmin de 50 ans qui est aussi développeur C, et j en passe )
Pas du tout, je "n'attaque" pas l'open source et je suis surtout "codeur". Je pense simplement que ce n'est pas le fait que le code soit "open" qui le rend plus sûr. Par contre je redis qu'il faut qu'il soit open pour être libre.
Oui avec l open source il est facile de decouvrir une faille !
Ah, au moins un point où on est presque d'accord. Il est /plus/ facile de découvrir une faille en analysant un code que l'on peut lire qu'un code qu'on ne peut pas lire :-)
DONC :
- Il est tres probable que la faille sera decouverte RAPIDEMENT ,
C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ?
Pour mon premier travail salarié, j'ai eu pour mission de maintenir un programme d'affichage et de traitement d'informations financières en temps réel. Il était profondément buggé, son concepteur étant plus porté sur le fun que la rigueur. Mais parmi les innombrables bugs, il y en avait un qui n'était pas complètement de sa faute. La mémoire allouée au processus principale de ce programme enflait progressivement au point de le planter ; cela faisait désordre dans les salles de marché. Il m'a fallu un temps considérable pour trouver l'origine du problème. J'ai dû écrire une surcouche aux malloc()/free() pour tracer les fuites. Il y en avait une particulièrement inattendue sur la fonction time() qui manquait manifestement de free(). Le logiciel affichait les heures des principales places boursière du monde entier et la fonction time() était appelée plusieurs fois chaque seconde… Je garde de cette expérience une profonde aversion pour la maintenance d'un code écrit par un autre et une idée précise de la difficulté de cette tâche.
car plein de gens qui sont aussi paranos que toi et moi, vont jeter un oeil au code, et les plus autiste d entre nous y passeront peut etre plusieurs jours ( ou nuits ),
J'ai un gros doute sur le fait que plein de gens (bienveillants) passent du temps à chercher des failles dans les logiciels open source. Je sais par ma première expérience évoqué ci-dessus que c'est un travail très compliqué. Qui les payerait pour cela ? Mais je ne demande qu'à me tromper ; ce serait une bonne nouvelle. Par contre l'utilisation massive de logiciels open source me semble un facteur bien plus rassurant sur leur fiabilité. Cela multiplie les opportunités de remarquer des failles (ou des bugs).
dans le cas d un truc que tu CROIE .devoir faire tourner en root.
Ce n'est pas une question de croyance, c'était juste un constat. Mon installation standard de cerbot aboutissait à un processus lancé par root.
- Le mec qui voudrait mettre une backdoor dans un logiciel choisira la
boite noire, car si il a un minimum d intelligence, il sait que sa backdoor sera vite decouverte et qu il perdra au minimum sa reputation, et au maximum . . . beaucoup plus.
Il n'y a pas que l'insertion volontaire d'une faille ; elle peut s'y trouver à l'insu du codeur ; cf. le bug de la fonction time() évoquée plus haut.
DONC :
- inserer volontairement une backdoor dans un logiciel FOSS est
tellement risqué que c est rare.
AU PIRE :
- parfois une faille ou une backdoor se retrouve dans un logiciel open source
Oui.
- elle est decouverte 1000 fois plus vite que dans une boite noire.
Encore faut-il que ce soit pas découvert par un pirate :-)
- res peu de gens , voire aucun, se feront pirater par cette faille open source.
- le probleme sera réglé tres rapidement pour les milliers d autres
utilisateurs qui se seraient fait pirater si cette backdoor etait dans une boite noire.
De toute évidence je ne partage pas cette conviction, voir plus haut.
EXCEPTION : des gens qui ont de très gros moyens, comme par exemple la N SA, sont capables de t' inventer des backdoors multi niveau très complexes et quasiment introuvables, car elles n' existent pas à première vue.
Il y a aussi eu un concours organisé pour ce genre de sport : http://www.underhanded-c.org/ ; tiens c'est marrant, le lien https ne fonctionne pas pour ce site :-0
depuis 30 ans je n ai vu personnellement passer qu une seule faille de ce genre : https://grsecurity.net/~spender/exploits/exploit2.txt et ca date ( en gros ) de l epoque du hard fork agressif de gcc 2.95.2 par redhat.
/* super fun 2.6.30+/RHEL5 2.6.18 local kernel exploit in /dev/net/tun A vulnerability which, when viewed at the source level, is unexploitable! But which, thanks to gcc optimizations, becomes exploitable :) Also, bypass of mmap_min_addr via SELinux vulnerability! (where having SELinux enabled actually increases your risk against a large class of kernel vulnerabilities) */
Merci d'intervenir ; je suis intéressé par toute discussion constructive qui pourrait faire progresser mes connaissances, surtout lorsque c'est fait sans agressivité.
Pas de probleme, j' essaye de ne pas être agressif, mais tu sais quand on est convaincu de ce qu' on dit . . . on a parfois l' air agressif, trop critique ou condescendant . . .
Non, je n'ai jamais eu l'intention de troller quoique ce soit. Bien au contraire, je n'imaginais pas que suggérer sur FrsAG qu'exécuter un processus en root ne serait pas une bonne pratique au niveau sécurité peut déclencher une telle réaction.
Oui, mais le fait est que tu avais tort, il est possible et assez facile, de gérer ça sans que le processus soit root, ton installation par défaut n' est pas la vérité ultime. De plus, meme en root, quand un peut lire et comprendre le script facilement et rapidement . . . le probleme reste moins grave qu' une boîte noire, que tu exécutes sans avoir aucune idée du code qui s'exécute.
La tu attaque l open source. Je suppose que tu n es QUE sysadmin et pas du tout codeur ? ( ici un sysadmin de 50 ans qui est aussi développeur C, et j en passe )
Pas du tout, je "n'attaque" pas l'open source et je suis surtout "codeur". Je pense simplement que ce n'est pas le fait que le code soit "open" qui le rend plus sûr. Par contre je redis qu'il faut qu'il soit open pour être libre.
Tu insinue le fait qu' un code open source est plus vulnérable et dangereux car on peut lire le code. c' est là le troll ( sournois , mais je ne t en veux pas , tu n es pas le premier a te poser ce genre de questions ) que je suis obligé de combattre. Un troll qui a été débunké à tous les niveaux, notamment pas les FAITS ces 20 dernières années.
Oui avec l open source il est facile de decouvrir une faille ! Ah, au moins un point où on est presque d'accord. Il est plus facile de découvrir une faille en analysant un code que l'on peut lire qu'un code qu'on ne peut pas lire :-)
Certes, et c' est toute la force de l' open source, si il y a une faille ou une backdoor, on va la niquer vite fait, et on passera a la suite. Ceci dit, tu restes libre de croire que c' est mieux de laisser la faille se répandre pendant 20 ans avant que la moitié de la planète ne se fasse pirater betement par une boite noire auquel tout le monde fait confiance vu qu on peut pas voir le code.
DONC :
- Il est tres probable que la faille sera decouverte RAPIDEMENT ,
C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ?
Plusieurs raisons sont possibles, dans le cas d un logiciel comme openssh le plus probable c est : * optimisation * respecter des specs complexes et de tres nombreux cas particuliers
Si tu veux plonger dans le code d un logiciel comme openssh ou bitcoin . . . ca va prendre d temps, il ne suffit d etre un bon codeur.
Pour mon premier travail salarié, j'ai eu pour mission de maintenir un programme d'affichage et de traitement d'informations financières en temps réel. Il était profondément buggé, son concepteur étant plus porté sur le fun que la rigueur. Mais parmi les innombrables bugs, il y en avait un qui n'était pas complètement de sa faute. La mémoire allouée au processus principale de ce programme enflait progressivement au point de le planter ; cela faisait désordre dans les salles de marché. Il m'a fallu un temps considérable pour trouver l'origine du problème. J'ai dû écrire une surcouche aux malloc()/free() pour tracer les fuites. Il y en avait une particulièrement inattendue sur la fonction time() qui manquait manifestement de free(). Le logiciel affichait les heures des principales places boursière du monde entier et la fonction time() était appelée plusieurs fois chaque seconde… Je garde de cette expérience une profonde aversion pour la maintenance d'un code écrit par un autre et une idée précise de la difficulté de cette tâche.
Je comprends tout a fait ca, ca mest arrivé. On a essayé d expliquer a bull que ca serait plus rapide de tout réécrire proprement, ils ont refusé, je me suis battu pour me faire licencier. Ce genre de chose ne devrait pas arriver, il existe des outils comme valgrind, qui me permettent d'être sûr à 99.99% que quand je livre un code, il n y a aucune fuite mémoire, aucun buffer overflow, aucun null pointer dereference . . .
plein de gens qui sont aussi paranos que toi et moi, vont jeter un oeil au code, et les plus autiste d entre nous y passeront peut etre plusieurs jours ( ou nuits ),
J'ai un gros doute sur le fait que plein de gens (bienveillants) passent du temps à chercher des failles dans les logiciels open source. Je sais par ma première expérience évoqué ci- dessus que c'est un travail très compliqué. Qui les payerait pour cela ? Mais je ne demande qu'à me tromper ; ce serait une bonne nouvelle. Par contre l'utilisation massive de logiciels open source me semble un facteur bien plus rassurant sur leur fiabilité. Cela multiplie les opportunités de remarquer des failles (ou des bugs).
C' est le cœur de ton problème, tu ne peux pas imaginer qu' il existe des gens bienveillants, trop intelligents ou trop autistes pour rentrer dans l' arnaque globale du système dans lequel nous vivons. C est vrai que ce genre de gens bienveillants, ou neutres, trop intelligents ou trop autistes finissent souvent cancres, clochards ou suicidés avant 20 ans, mais certains survivent . . . et ce genre de débiles autistes survivants sont ceux qui ont fait l open source, linux, la GPL, bitcoin, internet, et j' en passe.
Ce n'est pas une question de croyance, c'était juste un constat. Mon installation standard de cerbot aboutissait à un processus lancé par root.
Le fait est que tu avais tort, dorénavant tu sais qu' il y a moyen de ne pas tourner en root. Tu avais tort par ignorance ou feignantise, admets le STP !
- Le mec qui voudrait mettre une backdoor dans un logiciel choisira la
boite noire, car si il a un minimum d intelligence, il sait que sa backdoor sera vite decouverte et qu il perdra au minimum sa reputation, et au maximum . . . beaucoup plus.
Il n'y a pas que l'insertion volontaire d'une faille ; elle peut s'y trouver à l'insu du codeur ; cf. le bug de la fonction time() évoquée plus haut.
C est pareil, backdoor ou pas, quand on OSE faire de l open source on tient a sa reputation et on essaye de ne pas faire de la merde, de ne pas livres des fuites memoires, des buffer overflow . . .
Il y a aussi eu un concours organisé pour ce genre de sport : http://www.underhanded-c.org/ ; tiens c'est marrant, le lien https ne fonctionne pas pour ce site :-0
sauf que la je parle de redhat, de la N SA, de GCC, de la libc et du kernel :p
/* super fun 2.6.30+/RHEL5 2.6.18 local kernel exploit in /dev/net/tun A vulnerability which, when viewed at the source level, is unexploitable! But which, thanks to gcc optimizations, becomes exploitable :) Also, bypass of mmap_min_addr via SELinux vulnerability! (where having SELinux enabled actually increases your risk against a large class of kernel vulnerabilities) */
Liste de diffusion du %(real_name)s http://www.frsag.org/
Le Wed, Mar 20, 2024 at 10:07:11PM +0100, Laurent Barme a écrit :
C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ?
J'imagine que tu veux dire OpenSSL et pas OpenSSH ?
Le 21/03/2024 à 09:31, Denis Fondras via FRsAG a écrit :
Le Wed, Mar 20, 2024 at 10:07:11PM +0100, Laurent Barme a écrit :
C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ?
J'imagine que tu veux dire OpenSSL et pas OpenSSH ?
C'est bien d'openSSH dont je parle. J'ai partagé mon expérience à ce sujet sur mon blog : https://blog.nun.tf/les-limites-de-lopen-source/ ; si tu veux bien le lire, tes remarques et commentaires sont les bienvenus.
Le Thu, Mar 21, 2024 at 11:16:20AM +0100, Laurent Barme a écrit :
Le 21/03/2024 à 09:31, Denis Fondras via FRsAG a écrit :
Le Wed, Mar 20, 2024 at 10:07:11PM +0100, Laurent Barme a écrit :
C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ?
J'imagine que tu veux dire OpenSSL et pas OpenSSH ?
C'est bien d'openSSH dont je parle. J'ai partagé mon expérience à ce sujet sur mon blog : https://blog.nun.tf/les-limites-de-lopen-source/ ; si tu veux bien le lire, tes remarques et commentaires sont les bienvenus.
Dire qu'un projet écrit en C est *trop* complexe parce qu'il utilise des pointeurs de fonction... nan, désolé, ça ne passe pas. Tout logiciel complexe utilise des indirections, que le langage utilisé rende ça transparent ou non. Je ne vois pas en quoi ce serait de nature à faire froid dans le dos.
Si tu vois comment modifier le code pour rendre sa compréhension plus abordable pour un débutant *sans amener en même temps d'autres problèmes*, je suis persuadé que tes patches seront bienvenus.
PS : "given enough eyeballs, all bugs are shallow" on est d'accord que cette pseudo-loi est trop simple pour représenter fidèlement la réalité. Par contre laisser entendre qu'elle serait tout simplement fausse est au mieux trollesque, mais ça je pense que tu le sais très bien. ;)
Le 21/03/2024 à 12:51, Jeremie Courreges-Anglas a écrit :
Le Thu, Mar 21, 2024 at 11:16:20AM +0100, Laurent Barme a écrit :
Le 21/03/2024 à 09:31, Denis Fondras via FRsAG a écrit :
Le Wed, Mar 20, 2024 at 10:07:11PM +0100, Laurent Barme a écrit :
C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ?
J'imagine que tu veux dire OpenSSL et pas OpenSSH ?
C'est bien d'openSSH dont je parle. J'ai partagé mon expérience à ce sujet sur mon blog : https://blog.nun.tf/les-limites-de-lopen-source/ ; si tu veux bien le lire, tes remarques et commentaires sont les bienvenus.
Dire qu'un projet écrit en C est *trop* complexe parce qu'il utilise des pointeurs de fonction... nan, désolé, ça ne passe pas. Tout logiciel complexe utilise des indirections, que le langage utilisé rende ça transparent ou non. Je ne vois pas en quoi ce serait de nature à faire froid dans le dos.
Si tu vois comment modifier le code pour rendre sa compréhension plus abordable pour un débutant *sans amener en même temps d'autres problèmes*, je suis persuadé que tes patches seront bienvenus.
Alors je suppose que tu commentes : "On y découvre un style de programmation artificiellement compliqué. Par exemple : mais pourquoi diable passer par un pointeur sur une fonction laborieusement stocké en de multiples exemplaires plutôt que d'appeler tout simplement la fonction elle-même ? Le reste est à l'avenant, avec notamment un recours avide aux pointeurs, une fonctionnalité très puissante lorsqu'elle est bien employée mais une source redoutable d'erreurs."
Ce que tu traduis par "un projet écrit en C est *trop* complexe parce qu'il utilise des pointeurs de fonction".
C'est curieux cette pratique qui consiste à critiquer ce que je n'ai pas dit…
Je n'ai aucun souci avec l'utilisation des pointeurs en C /mais pourquoi diable passer par un pointeur sur une fonction laborieusement stocké en de multiples exemplaires plutôt que d'appeler tout simplement la fonction elle-même ?/
C'est à dire, si tu veux synthétiser : pourquoi rajouter une complexité inutile ?
PS : "given enough eyeballs, all bugs are shallow"
J'adore la traduction de ggl : /avec suffisamment de globes oculaires, tous les insectes sont superficiels/
on est d'accord que cette pseudo-loi est trop simple pour représenter fidèlement la réalité. Par contre laisser entendre qu'elle serait tout simplement fausse
J'ignorais cette pseudo loi et je ne laisse donc rien entendre à son propos, encore moins qu'elle serait fausse.
est au mieux trollesque, mais ça je pense que tu le sais très bien. ;)
Ha voilà, ton commentaire était en fait destiné à susciter une polémique… Ne crois-tu pas que la bande passante de FRsAG a été suffisamment saturée récemment par des propos hargneux qui n'apportent rien aux lecteurs et qu'il serait temps de revenir à des échanges plus courtois et surtout plus constructifs ?
Laurent Barme 2551@barme.fr wrote on 21/03/2024 at 14:16:51+0100:
Ne crois-tu pas que la bande passante de FRsAG a été suffisamment saturée récemment par des propos hargneux qui n'apportent rien aux lecteurs et qu'il serait temps de revenir à des échanges plus courtois et surtout plus constructifs ?
Sur ce point il y a une solution toute simple à laquelle manifestement tu n'as toujours pas pensé, vu que tu continues à répondre pour expliquer que tu as raison quand il est manifeste que c'est au mieux discutable, et au pire manifestement faux.
Le Thu, Mar 21, 2024 at 02:16:51PM +0100, Laurent Barme a écrit :
Le 21/03/2024 à 12:51, Jeremie Courreges-Anglas a écrit :
Le Thu, Mar 21, 2024 at 11:16:20AM +0100, Laurent Barme a écrit :
Le 21/03/2024 à 09:31, Denis Fondras via FRsAG a écrit :
Le Wed, Mar 20, 2024 at 10:07:11PM +0100, Laurent Barme a écrit :
C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ?
J'imagine que tu veux dire OpenSSL et pas OpenSSH ?
C'est bien d'openSSH dont je parle. J'ai partagé mon expérience à ce sujet sur mon blog : https://blog.nun.tf/les-limites-de-lopen-source/ ; si tu veux bien le lire, tes remarques et commentaires sont les bienvenus.
Dire qu'un projet écrit en C est *trop* complexe parce qu'il utilise des pointeurs de fonction... nan, désolé, ça ne passe pas. Tout logiciel complexe utilise des indirections, que le langage utilisé rende ça transparent ou non. Je ne vois pas en quoi ce serait de nature à faire froid dans le dos.
Si tu vois comment modifier le code pour rendre sa compréhension plus abordable pour un débutant *sans amener en même temps d'autres problèmes*, je suis persuadé que tes patches seront bienvenus.
Alors je suppose que tu commentes : "On y découvre un style de programmation artificiellement compliqué. Par exemple : mais pourquoi diable passer par un pointeur sur une fonction laborieusement stocké en de multiples exemplaires plutôt que d'appeler tout simplement la fonction elle-même ? Le reste est à l'avenant, avec notamment un recours avide aux pointeurs, une fonctionnalité très puissante lorsqu'elle est bien employée mais une source redoutable d'erreurs."
Ce que tu traduis par "un projet écrit en C est *trop* complexe parce qu'il utilise des pointeurs de fonction".
C'est curieux cette pratique qui consiste à critiquer ce que je n'ai pas dit…
L'épouvantail, une pratique rhétorique relativement commune. Quid de la pratique de sortir des propos polémiques pour ensuite expliquer que le message a été mal interprété ? ;)
Plus sérieusement, as-tu tenté de répondre de toi-même à ta propre question ? Si je devais essayer : c'est certainement que cette complexité supplémentaire est utile. Utiliser des pointeurs de fonction est une approche qui me semble semble commune pour implémenter un automate à état fini.
PS : "given enough eyeballs, all bugs are shallow"
J'adore la traduction de ggl : /avec suffisamment de globes oculaires, tous les insectes sont superficiels/
on est d'accord que cette pseudo-loi est trop simple pour représenter fidèlement la réalité. Par contre laisser entendre qu'elle serait tout simplement fausse
J'ignorais cette pseudo loi et je ne laisse donc rien entendre à son propos, encore moins qu'elle serait fausse.
est au mieux trollesque, mais ça je pense que tu le sais très bien. ;)
Ha voilà, ton commentaire était en fait destiné à susciter une polémique…
Le titre de ton billet de blog est "Les limites de l'open source", il se termine par (je cite) "On aboutit au résultat opposé à celui recherché par l'open source !". Plus tôt dans cet échange, tu disais "si tu veux bien le lire, tes remarques et commentaires sont les bienvenus". Si polémique il y a, je pense que nous sommes tou-te-s un peu coupables ; mais toi un peu plus que les autres. :)
Ne crois-tu pas que la bande passante de FRsAG a été suffisamment saturée récemment par des propos hargneux qui n'apportent rien aux lecteurs et qu'il serait temps de revenir à des échanges plus courtois et surtout plus constructifs ?
Euh je n'avais pas spécialement remarqué que l'ambiance était particulièrement délétère, non, mais maintenant que tu le dis... Je comprends que le mail ne laisse pas passer toutes les émotions, mais de là à qualifier mes propos de hargneux, je trouve ça très exagéré.
Ah, pardon... ça non plus tu ne l'as pas dit. ;)
/me recrache l'hameçon
Bon... dredi... Grand beau... Rien à troller sur FRnOG (MP ayant disparu des radars), on va y mettre son poil à gratter sur la très calme et normalement apaisée FRsAG...
Alors je suppose que tu commentes : "On y découvre un style de programmation artificiellement compliqué. Par exemple : mais pourquoi diable passer par un pointeur sur une fonction laborieusement stocké en de multiples exemplaires plutôt que d'appeler tout simplement la fonction elle-même ? Le reste est à l'avenant, avec notamment un recours avide aux pointeurs, une fonctionnalité très puissante lorsqu'elle est bien employée mais une source redoutable d'erreurs."
La simplicité (/= simplisme) est difficile à atteindre. Sans avoir lu le code évoqué, je vois pourtant très bien de quoi Laurent parle.
Les "styles de programmation artificiellement compliqués" sont légion, particulièrement en C, mais pas que. C'est une plaie commune. Je tombe dedans parfois aussi. Dans le cas du logiciel libre, souvent animé par des bénévoles, pas nécessairement des pros de l'ingénierie logicielle (ou utilisant un langage qui n'est pas adapté), ce code malhabile se voit.
Parce qu'il est libre est diffusé. Et on peut toujours alors le rendre plus lisible.
As-t'on idée des horreurs qui croupissent dans le code privateur ?
L'épouvantail, une pratique rhétorique relativement commune. Quid de la pratique de sortir des propos polémiques pour ensuite expliquer que le message a été mal interprété ? ;)
On se croirait sur FRnOG les jours de grands vents... On peut se mettre à plusieurs pour taper sur Laurent mais bon...
Il a son avis non orthodoxe et/ou très discutable mais bon... La réaction me semble est un tantinet excessive.
Plus sérieusement, as-tu tenté de répondre de toi-même à ta propre question ? Si je devais essayer : c'est certainement que cette complexité supplémentaire est utile. Utiliser des pointeurs de fonction est une approche qui me semble semble commune pour implémenter un automate à état fini.
Convoquer un automate pour cet argumentaire est-il juste ? Comparaison n'est pas raison, parait-il...
Globalement, les pointeurs "codés par les humains", c'est le mal absolu. Parfois, ils sont indispensables, même dans des langages plutôt conçus pour être sûrs, tels Ada. Parfois ils sont bannis (en apparence tout du moins) et on les déguise sous de la colle syntaxique zarbie.
Le titre de ton billet de blog est "Les limites de l'open source", il se termine par (je cite) "On aboutit au résultat opposé à celui recherché par l'open source !". Plus tôt dans cet échange, tu disais "si tu veux bien le lire, tes remarques et commentaires sont les bienvenus". Si polémique il y a, je pense que nous sommes tou-te-s
Tous, le pluriel est masculin en français, n'en déplaise aux wokistes et autres /abusateurs/ de langages inclusifs et piquant les yeux.
Bon, cette pique pour ambiancer, rien de bien méchant, le puriste que tu es comprendra :>
un peu coupables ; mais toi un peu plus que les autres. :)
Je propose de pendre le coupable Laurent à un chemin de câble (avec un câble réseau bas de gamme, afin que la sentence soit symbolique).
Quoique c'est grâce à un câble réseau de ce type qu'un français est devenu célèbre pour avoir reçu un Darwin Award (donc forcément à titre posthume).
comprends que le mail ne laisse pas passer toutes les émotions, mais de là à qualifier mes propos de hargneux, je trouve ça très exagéré.
Faut avouer que y'aurait comme un soupçon de roinçage assez palpable...
Bon, je te laisse me basher maintenant...
On se croirait sur FRnOG les jours de grands vents... On peut se mettre à plusieurs pour taper sur Laurent mais bon...
Il a son avis non orthodoxe et/ou très discutable mais bon... La réaction me semble est un tantinet excessive.
J’ai cru que quelqu’un avait mis en place une passerelle entre X et FRsAG…
J’ai cru que quelqu’un avait mis en place une passerelle entre X et FRsAG…
L'achat à 44 Md par IronMan a permis la diffusion les twitter files. Ça fait cher la vérité mais bon, ces temps-ci, la vérité a ses pointeurs en plein dépassement.
Que fait l'UE d'ailleurs ? N'a t-elle pas encore songé à réguler les dépassements de pointeurs, qui tuent aussi - cf la gestion de l'accélération incontrôlée des Toyotas :() Certainement un oubli du législateur qui sera corrigé.
Le Wed, Mar 20, 2024 at 10:07:11PM +0100, Laurent Barme a écrit : [...]
Pour mon premier travail salarié, j'ai eu pour mission de maintenir un programme d'affichage et de traitement d'informations financières en temps réel. Il était profondément buggé, son concepteur étant plus porté sur le fun que la rigueur. Mais parmi les innombrables bugs, il y en avait un qui n'était pas complètement de sa faute. La mémoire allouée au processus principale de ce programme enflait progressivement au point de le planter ; cela faisait désordre dans les salles de marché. Il m'a fallu un temps considérable pour trouver l'origine du problème. J'ai dû écrire une surcouche aux malloc()/free() pour tracer les fuites. Il y en avait une particulièrement inattendue sur la fonction time() qui manquait manifestement de free(). Le logiciel affichait les heures des principales places boursière du monde entier et la fonction time() était appelée plusieurs fois chaque seconde…
La fonction time(3) est censée être implémentée par l'environnement (libc) de ton programme. Cette interface n'alloue pas de mémoire censée être libérée par le programme appelant. Pas sûr de piger quand tu dis que ce n'était pas "complètement" de la faute de ton prédecesseur. Est-ce que cela veut dire que l'implémentation de time(3) dans la libc contenait un bug ?
Je garde de cette expérience une profonde aversion pour la maintenance d'un code écrit par un autre et une idée précise de la difficulté de cette tâche.
Ce qui n'est pas très précis, c'est où se situait ce bug dont tu parles. Tu sembles impliquer que c'était il y a longtemps, donc ça se comprend. Mais du coup je ne sais pas ce qu'on devrait en conclure.
Le 21/03/2024 à 13:26, Jeremie Courreges-Anglas a écrit :
Le Wed, Mar 20, 2024 at 10:07:11PM +0100, Laurent Barme a écrit : [...]
Pour mon premier travail salarié, j'ai eu pour mission de maintenir un programme d'affichage et de traitement d'informations financières en temps réel. Il était profondément buggé, son concepteur étant plus porté sur le fun que la rigueur. Mais parmi les innombrables bugs, il y en avait un qui n'était pas complètement de sa faute. La mémoire allouée au processus principale de ce programme enflait progressivement au point de le planter ; cela faisait désordre dans les salles de marché. Il m'a fallu un temps considérable pour trouver l'origine du problème. J'ai dû écrire une surcouche aux malloc()/free() pour tracer les fuites. Il y en avait une particulièrement inattendue sur la fonction time() qui manquait manifestement de free(). Le logiciel affichait les heures des principales places boursière du monde entier et la fonction time() était appelée plusieurs fois chaque seconde…
La fonction time(3) est censée être implémentée par l'environnement (libc) de ton programme. Cette interface n'alloue pas de mémoire censée être libérée par le programme appelant. Pas sûr de piger quand tu dis que ce n'était pas "complètement" de la faute de ton prédecesseur. Est-ce que cela veut dire que l'implémentation de time(3) dans la libc contenait un bug ?
C'est ça ; il y avait un bug dans la fonction.
Je garde de cette expérience une profonde aversion pour la maintenance d'un code écrit par un autre et une idée précise de la difficulté de cette tâche.
Ce qui n'est pas très précis, c'est où se situait ce bug dont tu parles. Tu sembles impliquer que c'était il y a longtemps, donc ça se comprend. Mais du coup je ne sais pas ce qu'on devrait en conclure.
C'était il y a 36 ans.
Libre à toi d'en conclure ce que tu veux (je ne comprends pas bien le sens de ta question).
( ici un sysadmin de 50 ans qui est aussi développeur C, et j en passe )
Ici même profil que toi.
Les points que j'ai retenu, ayant taffé pour la défense est que, contrairement au discours habituel d'audition d'un code source, la protection par la non diffusion est la base de la protection (chiffre, algo, etc.) et que beaucoup d'investissements sont faits pour augmenter cette non diffusion (protection contre le reverse engineering).
Inversement, la pollution d'un code source GPL peut être très subtil. Pour le chiffrement avec des algos publics, comment être certain que les vecteurs, seeds et autres tableaux de permutations sont ne sont pas "adaptés" à une attaque particulière ? Tu en parles très bien dans ta section Exception. La "viciosité" des agencs à trois ou quatre lettres est infinie.
Enfin, je jamais sous-estimer la stupidité ou la distraction de mettre en commentaire la génération pseudo-aléatoire de je ne sais plus quel seed qui avait vérolé OpenSSL ou OpenSSH, je ne sais plus...
Ces choses-là étant dites le logiciel libre (que je peux recompiler, par opposition à de l'open source inbuildable avec des binaires gentiment proposés) représente un tel progrès dans la connaissance et dans la prod que je n'imagine juste pas mon métier sans lui...
Le 21/03/2024 à 10:25, Stéphane Rivière a écrit :
Ces choses-là étant dites le logiciel libre (que je peux recompiler, par opposition à de l'open source inbuildable avec des binaires gentiment proposés) représente un tel progrès dans la connaissance et dans la prod que je n'imagine juste pas mon métier sans lui...
Tout à fait d'accord !
-
Alain Péan -
Barth DELUY -
David COURTOIS -
David Ponzone -
Denis Fondras -
Jeremie Courreges-Anglas -
Kevin Decherf -
Laurent Barme -
ml-frsag＠srv.mx -
neo futur -
Pierre Colombier -
Pierre-Elliott Bécue -
Stéphane Rivière -
Théophile Bastian -
William FERRES