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 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/
