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