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/