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/