[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[ml-frsag]

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 <2...@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 ?


___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: Gérer les versions de ses cafetières ?

[JM via FRsAG]

On Wed, 20 Mar 2024 12:21:50 +0100
nicolas.fr...@ecarnot.net wrote:

> Bonjour,
>
> Comme bon nombre d'entre vous, je m'efforce de garder à jour les
> versions de tout ce qui constitue notre infrastructure systèmes et
> réseaux, et je garde trace de toutes ces montées de versions de manière
> artisanale, ce qui ne facilite pas le reporting.
> En effet, le types d'éléments que j'entretiens comprends des
> applicatifs, des firmwares de matériel (switchs, routeurs, onduleurs,
> imprimantes, sondes, cartes variées...), des machines physiques ou
> virtuelles, des containers, jusqu'à certains plugins de certaines
> applications.
>
> Pour conserver trace de toutes ces actions de maintenance, je ne dispose
> pas d'un outil spécifique et je suis bien persuadé que cela doit exister
> mais mes recherches aboutissent souvent à des outils qui sont trop
> spécifiques :
> - soit trop orientés logiciel
> - soit trop orientés matériel
> - soit trop orientés gestion de maintenance physique et ticketing
>
> Et puisque la grande variété de cas ruine tout espoir d'automatisation
> (que j'assume), je suis plutôt à la recherche d'un outil simple qui
> permettrait de simplement prendre note de toute action d'upgrade, de
> consulter les versions les plus anciennes, et d'estimer le nombre
> d'actions par période.
>
> Évidemment, si quelqu'un connaît ce genre de chose en open source, qu'il
> soit bénit, mais restons ouverts d'esprit.

Bonjour,

Quels sont les logiciels que vous avez déjà examinés ? Avez-vous regardé si 
ITSM-NG
pourrait vous convenir ? (Je ne le connais pas personnellement, je l'ai juste 
dans ma
liste) https://www.itsm-ng.com/la-solution

Cordialement,
Joyce MARKOLL

--

https://linuxvillage.org
https://orditux.org


___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[neo futur]

> 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 

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Laurent Barme]

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 

[FRsAG] Re: [MISC] Mails bloqués par Free.fr depuis Tenant Office365 Microsoft.

[Seb Astien]

Postmaster.free.fr

Le mer. 20 mars 2024, 17:48, frsag--- via FRsAG  a écrit :

> Bonjour,
>
>
> Depuis plus d'une semaine, quasi plus aucun de nos mail n'arrivent chez
> free.fr depuis notre tenant Microsoft Office 365 (Au moins un centaine de
> mails quotidiens).
>
>
> Les IP de M$ sont refusées : LED=451 too many errors detected from your
> IP, depuis les IP M$ 40.107.XXX.XXX entre autre.
>
>
> Bien entendu, de notre côté, tout est correctement configuré : SPF, DKIM,
> DMARC
>
>
> Le support de Microsoft est, comme souvent, inutile et ne veux rien
> comprendre.
>
>
> Quelqu'un aurait il un contact chez Free pour voir ce qu'il est possible
> de faire pour dé-blacklister ces IP's ?
>
> Sachant que nous ne sommes certainement pas les seuls puisque les IP de
> sortie M$ sont mutualisées...
>
>
> Frédéric.
> ___
> Liste de diffusion du %(real_name)s
> http://www.frsag.org/
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[neo futur]

> 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)
*/
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Laurent Barme]

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.
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[David COURTOIS]

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 <2...@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 

[FRsAG] Audit ordinateur ecole

[Ilyass RAITI]

 
 
  
   Je me permets de poser la question suivante : 
   
   J'ai déployé une GPO dans une école qui permet d'auditer les logiciels, scripts et autres bêtises que des enfants peuvent lancer sur les machines. J'aimerais avoir votre retour sur d'autres solutions + poussées que la GPO (tableau de bord, contrôle pour chaque user, etc...) qui permet de surveiller les machines de cette école ?
   
   (Je m'excuse du mail d'avant j'ai oublié le [FRsAG] dans le sujet :/)
   
   
   Cordialement,
   Ilyass.
  
 

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Audit ordinateur ecole

[Ilyass RAITI]

 
 
  
   Je me permets de poser la question suivante : 
   
   J'ai déployé une GPO dans une école qui permet d'auditer les logiciels, scripts et autres bêtises que des enfants peuvent lancer sur les machines. J'aimerais avoir votre retour sur d'autres solutions + poussées que la GPO (tableau de bord, contrôle pour chaque user, etc...) qui permet de surveiller les machines de cette école ?
   
   Cordialement,
   Ilyass.
  
 

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] [MISC] Mails bloqués par Free.fr depuis Tenant Office365 Microsoft.

[frsag--- via FRsAG]

Bonjour,

Depuis plus d'une semaine, quasi plus aucun de nos mail n'arrivent chez 
free.fr depuis notre tenant Microsoft Office 365 (Au moins un centaine 
de mails quotidiens).


Les IP de M$ sont refusées : LED=451 too many errors detected from your 
IP, depuis les IP M$ 40.107.XXX.XXX entre autre.


Bien entendu, de notre côté, tout est correctement configuré : SPF, 
DKIM, DMARC


Le support de Microsoft est, comme souvent, inutile et ne veux rien 
comprendre.


Quelqu'un aurait il un contact chez Free pour voir ce qu'il est possible 
de faire pour dé-blacklister ces IP's ?


Sachant que nous ne sommes certainement pas les seuls puisque les IP de 
sortie M$ sont mutualisées...


Frédéric.___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Pierre-Elliott Bécue]

Hello,

Stéphane Rivière  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.
-- 
PEB


signature.asc
Description: PGP signature
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Stéphane Rivière]

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é.


--
Stéphane Rivière
Ile d'Oléron - France

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: Gérer les versions de ses cafetières ?

[Théo VARIER via FRsAG]

> Le 20 mars 2024 à 12:50, David Ponzone  a écrit :
> 
>> 
>> Le 20 mars 2024 à 12:21, nicolas.fr...@ecarnot.net a écrit :
>> 
>> Bonjour,
>> 
>> Comme bon nombre d'entre vous, je m'efforce de garder à jour les versions de 
>> tout ce qui constitue notre infrastructure systèmes et réseaux, et je garde 
>> trace de toutes ces montées de versions de manière artisanale, ce qui ne 
>> facilite pas le reporting.
>> En effet, le types d'éléments que j'entretiens comprends des applicatifs, 
>> des firmwares de matériel (switchs, routeurs, onduleurs, imprimantes, 
>> sondes, cartes variées...), des machines physiques ou virtuelles, des 
>> containers, jusqu'à certains plugins de certaines applications.
>> 
>> Pour conserver trace de toutes ces actions de maintenance, je ne dispose pas 
>> d'un outil spécifique et je suis bien persuadé que cela doit exister mais 
>> mes recherches aboutissent souvent à des outils qui sont trop spécifiques :
>> - soit trop orientés logiciel
>> - soit trop orientés matériel
>> - soit trop orientés gestion de maintenance physique et ticketing
>> 
>> Et puisque la grande variété de cas ruine tout espoir d'automatisation (que 
>> j'assume), je suis plutôt à la recherche d'un outil simple qui permettrait 
>> de simplement prendre note de toute action d'upgrade, de consulter les 
>> versions les plus anciennes, et d'estimer le nombre d'actions par période.
>> 
>> Évidemment, si quelqu'un connaît ce genre de chose en open source, qu'il 
>> soit bénit, mais restons ouverts d’esprit.
>> 
> 
> GLPI, ça le fait pas ?

+1 
ou  juste FusionInventory qui gère la partie inventaire ?
Je ne suis pas spécialiste, peut-être que d'autres pourraient s'exprimer plus 
précisément sur le sujet.

Théo


> 
> David
> 
> 
> ___
> Liste de diffusion du %(real_name)s
> http://www.frsag.org/


___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Laurent Barme]

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.
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Laurent Barme]

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 ?


___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Pierre-Elliott Bécue]

Laurent Barme <2...@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.

-- 
PEB

¹ allez, pour les jeunes, cherchez DigiNotar, et dans une moindre mesure
Comodo ou KPN.


signature.asc
Description: PGP signature
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[David Ponzone]

> Le 20 mars 2024 à 14:59, Laurent Barme <2...@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



___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: Toc toc un support de chez Gandi ?

[Pierre-Elliott Bécue]

Alarig Le Lay via FRsAG  wrote on 20/03/2024 at 09:48:08+0100:

> On Wed 13 Mar 2024 23:57:13 GMT, Pierre-Elliott Bécue wrote:
>> Kevin  wrote on 13/03/2024 at 19:51:44+0100:
>> > A l'instar des autres, je quitte peu à peu grandi… Je migre tous mes
>> > clients NDD vers Infomaniak.
>> 
>> Peut-on dire qu'on ressort Gandis de cette histoire ?
>> 
>> (oui je sors)
>
> En tous cas pas indemnes.

Oh I see where you're going at <3

-- 
PEB


signature.asc
Description: PGP signature
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Stéphane Rivière]

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é.


--
Stéphane Rivière
Ile d'Oléron - France

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Stéphane Rivière]

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.


--
Stéphane Rivière
Ile d'Oléron - France

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Laurent Barme]

Le 20/03/2024 à 14:51, David Ponzone a écrit :


Le 20 mars 2024 à 14:40, Laurent Barme <2...@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 ?
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Laurent Barme]

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/


___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[David Ponzone]

> Le 20 mars 2024 à 14:40, Laurent Barme <2...@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.

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Laurent Barme]

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.




___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: Gérer les versions de ses cafetières ?

[David Durieux]

Bonjour, 

un logiciel de gestion de CMDB & de gestion des changements devrait
répondre à ton besoin.

David

On Wed, 20 Mar 2024 12:21:50 +0100
nicolas.fr...@ecarnot.net wrote:

> Bonjour,
> 
> Comme bon nombre d'entre vous, je m'efforce de garder à jour les 
> versions de tout ce qui constitue notre infrastructure systèmes et 
> réseaux, et je garde trace de toutes ces montées de versions de
> manière artisanale, ce qui ne facilite pas le reporting.
> En effet, le types d'éléments que j'entretiens comprends des 
> applicatifs, des firmwares de matériel (switchs, routeurs, onduleurs, 
> imprimantes, sondes, cartes variées...), des machines physiques ou 
> virtuelles, des containers, jusqu'à certains plugins de certaines 
> applications.
> 
> Pour conserver trace de toutes ces actions de maintenance, je ne
> dispose pas d'un outil spécifique et je suis bien persuadé que cela
> doit exister mais mes recherches aboutissent souvent à des outils qui
> sont trop spécifiques :
> - soit trop orientés logiciel
> - soit trop orientés matériel
> - soit trop orientés gestion de maintenance physique et ticketing
> 
> Et puisque la grande variété de cas ruine tout espoir
> d'automatisation (que j'assume), je suis plutôt à la recherche d'un
> outil simple qui permettrait de simplement prendre note de toute
> action d'upgrade, de consulter les versions les plus anciennes, et
> d'estimer le nombre d'actions par période.
> 
> Évidemment, si quelqu'un connaît ce genre de chose en open source,
> qu'il soit bénit, mais restons ouverts d'esprit.
> 
> Merci pour vos suggestions.
> 

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: Gérer les versions de ses cafetières ?

[David Ponzone]

> Le 20 mars 2024 à 12:21, nicolas.fr...@ecarnot.net a écrit :
> 
> Bonjour,
> 
> Comme bon nombre d'entre vous, je m'efforce de garder à jour les versions de 
> tout ce qui constitue notre infrastructure systèmes et réseaux, et je garde 
> trace de toutes ces montées de versions de manière artisanale, ce qui ne 
> facilite pas le reporting.
> En effet, le types d'éléments que j'entretiens comprends des applicatifs, des 
> firmwares de matériel (switchs, routeurs, onduleurs, imprimantes, sondes, 
> cartes variées...), des machines physiques ou virtuelles, des containers, 
> jusqu'à certains plugins de certaines applications.
> 
> Pour conserver trace de toutes ces actions de maintenance, je ne dispose pas 
> d'un outil spécifique et je suis bien persuadé que cela doit exister mais mes 
> recherches aboutissent souvent à des outils qui sont trop spécifiques :
> - soit trop orientés logiciel
> - soit trop orientés matériel
> - soit trop orientés gestion de maintenance physique et ticketing
> 
> Et puisque la grande variété de cas ruine tout espoir d'automatisation (que 
> j'assume), je suis plutôt à la recherche d'un outil simple qui permettrait de 
> simplement prendre note de toute action d'upgrade, de consulter les versions 
> les plus anciennes, et d'estimer le nombre d'actions par période.
> 
> Évidemment, si quelqu'un connaît ce genre de chose en open source, qu'il soit 
> bénit, mais restons ouverts d’esprit.
> 

GLPI, ça le fait pas ?

David


___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Gérer les versions de ses cafetières ?

[nicolas . frsag]

Bonjour,

Comme bon nombre d'entre vous, je m'efforce de garder à jour les 
versions de tout ce qui constitue notre infrastructure systèmes et 
réseaux, et je garde trace de toutes ces montées de versions de manière 
artisanale, ce qui ne facilite pas le reporting.
En effet, le types d'éléments que j'entretiens comprends des 
applicatifs, des firmwares de matériel (switchs, routeurs, onduleurs, 
imprimantes, sondes, cartes variées...), des machines physiques ou 
virtuelles, des containers, jusqu'à certains plugins de certaines 
applications.


Pour conserver trace de toutes ces actions de maintenance, je ne dispose 
pas d'un outil spécifique et je suis bien persuadé que cela doit exister 
mais mes recherches aboutissent souvent à des outils qui sont trop 
spécifiques :

- soit trop orientés logiciel
- soit trop orientés matériel
- soit trop orientés gestion de maintenance physique et ticketing

Et puisque la grande variété de cas ruine tout espoir d'automatisation 
(que j'assume), je suis plutôt à la recherche d'un outil simple qui 
permettrait de simplement prendre note de toute action d'upgrade, de 
consulter les versions les plus anciennes, et d'estimer le nombre 
d'actions par période.


Évidemment, si quelqu'un connaît ce genre de chose en open source, qu'il 
soit bénit, mais restons ouverts d'esprit.


Merci pour vos suggestions.

--
Nicolas
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Théophile Bastian]

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 !

[1] https://github.com/dehydrated-io/dehydrated
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Kevin Decherf]

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/

-- 
Kevin Decherf - @Kdecherf
GPG 0x108ABD75A81E6E2F
https://kdecherf.com
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Stéphane Rivière]

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.


--
Stéphane Rivière
Ile d'Oléron - France

___
Liste de diffusion du %(real_name)s
http://www.frsag.org/

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Barth DELUY]

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 <2...@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 

[FRsAG] Re: La mise à jour automatique des certificats LE est un cheval de Troie.

[Pierre Colombier via FRsAG]

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 <2...@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 

[FRsAG] Re: Toc toc un support de chez Gandi ?

[Alarig Le Lay via FRsAG]

On Wed 13 Mar 2024 23:57:13 GMT, Pierre-Elliott Bécue wrote:
> Kevin  wrote on 13/03/2024 at 19:51:44+0100:
> > A l'instar des autres, je quitte peu à peu grandi… Je migre tous mes
> > clients NDD vers Infomaniak.
> 
> Peut-on dire qu'on ressort Gandis de cette histoire ?
> 
> (oui je sors)

En tous cas pas indemnes.

-- 
Alarig
___
Liste de diffusion du %(real_name)s
http://www.frsag.org/