En ces temps de PRISM/NSA et autres grandes oreilles, et aussi parce que c'est techniquement intéressant, nous essayons d'avoir sur LinuxFr.org des configurations pertinentes au niveau sécurité (pour nos serveurs et pour vos données genre adresses de courriel). Vous trouverez ci-dessous un petit statut de l'existant et les pistes d'améliorations, et nous sommes bien entendu ouverts à vos propositions sur le sujet.
Au sommaire, d'abord un descriptif de ce qui est commun à nos différents serveurs, puis les spécificités de chacun et quelques questionnements pour ouvrir le sujet.
Services communs à nos différents serveurs
- sshd : configuration standard. TODO : limiter les algorithmes et si oui comment/lesquels ?
- postfix : TLS client/serveur clé 2048 bits, avec limitation sur les algorithmes utilisés, avec autorité de confiance CaCert. La configuration est issue de la conférence de B. Sonntag sur TLS pour confs.fr (ça nous a permis de remonter deux typos sur la configuration fournie). Tous nos postfix passent par celui du container main (qui rajoute du DKIM 2048 bits, SPF, policyd v2, greylisting, RBL, ralentisseur d'envoi vers Orange et Free, etc.).
Autre point commun, la mise à jour des paquets Debian/Ubuntu. TODO : utiliser debsig-verify pour toujours vérifier les signatures ? Quid des paquets produits par nos admins notamment pour Ruby et ElasticSearch ?
Et dernier point commun : le DNS. Actuellement nous n'utilisons pas (encore) DNSSEC. Cela semble représenter une vraie contrainte de gestion régulière (ce tutoriel suggère une mise à jour mensuelle des clés), ce qui est toujours délicat/non fiable avec des bénévoles. Ceci dit, c'est un pré-requis pour DANE.
Spécificités
serveurs physiques zobe / gruik :
- sauvegarde via duplicity+ssh+rsync+gpg depuis gruik vers zobe (une clé 1024 bits (TODO à mettre à jour) et deux 4096 bits) ;
- containers LXC : TODO renforcer la sécurité en suivant le LxcSecurity d'Ubuntu, notamment le lxc.cap.drop ?
container LXC bla (outils de communication) :
- serveur web nginx (accès en HTTP ou HTTPS, TLS, note de A hors CaCert sur SSLlabs avec 95% en support des protocoles, 80% en échange de clés et 90% en niveau de chiffrement avec SSL Report v1.6.23), TODO : activer Content Security Policy) ;
- éditeur collaboratif temps réel etherpad, accès en http ou https, avec authentification basique ; TODO : avoir un cookie en https uniquement ? Pouvoir utiliser les identifiants de la prod ?
container LXC prod (site web de production) :
- nginx (TLS, note de A hors CaCert comme précédemment) ;
- daemons LinuxFr board, epub, img et serveur applicatif unicorn Ruby on Rails accessibles http/https ; TODO : forcer les accès en https pour les comptes avec droits ?
- daemon LinuxFr share (accès HTTPS vers twitter, KO vers identi.ca depuis la migration pump.io, rien vers Google+ actuellement, rien de direct vers Facebook) ;
- client git via ssh ;
- récupération des gems Ruby ; TODO : vérification des signatures de gems ?
container LXC alpha (site web de développement) :
- comme prod mais sans le share.
container LXC main :
- serveur web httpd (HTTPS uniquement, note de A hors CaCert) ;
- serveur de listes de diffusion sympa avec interface web en https uniquement ; TODO : activer le filtre des messages entrants avec DKIM (il n'est pas nécessaire pour les messages sortant car le postfix est local et utilise déjà DKIM) ?
- dépôt de données associatives svn (accès via ssh) ;
- envoi de la lettre quotidienne par rss2email.
serveur externe conference (comptes et salons XMPP) :
- TODO : à héberger sur les serveurs de l'association, configuration à revoir niveau sécurité (voir journal, note de B sur xmpp.net).
Derniers points
- il reste toujours une entrée à traiter sur l'ajout d'une empreinte OpenPGP sur les comptes utilisateur, il ne restera plus qu'à rendre GnuPG plus facilement utilisable par tout un chacun…
- on note une certaine complexité de configuration des serveurs de courriel (TLS/DKIM/antitrucs divers/RBL/SPF/…) ou de TLS en général (algorithmes et versions à refuser) et on ne peut que regretter que ces options ne soient pas plus prises en compte par les scripts de la distribution ;
- à cette complexité et à la variété des connaissances requises viennent s'ajouter de plus en plus des contraintes régulières comme les mises à jour de sécurité (partie « facile ») ou comme avec DNSSEC qui paraît bien contraignant. Cela questionne sur les difficultés que vont rencontrer les futurs nouveaux petits acteurs (auto-hébergement, serveur d'une association, etc.), qui pourraient les jeter dans les bras des gros acteurs du gratuit ou de sociétés de service payantes, en limitant fortement les possibilités de bidouiller chez soi.
Aller plus loin
- DLFP : Retour d'expérience sécurité sur 11 ans de LinuxFr.org (2009) (458 clics)
- Confs.fr : SSL - TLS Histoire, fonctionnement Sécurité et failles par B. Sonntag (319 clics)
- DLFP : Héberger son courriel (518 clics)
- DLFP : Gérer plusieurs services de façon transparente (192 clics)
- DLFP : Certificat SSL/TLS pour serveur web, HTTPS et problèmes associés (351 clics)
# DNSSec
Posté par Sébastien Koechlin . Évalué à 7.
Si DNSSEC améliore bien la sécurité, la contrepartie c'est qu'en cas de gag, on a vite fait de rendre toute la zone indisponible, parfois pour une semaine.
[^] # Re: DNSSec
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Oui, et ça arrive même à des gens sérieux et compétents, cf DNSSEC administration likely cause of .gov outage ou DNSSEC glitch causes .gov sites to become inaccessible. De mémoire, S. Bortzmeyer l'évoque dans sa conférence confs.fr sur le DNS.
[^] # Re: DNSSec
Posté par bubar🦥 (Mastodon) . Évalué à 6. Dernière modification le 25 novembre 2013 à 18:03.
Parmi conseils prodigués par Mr Bortzmeyer lors de ses conférences, il recommande de mettre en place un serveur de test (ayant dnssec) sur une période de 6 mois. 6 mois /o\
Parmi les interrogations légitimes face à dnssec, à laquelle il n'y a pas de réponse, il reste l'abandon des politiques de coupures de flux au delà d'une certaine taille de paquet, dnssec demande de gros paquet, et du coup facilite le dns2tcp. Dnssec c'est un peu le haut débit du dns2tcp…
DNSSEC me semble (humblement, hein) un "yeux plus gros que le ventre" : améliorons d'abord le fonctionnement des DNS actuels, et des équipements autour, avant de s'attaquer à un tel morceau.
[^] # Re: DNSSec
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
Je ne comprends pas l'allusion à dns2tcp (c'est quoi ? juste un tunnel IP sur DNS ?) Il y a encore des gens compétents (pas des certifiés Cisco) pour limiter la taille des paquets DNS à 512 octets ???
[^] # Re: DNSSec
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
C'est vrai que seulement deux serveurs de noms pour linuxfr.org, tous les deux chez le même opérateur, ça fait un peu léger. Je suis sûr qu'on trouverait des secondaires volontaires dans la communauté (je suis volontaire, par exemple).
[^] # Re: DNSSec
Posté par doktoil makresh . Évalué à 3.
Je me propose également en tant que DNS secondaire gracieusement bien entendu…
# sshd : configuration standard.
Posté par Nono (site web personnel) . Évalué à 3.
Qu'entendez-vous par "sshd : configuration standard."
Port 22, algo par défaut, pas de système de clé passwordless, pas de limitation d'ip ou d'utilisateur système ?!
Autre chose, je n'ai rien vu concernant du firewalling ?!
[^] # Re: sshd : configuration standard.
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
# En parlant de données utilisateur ...
Posté par pol_w . Évalué à 2.
Au fait, rien à voir (ou presque), mais concernant les données, existe-t-il une API ou un/des dump(s) téléchargeable(s) de la base de données LinuxFr.org? Un genre d'initiative opendata, qui permettrait de savoir non seulement quel est le jour le plus pertinent pour collecter un max de commentaires sur son poste, mais potentiellement plein d'autres choses (quelle heure exacte de la journée)?
[^] # Re: En parlant de données utilisateur ...
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Il existe une API Oauth2 pour les développeurs.
[^] # Re: En parlant de données utilisateur ...
Posté par pol_w . Évalué à 3.
En fait je ne parlai pas tant d'entreprendre des actions au nom d'un utilisateur que d'avoir accès à la base de données des postes.
Quelque chose dans l'esprit de
Dans l'absolu il est déjà possible de "crawler" le site et de télécharger tous les postes/journaux et tous les commentaires associés de manière anonyme. Mais c'est une pratique qui s'apparente un peu au viol d'un site (on prend tout ce qu'il a à offrir de manière brute et généralement sans consentement).
A savoir que si le site consent ouvertement à se faire "piller" alors il n'y a pas de problème, mais ce n'est généralement pas le cas, les sites ne sont pas prévus pour ça. Aux dernières nouvelles la bande passante reste payante et on parle d'une activité très consommatrice de bande passante.
J'imagine qu'il est plus simple pour LinuxFr soit de proposer une API pour télécharger les données soit de mettre à disposition un fichier qui contient déjà toutes les données. Cela permet de mieux contrôler la bande passante du site en offrant aux applications ou au curieux de passage une vue sur toutes les données.
Ca peut se faire assez simplement en mettant simplement les données à disposition sur un autre serveur.
[^] # Re: En parlant de données utilisateur ...
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
C'est un débat commencé à divers endroits. Dans le suivi par exemple. J'ai un doute sur le « plus simple » entre « ne rien faire par choix ou fainéantise/procrastination » et « anonymiser des données de manière fiable et durable malgré les évolutions à venir » par contre. Il faut aussi tenir compte des licences sur les contenus (en particulier ceux qui ne sont pas souss CC By-Sa), bien filtrer les contenus/commentaires non publics, du fait qu'il n'a pas été signalé à nos utilisateurs que les données seraient fournies à n'importe qui pour n'importe quel usage, etc. Ça mérite d'être bien réfléchi si on le fait en tout cas ; surtout qu'on a toujours plus de demandes que d'aide fournie.
[^] # Re: En parlant de données utilisateur ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Tu plaisantes ? C'est la base même du web : tout est disponible, et indexable à volonté. Et les sites sont conçu pour faciliter un tel usage, en indiquant à de tels robots comment exploiter au mieux la ressource.
Comment crois-tu que les moteurs de recherche fonctionnent autrement ?
Avec un mysqldump ? Pourquoi pas un accès en lecture au serveur SQL tant qu'on y est ?
# HTTPS
Posté par cluxter . Évalué à -5.
Pourquoi n'a-t-on pas de HTTPS sur LinuxFr.org ?
[^] # Re: HTTPS
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
euh, si ! T'as même un petit cadenas en dessous du logo qui est ouvert ou fermé selon que tu utilises ou pas l'accès https.
[^] # Re: HTTPS
Posté par nud . Évalué à 3.
Par contre dans quelle mesure ne serait-il pas pertinent de complètement désactiver l'accès non-https ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: HTTPS
Posté par ariasuni . Évalué à 2.
C’est surtout que ça peut faire fuir de potentiels nouveaux visiteurs. Ou alors on peut voir ça comme un filtre. :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: HTTPS
Posté par rakoo (site web personnel) . Évalué à 3.
Je pense que HTTPS est la surtout pour protéger les mots de passe qui se baladent sur internet. Si quelqu'un ne fait que lire le contenu anonymement, il n'a pas de raison d'utiliser HTTPS.
[^] # Re: HTTPS
Posté par oao . Évalué à 5.
HTTPS permet également de cacher à des tierces parties (FAI, NSA, …) la page exacte que l'on consulte.
[^] # Re: HTTPS
Posté par dinomasque . Évalué à 3.
HTTPS permet aussi d'être sur de l'auteur d'une page web.
BeOS le faisait il y a 20 ans !
[^] # Re: HTTPS
Posté par octane . Évalué à 2.
Même pas toujours. Il y a des démos ou en connaissant seulement le volume de données échangées et le site distant on est capable de savoir ce que tu consultes. Ca avait été fait avec wikipedia et maps.google.com il me semble.
[^] # Re: HTTPS
Posté par Elfir3 . Évalué à 2. Dernière modification le 28 novembre 2013 à 14:25.
Bah, avec le nombre de bêtises lachées à la minute dans les commentaires (oui je m'auto-référence), ça risque d'être relativement difficile quand même.
En générant aléatoirement un du bruit sur chaque page, ça résoudrait pas le problème ?
[^] # Re: HTTPS
Posté par ariasuni . Évalué à 2.
Ça me fait penser à un module Firefox (dont j’ai oublié le nom) qui génère pleins de fausses requêtes chez Google pour «dissimuler» les nôtres.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: HTTPS
Posté par nud . Évalué à 3.
On pourrait alors "forcer" le HTTPS uniquement à partir du moment où la moule est loguée le nouveau moule-to-be s'enregistre. De ce fait les nouveaux visiteurs ne sont pas effrayés par l'éventuelle page d'erreur de $navigateur lors d'un surf anonyme. N'est-ce pas ce que google fait par exemple ?
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Actuellement, si tu te logues en HTTPS, tu restes en HTTPS. Par contre si tu te logues en HTTP, ça dépend des URL que tu tapes ou sur lesquelles tu cliques.
[^] # Re: HTTPS
Posté par arthurr (site web personnel) . Évalué à 2.
https://linuxfr.org/
[^] # Re: HTTPS
Posté par _jordan_ . Évalué à 2.
Petit complément si tu vois une alerte dans ton navigateur : http://linuxfr.org/aide#aide-certificatssl
En plus, ça te permettra d'accéder aux images en https.
[^] # Re: HTTPS
Posté par hermenegilde . Évalué à 10.
Il serait bien de dire pourquoi le certificat CACert n'est pas inclus dans Mozilla: http://wiki.cacert.org/InclusionStatus et https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158 . L'histoire a maintenant une dizaine d'année.
Au passage, d'autres boites comme http://www.startssl.com/ permettent d'avoir des certificats gratuits, dont l'autorité est reconnue pas Mozilla et les autres. Pourquoi continuer à rester sur CACert ?
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
ça tombe bien c'est l'entrée suivante dans l'aide. Cf http://linuxfr.org/aide#aide-autrecertificatssl
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Qui connaît une autre « autorité de certification basée sur une communauté (community driven non-Profit Certificate Authority), qui propose à la fois du centralisé et du décentralisé (réseau de confiance), qui publie son code sous licence libre » ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: HTTPS
Posté par claudex . Évalué à 1.
Une url et 2 clics, c'est très difficile ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: HTTPS
Posté par claudex . Évalué à 3.
Je ne parlais d'éviter le warning mais d'ajouter le certificat root CACert de manière à ne pas avoir le message d'erreur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 26 novembre 2013 à 14:12.
Tu veux parler du certificat que tu ne peux pas récupérer en HTTPS (ou en ayant validé le site après un gros warning parce que le site pour récupérer le certificat est signé par le certificat que tu essayes de récupérer)?
Tu veux parler d'un certificat racine dont les propriétaires ne souhaitent pas se faire auditer mais on devrait accepter tous leurs sites comme ça?
On parle vraiment de sécurité la?
PS : je récupère Firefox à partir d'une install clean de Windows, via IE sur le site https://www.mozilla.org : la chaine sécurité est alors bonne. Pour LinuxFr, je n'ai pas encore trouvé de moyen d'avoir une chaine de sécurité correcte.
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 1.
Pourtant tu en as déjà eu une au moins. Cf https://linuxfr.org/users/necua6nahs/journaux/que-r%C3%A9pondre-%C3%A0-%C3%A7a#comment-1242690
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 4.
tu veux parler de la clé PGP?
C'est bête, mais pour accéder à ta page avec la clé PGP (qui est sur le site A), j'ai besoin d'avoir confiance dans le site A, hors le besoin de la clé PGP est parce que l'accès au site A n'est pas sécurisé (donc pas de confiance dans le site A).
Il faudrait que la clé soit sur un site qui est dans la chaine de confiance de la personne qui tente d'accéder au site, ce qui n'est pas le cas (sans compter la complexité, j'ai aucune idée de comment on utilisé cette clé, donc bref c'est inutilisable en l'état).
Ca tourne toujours en boucle cette histoire avec une chaine de sécurité toujours défaillante… Pas terrible pour des gens parlant ensuite de sécurité.
PS : d'ailleurs, tu noteras qu'on continue toujours à tourner en boucle, j'ai un beau score négatif sur le message auquel tu réponds (celui du lien).
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 26 novembre 2013 à 20:47.
A noter : LinuxFr n'est pas le seul avec une chaine défaillante.
Quand j'achète une machine, je l'achète dans un endroit très neutre (un magasin, physique ou en ligne ça reste pas chez moi, alors qu'ensuite c'est chez moi, plus facile à viser), donc j'ai (pas mal) confiance. ensuite pour récupérer un linux à partir de l'OS en place (quel qu'il soit, y compris avec un certificat CACert) :
* CentOS par exemple, HTTPS ok (chaine de confiance) pour la premère page, puis pour télécharger bam HTTP chaine rompue. On pourrait se consoler en chopant un hash de l'ISO, mais le SHA-1 (qui a quelques collision connues, mais bon admettons) est dans le "annonce" qui se situe sur lists.centos.org, innaccessible en HTTPS (donc chaine de confiance morte)
* Fedora est disponible aussi en HTTPS, mais le lien de download est en… HTTP. chaine de confiance rompue. Fedora est sauvée car le hash (SHA-2, c'est mieux que CentOS) est accéssible en HTTPS, mais il reste une étape manuelle (après le téléchargement, il faut faire un check manuel du fichier) à faire pour être sécurisé
* Debian, debian.org est carrément pas accessible en HTTPS.
* Ubuntu copie Debian, pas de HTTPS.
* OpenSuSE, www.opensuse.org (mais pas opensuse.org, hum) est accessible en HTTPS mais le "get it" redirige vers software.opensuse.org en HTTP, il faut forcer le HTTPS (dommage, une manip manuelle…) mais de toutes manière le lien de download passe en HTTP. Encore sauvé par la signature PGP (sur la même page qu'on a manuelle forcé en HTTPS) ou SHA-2 (mais la il faut encore faire une manip manuelle supplémentaire pour passer le lien de HTTP en HTTPS).
Linux est peut-être sécurisé, mais pour récupérer une distro de manière sécurisée, c'est galère… Très bizarre que des admins qui sont souvent à cheval sur la sécurité font et acceptent ce genre de chaine non sécurisée. Faut avoir confiance en son réseau, de chez soit vers le serveur de download (géré par des personnes pas trop à cheval sur la sécurité) en passant par tous les intermédiaires…
[^] # Re: HTTPS
Posté par rakoo (site web personnel) . Évalué à 2.
Ton commentaire me fait doublement peur:
Bittorrent a l'avantage d'inclure une vérification, donc si le
.torrent(voire même lemagnet) est fiable, l'archive est fiable. Les vraies distributions comme archlinux (en HTTPS!), linux mint, slackware, elementary os proposent toutes un .torrent.Et puis là je me suis dit qu'il fallait bien un client bittorrent quelque part, si possible libre et pas trop vieux. Et bien de toute la liste wikipedia, il n'y en a qu'un seul accessible en HTTPS: tribler. Pour un maniaque de la sécurité, la situation est clairement pas folichonne.
Tiens, d'ailleurs, même OpenBSD, le géant de la sécurité, n'est pas accessible en HTTPS …
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 2.
Il y en a avec du bittorrent dans mes exemples, mais avec le même problème pour avoir le lien (tu ne peux avoir aucune confiance dans le lien fourni si la page n'est pas un HTTPS), et surtout c'est pas lui ui est mis en avant la plupart du temps.
Mais ça s'arrête vite : les liens de download direct sont en HTTP (MD5, SHA1, PGP pour vérifier en HTTPS donc on peut vérifier manuellement), donc pas bien mieux que les autres (Fedora a SHA-2, c'est mieux que MD5 ou SHA-1 qui ont des collisions!)
Reste Bittorrent (qui est mis en avant).
Pas de HTTPS donc je peux pas avoir le lien BitTorrent de manière fiable.
HTTPS foireux (akamai??? J'ai peur)
pas de HTTPS
C'est maniaque de vouloir du HTTPS? Euh… Quand on voit qu'il y en a qui demandent aux grands du web" de mettre HTTPS par défaut, qu'il ya des HTTPS everywhere, qu'il y en a qui voudraient refaire le monde Internet et tout chiffrer par défaut, il faudrait déjà sécuriser l'existant (et la, je ne parle même pas d'ignorer CACert qui n'ose pas ce faire auditer).
hop, je rajoute un exemple de sécurité bizarre : https://www.bortzmeyer.org/ietf-securite-espionnage-bis.html (je comprend pas tout : ok, admettons le certificat auto-signé qui ne m'aide pas du tout dans la chaine de confiance, mais le mauvais CN? Pour une personne qui parle de sécurité assez souvent, je ne comprend pas que je ne puisse pas accéder à son blog de manière sécurisée)
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Les distributions utilisent des sommes de contrôle et des signatures GPG (au passage CaCert et sûrement d'autres autorités signent les clés GPG aussi), notamment parce qu'ils gèrent la diffusion via HTTP/FTP/CD/divers moyens pour lesquels les certificats x509 ne sont pas forcément la solution ou parce qu'ils gèrent des miroirs HTTP sur divers domaines hors de leur contrôle.
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 27 novembre 2013 à 10:37.
Relit, tu verras qu'il y a un soucis dans la chaine de sécurité pour pas mal de distros.
en pratique, tu te retrouve avec un test pour vérifier qu'un download s'est bien passé, pas une confiance que tu as le bon download (sans MITM). Croire que la somme de contrôle récupérée sur un site non sécurisé te sécurise le download, hum hum…
Ma critique est justement que HTTP devrait être moins présent et remplacé par HTTP. AES-NI est notre ami pour les perfs (toujours "pire" que HTTP, mais on veut de la sécurité ou pas).
On peut devoir proposer des canaux non sécurisés pour des raisons historique, ça n'interdit pas de proposer des canaux sécurisés. Le problème est que pour pas mal de distros, il n'y a rien pour vérifier l'intégrité du download (juste que le download s'est bien passé même si c'est le MITM qui te donne le fichier, tu es content de vérifier que le MITM t'a filé un fichier correctement téléchargé).
Ou alors, explique-moi où je ne comprend pas que la chaine de sécurité est bonne alors que je vois qu'elle n'est pas bonne.
Prenons par exemple CentOS (ou le SHA-1 est pas disponible en HTTPS) et son download en HTTP, même manuellement ; comment fais-tu pour te prémunir d'un MITM? Moi je ne sais pas faire.
De la même manière, explique-moi pour PGP (je connais beaucoup moins), comment une signature que je récupère de manière non sécurisée (donc falsifiable) me permettra de vérifier que le download est celui voulu et non pas du MITM.
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 1.
Pour Debian par exemple :
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 4.
tes liens sont innaccessibles en chaine sécurisée…
Sans compter qu'il faut déjà Debian par exempel dans le premier lien : "comment mettre à jour et à niveau un système Debian GNU/Linux en sécurité", donc il faut déjà la chose chez soit (comment en sécurisé?), et je connais pas vraiment beaucoup de machine avec debian pré-installée.
tu me donnes des brides de sécurité, tu ne me donnes toujours pas une façon claire d'avoir une version sans MITM possible d'une distro sur le net, avec toute la chaine en sécurisé. Et la sécurité d'une chaine dépend de son chainon le moins sûr.
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 0. Dernière modification le 27 novembre 2013 à 11:32.
Tu as la même doc signée-GPG si tu veux via le paquet Debian harden-doc par exemple (et tu n'as pas besoin d'avoir une Debian pour le vérifier, juste de GPG), donc dans une chaîne de confiance à partir de Debian.
[^] # Re: HTTPS
Posté par barmic . Évalué à 3.
Le premier liens montre dans les archives des mailing-liste Debian (archives accessibles en https) que les figerprint sont transmises par mail signé via pgp (après la chaîne de confiance PGP n'a rien avoir avec SSL/X.509).
Au passage le sacro-saint SSL ne semble plus l'être tant que ça (il faut voir quels paramètres exactes sont utilisés et refuser les AC qui seraient succeptibles de fournir un mauvais certificat soit par incompétence, soit par appât du gain, soit par obligation légale). D'après Snowden PGP est encore très sûr, même si oui c'est plus compliqué à utiliser et il faut comprendre comment y faire confiance.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTPS
Posté par jyes . Évalué à 4.
GPG ce n’est pas juste un hash MD5. Ça ne sert pas qu’à vérifier que le téléchargement s’est bien passé, tu peux aussi évaluer ta confiance en la donnée que tu as récupérée. De fait, les signatures GPG des paquets des distribs te fournissent une bien meilleure confiance que celle que peut fournir une autorité de certification.
Note que dans le manuel Debian, la commande indiquée fait télécharger la clé en HTTP et demande à l’utilisateur de valider lui-même si la chaîne de confiance lui inspire réellement confiance. Tu peux utiliser le HTTPS pour obtenir la clé, mais le certificat utilisé est fourni par l’autorité de certification Debian (ca.debian.org) qui ne fait sûrement pas partie des tiennes.
Tu as donc fermé la boucle, il faut que le système dont tu disposes à l’instant t soit capable de vérifier l’authenticité du système que tu veux installer à t + 1. Si tu as une Debian à ta portée, c’est simple. Tu voudrais pouvoir faire confiance à ton Windows acheté en magasin, mais il n’y a pas de raison à cela. Dans ce cas achète une Debian en ligne et tu auras la même confiance que celle que tu aurais en ton CD de Windows.
[^] # Re: HTTPS
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
L'accès à www.bortzmeyer.org en HTTPS est sur mon TODO. Le principal problème est la pénurie d'adresses IPv4. J'ai peu d'adresses et le port 443 est déjà pris par autre chose.
[^] # Re: HTTPS
Posté par Annah C. Hue (site web personnel) . Évalué à 1.
Et avec des virtualhosts et SNI y'a pas moyen de mettre plusieurs sites https sur une seule IP ?
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
[^] # Re: HTTPS
Posté par claudex . Évalué à 4.
Il n'a pas dit que c'était pris par du HTTPS.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HTTPS
Posté par gouttegd . Évalué à 2.
Si.
En fait, le support de SNI par le client n’est même pas nécessaire, si l’on accepte que les virtual hosts partagent le même certificat et la même clef privée, ce qui est acceptable dans certains cas.¹ Il suffit de lister le nom de tous les virtual hosts dans le champ subjectAltName du certificat.
¹ Ça l’est évidemment beaucoup moins si les différents virtual hosts concernent des sites n’ayant absolument aucun rapport entre eux (comme dans un hébergement mutualisé par exemple).
[^] # Re: HTTPS
Posté par Antoine . Évalué à 3.
Faut aussi trouver une autorité de certification qui accepte de signer un tel certificat (pour pas trop cher).
[^] # Re: HTTPS
Posté par Buf (Mastodon) . Évalué à 1.
Si tous les virtual hosts sont dans le même domaine, ça marche aussi avec un certificat wildcard (par exemle, avec un certificat pour *.example.com, ça marchera pour site1.example.com, site2.example.com, etc.)
[^] # Re: HTTPS
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
Si, mais cela ne marche pas si on veut TLS et d'autres protocoles (en l'occurrence SSH, car plein de réseaux ne laissent d'accès que via le port 443).
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
sslh ? Cf http://linuxfr.org/news/sslh%C2%A0110-la-b%C3%AAte-noire-des-censeurs
[^] # Le principal problème est la pénurie d'adresses IPv4.
Posté par Zenitram (site web personnel) . Évalué à 3.
Apparté encore plus HS
C'est truc que j'ai du mal à suivre : on parle depuis des années de pénurie d'adresses IPv4, et encore ce mois-ci j'ai commandé 4 VPS à pas cher, et j'ai eu 4 @IPv4, et ce au 4 coin de la planète. Je peux louer de l'IPv4 en plus a 1€/mois/@IP, ou du /27 (pas à moi certes, mais j'ai des adresses) à 32€/mois, et le truc à la mode est de l'iP failover (vas-y je te rajoute des IP comme ça) soit un prix complètement dérisoire pour un truc sensé être rare. Alors j'imagine que tu as un bloc à toi et ne veut pas trop t'en séparer, mais en tant que loueur d'adresse IPv4 de base (pas de blocs à soit-même et c'est un domaine que je ne connais pas du tout), le fait qu'on me dit "attention ça va péter" et "on va plus avoir d'adresse IP dans pas longtemps" et "la je peux pas, j'ai plus d'adresses IPv4 libres" depuis des années me laisse perplexe.
quelqu'un peut-il m'expliquer pourquoi je peux avoir des adresses IPv4 comme je veux et que d'autres sont "en pénurie"? Quelle est la différence entre ceux qui en ont et ceux qui en n'ont pas?
[^] # Re: Le principal problème est la pénurie d'adresses IPv4.
Posté par barmic . Évalué à 4.
Les pays qui se sont mis à internet dans les années 80 et les autres ? Ils semble par exemple que nos FAIs français aient de quoi fournir des adresses IPv4 pour 3 fois la France. Certaines compagnies ont leur propore /8 et sont donc techniquement capable de rendre toutes leurs machines directement accessibles sur internet en IPv4.
Je pense qu'il faut voir en Chine, en Inde ou autre pour voir des pénuieries (là où tu as du nat444).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le principal problème est la pénurie d'adresses IPv4.
Posté par Zenitram (site web personnel) . Évalué à 4.
L'argument est recevable pour les pays "qui ne sont pas mis à Internet dans les années 80" et la je comprend complètement le problème, mais :
nslookup www.bortzmeyer.org
(…)204.62.14.153
http://www.maxmind.com/fr/geoip_demo sur 204.62.14.153 : Code de pays = US (New Jersey).
Les US ne sont pas mis à Internet dans les années 80? ;-)
Après, vu ce qu'on perd comme adresses IP pour le routage, vu le nombre de serveurs VPS de partout, les VPN, les IP failover, ça doit pas être si large que ça.
[^] # Re: Le principal problème est la pénurie d'adresses IPv4.
Posté par eingousef . Évalué à 0.
Même icitte on est en pénurie. J'ai trois machines (deux ordinateurs et un routeur) et je n'ai qu'une seule ipv4. Ca ne choque pas parce qu'on considère que une ip par abonnement c'est la norme mais y'a pas de raison.
Et sinon j'ai plein de nipévaissices-euh nananèreuh \o/
*splash!*
[^] # Re: Le principal problème est la pénurie d'adresses IPv4.
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu fuis le cas dans lequel je pose la question (à moins que son serveur soit dans son logement, mais je doute…)
De plus, tu peux très bien avoir 3 IPv4 chez toi si tu en as envie (il te suffit de commander 3 abos, il n'y a aucune limite à ma connaissance à part le nombre de lignes tirées par FT), c'est toi qui a choisi d'en avoir qu'une seule par rapport à ce que tu acceptes de payer.
[^] # Re: Le principal problème est la pénurie d'adresses IPv4.
Posté par eingousef . Évalué à -1. Dernière modification le 28 novembre 2013 à 12:11.
Ok c'est pas une pénurie c'est une rareté alors.
Nananère quand même \o/
*splash!*
[^] # Re: Le principal problème est la pénurie d'adresses IPv4.
Posté par barmic . Évalué à 3.
Tu peut très bien avoir n adresse IP sur une même ligne, c'est juste que les FAI ne le proposent pas.
Et le fait que ça revienne chère ne vient pas du tout de la rareté, n'est ce pas ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le principal problème est la pénurie d'adresses IPv4.
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 28 novembre 2013 à 12:43.
Je n'ai pas dit le contraire.
Je n'ai pas dit ça. a toi de voir avec ton FAI, je dis juste que c'est possible d'avoir plusieurs IP par logement.
Le coût est plus cher que chez un hébergeur, mais c'est possible. Je répondais à quelqu'un qui sous-entendait que ce n'était pas possible.
Et 30€/mois pour un truc "qu'il y a plus c'est horrible", c'est pas encore un truc que je considère rare, du moins pas comme on nous le dit. Et encore une fois, tu parles de prix, j'ai parlé de disponibilité. Le prix, tu vois avec ton FAI, c'est pas une limite technique mais commerciale (cette limite existait déjà il y a 20 ans où on ne parlait pas de pénurie) dont je me fou complet dans ma question.
et encore une fois, ce n'est pas le sujet, j'ai des @IP à 1€/mois (pas chez moi, et alors je n'ai pas parl de cette limite)
au final, on ne m'a toujours pas expliqué pourquoi cette explication "j'ai un problème avec la dispo d'IPv4" (si il faut précisser : chez les hébergeurs dans un pays ayant déployé Internet en premier et où on a autant d'IP qu'on veut à 1€/mois/@IPv4)
[^] # Re: Le principal problème est la pénurie d'adresses IPv4.
Posté par barmic . Évalué à 6.
Dès ton premier message tu parle de prix.
Personnellement je trouve que 30€/mois pour un enregistrement DNS et une ligne dans des tables de routage, c'est énorme. Le prix ne reflète pas le service ou la difficulté.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTPS
Posté par Antoine . Évalué à 6.
Heu… On s'en fiche, justement, que le site A soit sécurisé, ce qui compte c'est que la clé PGP que tu as récupérée soit signée par un certain nombre de gens de confiance (en fonction de ton propre réseau de confiance).
Évidemment, j'imagine que comme la plupart des gens (y compris moi), tu n'as utilisé PGP que pour essayer un jour, donc ton réseau de confiance est très restreint. Mais idéalement tu n'as pas besoin de HTTPS pour valider une clé PGP.
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 26 novembre 2013 à 21:20.
Avec autant de si, on mettrait Paris en bouteille ;-).
Oui, je ne suis pas grand utilsiateur de PGP, tout simplement parce que même pour moi (ne parlons pas de non informaticiens), c'est incompréhensible.
Après, si récupérer une clé PGP sur un canal non sécurisé (donc falsifiable) est suffisant pour être sûr que le site atteint est le bon, admettons, mais il y a besoin de m'expliquer comment ça marche, car pour le moment, je pige que dalle (et de ce que j'ai testé de PGP, ça m'a un peu fait peur, genre j'ai pas réussi à révoquer un message signé par un voleur avant que je m'en soit rendu compte dans mon scénario, le message était toujours "ok" bien que j'avais révoqué la clé).
Sans parler que les outils ne sont pas accessibles à tout le monde (il faut connaitre, et bien, pour pas faire de conneries, SSL ça fait passer par des intermédiaires dans lesquels il faut avoir certes confiance, mais je comprend mieux ce que je fais quand je fais).
[^] # Re: HTTPS
Posté par barmic . Évalué à 5.
Aussi bonne que la confiance que tu place en GeoTrust.
Personnellement j'installe Debian et j'accède à https://linuxfr.org avec une chaîne de confiance qui me semble tout à fait acceptable (je dois faire confiance en la signature des paquets installés qui eux me fournissent le certificat racine de CACert). J'installe ma Debian à l'aide d'une autre distribution et debootstrap à partir du dernier livecd à la mode que j'ai obtenu dans un magazine (auquel je fait confiance).
Je ne dis pas que mon cas est généralisable, mais j'ai pas vraiment confiance en ta chaîne de confiance. D'une part Windows est à mon avis depuis cet été légitimement soupçonnable (oui pBpG, même si MS n'y est pour rien et ne fait que subir les contraintes des lois ignobles post-11 septembre), d'autre part je ne connais pas GeoTrust (alors que je connais un peu CACert).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTPS
Posté par Aris Adamantiadis (site web personnel) . Évalué à 4.
Je plussoie d'autres lecteurs dans le sens où CACert a un vrai problème d'utilisabilité. Je ne me vois pas installer un root CA (= possibilité de faire du Mitm sur tous les sites que je visite) uniquement pour aller sur linuxfr. Ce root CA n'a aucun avantage par rapport à la concurrence (ah ouais c'est libre mais ça marche pas). Utiliser CACert ne diminue pas de manière magique la liste des CA autorisés dans mon browser et donc n'augmente pas la sécurité de ma communication (ni celle du site) mais au contraire la diminue.
Pour quelle raison ? Parce que la totalité des autres CA de mon browser ont suivi une procédure pour pouvoir être inclus dans cette fameuse liste, et CACert ne répond pas aux critères demandés.
On va alors me répondre "Mais t'as vu tous les scandales avec les CA ? Diginotar, Comodo etc. ?". Je réponds que si même eux, qui suivaient des procédures et répondaient à des critères de sécurité assez stricts ont été compromis, je ne vois pas la moindre raison pour que CACert soit plus sécurisé. La difficulté d'utilisation en plus.
Il faut de temps en temps arrêter avec le librisme acharné quand on se rend compte que ça ne marche pas.
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 26 novembre 2013 à 14:07.
Pas difficile, certes. Mais une éducation des gens "le warning est chiant, ne le regardez pas, la sécurité c'est pas si important" complètement à l'opposé de l'éducation à la sécurité (dont celle que Mozilla essaye d'apporter).
Pour des gens parlant de sécurité dans une dépèche, ça fait un peu le cordonnier qui est le plus mal chaussé et faites ce que je dis, pas ce que je fais.
Et dire que tout ça serait déjà plus simple si CACert faisait l'audit… Ca montrerait que la sécurité est sérieusement prise en compte par CACert et que la barrière est financière (IE et Safari).
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Ton propos sur l'éducation est à côté de la plaque. On ne dit pas « ne tenez pas compte des avertissements », on dit « comprenez ce que ça veut dire ». Les navigateurs ont des avertissements que je trouve plutôt abusifs car ils mettent dans le même sac certificat obsolète, algorithme obsolète, autorité non reconnue et certificat auto-signé. La sécurité ce n'est pas « faites aveuglément confiance à votre navigateur il sait ce qui est le mieux pour vous ». Sinon mon processeur pourrait décider à ma place quel binaire mérite l'exécution, mon disque dur quels sont les meilleurs octets, etc. Si je veux accéder à https://le_meilleur_des_lolcats.example.com avec son certificat auto-signé donc je me contrefiche vu que je veux juste mater des photos de chatons, c'est mon choix.
Et pour quelqu'un qui comme toi parle de sécurité, opter pour des clés de chiffrement générées par un tiers et transmises à tu ne sais pas qui ? Combien de gens sont capables de produire des certificats linuxfr.org "valides pour les navigateurs" grâce à des autorités n'ayant pas fait leur boulot ?
On pourrait fournir sur le site la signature GPG de nos empreintes de certificats x509 par contre. Mais faudra toujours accepter de lire et de comprendre l'avertissement du navigateur.
Ça je suis bien d'accord.
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
D'abord LinuxFr.org est géré par l'asso LinuxFr, dont le but est tout de même de parler de logiciels libres. Du coup on préfère les solutions à base de logiciels libres.
Parmi les assos du libre, d'autres ont fait le choix de ne pas se préoccuper de qui fournit leur certificat ou d'opter pour un certificat qui leur donnera la meilleure efficacité possible, notamment pour collecter des dons. Pour LinuxFr.org on a l'avantage de ne pas avoir besoin de se dire que l'on doit gagner 3 points de marché sur les CSP+ sur iMachins afin d'optimiser nos revenus publicitaires et que pour ça il faudrait opter pour une solution propriétaire ou une solution centralisée. C'est-à-dire que si on venait me donner gratuitement la solution ultime qui marche partout mais qui est propriétaire et centralisée, elle ne vaudrait pas à mes yeux une solution libre et décentralisée qui marche suffisamment bien.
Sinon oui on croise peu de sites avec CaCert oui.
Au final, les gens ont le choix entre :
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
J'ai bien séparé la partie qui relève de LinuxFr.org de celle qui est mon avis personnel dans le cadre de mon activité de libriste bénévole dans le commentaire concerné.
[^] # Re: HTTPS
Posté par eingousef . Évalué à 10.
Hélas, sa décision est prise, je pense qu'il est inutile de chercher à le faire changer d'avis.
*splash!*
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 6.
Pourquoi donc? Leur position n'a pas bougé depuis des années, et tu le découvres que maintenant? Pourquoi tu changes d'avis maintenant alors qu'eux (les membres de l'asso LinuxFr) ont l'intégrité de ne pas avoir changé de position? On aime ou pas (oui, ils sont utopiques mais ils l'ont toujours été!), on est d'accord ou pas, mais il faut leur reconnaitre une constance dans leur choix qui est tout à leur honneur.
Tu serais pas pote des 2 anciens UMP qui vont au FN pour ensuite dire qu'ils ne savaient pas ce qu'était le FN?
PS : anonymiser les journaux ou commentaires, admettons, mais les supprimer… ca casserait beaucoup le reste des commentaires, ce n'est pas non plus ton blog où tu es maitre de tous. Tes écrits sont publiques, et tu as en tout connaissance de cuase écrit sur un site dont tu n'es pas admin, ça fait bizarre comme demande.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: HTTPS
Posté par barmic . Évalué à 4.
Oh con… °_°
J'ai jamais vu quelqu'un monter sur ses grands chevaux aussi vite, surtout que c'est un habitué. Rien n'a changé entre la semaine dernière et aujourd'hui, mais pouf…
Peut être est-ce là la fin d'une série de déconvenues sur le site (si oui je serais curieux d'en savoir plus) ou de problèmes personnels.
C'est vrai que tu ne licencie jamais tes journaux, bon débarras (pour les journaux, ça ferra du contenu non libre et non partageable en moins sur le site).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Une liste non exhaustive a priori de sites ayant recours à CaCert http://wiki.cacert.org/CacertSites (donc quelques sites majeurs tout de même).
Sinon quelques liens intéressants trouvés au passage :
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 2.
Quel site majeur?
J'en vois aucun de majeur (par exemple, le CCC est certes majeur pour 1% de des gens qui vont se dire libristes, et encore sorti d'Europe ça limite le nombre de personnes qui connaissent, mais ça ne fait pas un site majeur de manière générale, loin de la)
Tu veux quand même pas parler de "Esperanto Nürnberg" j'espère :-D
[^] # Re: HTTPS
Posté par ariasuni . Évalué à 1.
C’est possible sur le navigateur par défaut, Sur Tint Browser, il me semble que c’est possible sur Firefox et il ne me semble pas incongru de penser que c’est possible sur Chrome.
Tu peux faire le lien vers la version http du site.
Je trouve qu’avoir une bonne sécurité par défaut c’est un combat utile quand même.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 1.
Et après on parle de sécurité…
Aujourd'hui, c'est pas une bonne sécurité par défaut (CACert n'ose pas se faire auditer, message lorsqu'on essaye d'accéder en HTTPS…), si combat sur la sécurité il y aurait, faudrait déjà penser à botter le cul à CACert pour qu'il se fasse auditer, en attendant ce combat n'est pas sur la sécurité mais sur le "communautaire" qui aurait la priorité sur la sécurité.
[^] # Re: HTTPS
Posté par Tonton Th (Mastodon) . Évalué à 5.
Quelques remous chez OpenBSD à propos de CACert :
http://marc.info/?l=openbsd-bugs&m=138437411216098&w=2
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 02 décembre 2013 à 13:24.
Clair, net, précis, ça fait mal. Si Debian (et ubuntu) retirent leur soutien, ainsi que du BSD, ça sera quand même un très très grand signe de problème pire qu'imaginé (puisque déjà aujourd'hui c'est du militantisme, mais même si les militants dans BSD et Debian lâchent l'affaire…).
On est très loin dans la crédibilité d'un audit prochain.
Qu'on ne vienne pas me parler de sécurité avec CACert ensuite :).
PS : bon, certes, c'est qu'un gus qui demande et pas foule le suit, mais quand même… Il demande et dit pourquoi, si jamais ça touche la bonne personne…
[^] # Re: HTTPS
Posté par Zenitram (site web personnel) . Évalué à 2.
Peut-être aussi que la question est mal posée.
Vaut-il mieux pour la sécurité un truc open-source (tout ça) pas sécurisé ou un truc non open-source non sécurisé?
Parce que la, ta question est du genre "on cherche un truc sécurisé mais si c'est pas sécurisé ce n'est pas un problème".
A la question "existe-t-il un truc secure open-source" on peut aussi accepter la réponse "non" et chercher un truc secure ensuite en attendant, plutôt que d'utiliser u ntruc qui incite les gens à ne pas aire attention quand il y a un warning dans le navigateur (le warning est normal, vas-y clique).
Car la, ça m'étonne que vous utilisiez un CPU non open-source avec la logique "on cherche un truc open source qui fait x mais pas grave si ça ne fait pas x", donc vaut mieux utiliser un CPU x open-source même si il est pourri.
Mais bon, on tourne en rond, le sujet à déjà été débattu (genre chaque fois qu'on parle de ce foutu warning SSL).
[^] # Re: HTTPS
Posté par sifu . Évalué à 1.
En même temps, les explications commencent à dater un peu.
De ce que j'en ait compris, CaCert avait dit "on n'est pas très bon, il faut peut-être attendre un peu avant de nous inclure" et puis … le temps passe ;)
[^] # Re: HTTPS
Posté par yann-kaelig . Évalué à -2.
Il existe un module pour firefox qui s'appelle "https finder" ( Firefox extension for discovering HTTPS sites and creating HTTPS Everywhere rulesets )
Il a disparu ( semble t-il pour des raisons de compatibilité ) du site d'addons mozilla, cependant il est disponible et à jour sur:
https://code.google.com/p/https-finder/
les sources
https://github.com/kevinjacobs/HTTPS-Finder
ENJOY HTTPS
[^] # Re: HTTPS
Posté par yann-kaelig . Évalué à -3.
Bizarrement ça n'a pas l'air de détecter la version https. ( testé sur linuxfr entre autre )
Quelqu'un peu confirmer ?
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Sur la page, on peut lire qu'il faut accepter les certificats.
Sinon y a https://www.eff.org/https-everywhere qui est utilisé par certains ici.
Et sinon y a juste à se loguer en HTTPS en fait. Cf http://linuxfr.org/aide#aide-cookies
[^] # Re: HTTPS
Posté par yann-kaelig . Évalué à 0.
Si tu parles bien du certificat CACert, il était déjà présent.
Avec https-everywhere le site ne passe pas automatiquement en https, je dois pour ça taper l'adresse complète à la main, d'où ma remarque sur https finder.
Bizarre. Quelque chose m'échappe.
[^] # Re: HTTPS
Posté par cluxter . Évalué à 1. Dernière modification le 26 novembre 2013 à 09:56.
Justement, c'est pour ça que j'ai posé la question, j'utilise aussi HTTPS Everywhere et même en tapant "https://" au lieu de "http://" il me reprenait la version HTTP en cache plutôt que d'aller sur la version chiffrée. Donc j'ai d'abord dû fermer mon onglet et le rouvrir.
Et je pensais aussi que HTTPS Everywhere testait si un service HTTPS était disponible et, si non, allait sur HTTP, mais apparemment non. J'imagine qu'il utilise une liste blanche pour accélérer les connexions ? Mais du coup on ne profite pas automatiquement du service chiffré s'il n'est pas répertorié.
EDIT : mais c'est surtout que je trouve que linuxfr.org devrait nous rediriger automatiquement vers la page chiffrée, qu'est-ce que vous en pensez ?
[^] # Re: HTTPS
Posté par barmic . Évalué à 3.
HTTPS Everywhere utilise une liste de règle pour rediriger vers la version ssl des sites qu'il connaît. La dernière fois que j'ai essayé il n'avait pas linuxfr (mais je ne l'utilise plus depuis très longtemps).
Le certificat racine n'étant pas dans les navigateurs les plus utilisé ça diminuerait la visibilité du site je pense.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: HTTPS
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Il y a LinuxFr.org dedans depuis octobre 2010
[^] # Re: HTTPS
Posté par Bruno Michel (site web personnel) . Évalué à 9.
Si un utilisateur va sur la page en https et s'authentifie, on dépose un cookie pour faire la redirection automatique de http vers https (et le cookie d'authentification est envoyé en https uniquement). Par contre, nous ne souhaitons pas étendre ce mode de fonctionnement aux autres utilisateurs car il peut y avoir de bonnes raisons de ne pas pouvoir accéder au https (proxys d'entreprises qui refusent notre certificat par exemple).
[^] # Re: HTTPS
Posté par octane . Évalué à 3.
Merci d'ailleurs, j'ai eu le cas dans une entreprise. linuxfr en https bloqué pour cause de certificat. Bah je moulais en http du coup.
[^] # Re: HTTPS
Posté par 2PetitsVerres . Évalué à 3.
C'est un bel exemple de sécurité intelligente, ça. Interdire les sites en https pour cause de certificat non accepté par la boite tout en laissant les sites en clair. Bravo.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: HTTPS
Posté par hermenegilde . Évalué à 1.
Tiens, c'est marrant, je m'en sers pour exactement l'inverse: rediriger le linuxfr en https vers le site en http. La conf est pas triviale, mais ça marche bien.
# LXC
Posté par philpep (site web personnel) . Évalué à 6.
Voilà les cap.drop que j'utilise:
Par contre si on drop net_admin, il ne faut pas oublier de configurer l'ip et gw en static (lxc.network.ipv4, lxc.network.ipv4.gateway).
Voir aussi sur mon blog pour un exemple de config grsec et iptables pour renforcer l'isolation.
[^] # Re: LXC
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
C'est quand même moche une liste d'exclusion à maintenir à jour à chaque nouvelle version du noyau pouvant ajouter de nouvelles capabilities.
[^] # Re: LXC
Posté par Misc (site web personnel) . Évalué à 4.
Regarde du coté de svirt si tu veux une approche basé sur une whitelist ( attention, ça impliqe d'avoir selinux )
[^] # Re: LXC
Posté par philpep (site web personnel) . Évalué à 1.
Certaines capabilities sont obligatoires pour faire tourner une debian (par exemple). Le but de lxc n'est pas la sécurité mais l'isolation, d'où la liste d'exclusion et toutes les capabilities actives par défaut. Et l'apparition de nouvelles capabilities ne vont pas introduire de regression ni de nouvelle "faille" dans tes containers (au pire, il sera moins secure qu'il ne pourrait l'être).
Mais jeter un coup d'oeil au changelog et en particulier aux capabilities(7) quand on met à jours le kernel c'est toujours une bonne pratique ;)
[^] # Re: LXC
Posté par zebra3 . Évalué à 7.
On joue sur les mots mais si un container est moins secure suite à une mise à jour, c'est bien qu'il y a une nouvelle faille, non ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: LXC
Posté par zebra3 . Évalué à 4.
On ne peut pas juste faire un « lxc.cap.drop = a » comme pour « lxc.cgroup.devices.drop » et n'autoriser explicitement que celles dont on a besoin ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: LXC
Posté par philpep (site web personnel) . Évalué à 2.
Justement non puisque les capabilities sont permissives par défaut. Si les développeurs du noyau rajoutent une capability essentielle pour lancer ton container (par exemple CAP_SETUID en est une), il ne redémarrera pas suite à la mise à jours, ce qui est une regression.
# ralentisseur ?
Posté par tetaclac . Évalué à 3.
Quelqu'un pourrait expliquer l'intérêt? j'ai cherché mais sans succès.
Merci
[^] # Re: ralentisseur ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
À cause de ça :
Pour Free cf http://search1-2.free.fr/index_en.html
[^] # Re: ralentisseur ?
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Je sais pas avec postfix, avec sendmail on peut utiliser une queue par domaine de destination.
Dans /etc/mail/access :
Puis dans ton mc
̀FEATURE(
define(
QUEUE_DIR',/var/spool/mqueue')QUEUE_GROUP(
orange',P=/var/spool/mqueue/orange, I=1s, Jobs=1, recipients=1, Runners=1')dnlQUEUE_GROUP(
laposte',P=/var/spool/mqueue/laposte, I=1s, Jobs=1, recipients=1, Runners=1')dnl̀`# Pas tout compris mais du coup...
Posté par Maclag . Évalué à 10.
… tu viens de faire une magnifique piqûre de rappel sur le thème:
"Gérer un site à inscriptions, c'est pas pour les bricolos"
[^] # Re: Pas tout compris mais du coup...
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Justement c'est un peu le questionnement final : comment rendre cela plus facile et plus accessible pour les futurs geeks, libristes et hackers encore glabres ou qui débutent en pilosité ? Comment les libristes peuvent se faciliter la vie les uns les autres et la rendre plus facile aux utilisateurs en général ? Comment seront les « systèmes d'information » des prochaines FSF/LQDN/April/LinuxFr.org/Framasoft/EFF/LeaLinux/FDN/etc. ? Comment éviter que ça ne devienne qu'un truc de professionnels et d'experts hors de portée de bénévoles et d'amateurs motivés ?
Exemple : comment avoir des paquets nginx/apache2/postifx/etc. qui gèrent mieux cette complexité et qui proposent des configurations plus « avancées » ? Qui vérifient ou aident à configurer les entrées DNS DKIM/SPF/DNSSEC ?
[^] # Re: Pas tout compris mais du coup...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je pense que c'est un projet en soi. Cela peut être un tutorial, un script si cela devient complexe, voir un nouveau projet de module pour serveur, si vraiment une politique correct de sécurité devient une usine à gaz avec les outils actuels (on peut imaginer que le site web met tout seul à jour le DNSSEC par exemple).
"La première sécurité est la liberté"
# DNSSEC pas si compliqué
Posté par Spomky . Évalué à -6.
Mes domaines sont chez OVH et le passage vers DNSSEC s'est fait en un clique, leur serveur DNS gère tout, y compris la rotation des clés (https://www.ovh.com/fr/domaines/guides/g609.securiser_votre_domaine_avec_dnssec).
C'est plus simple que de gérer son propre serveur, même si on s'éloigne du Do It Yourself.
[^] # Re: DNSSEC pas si compliqué
Posté par Zenitram (site web personnel) . Évalué à 5.
Au cas où tu n'as pas compris la problématique : ce que tu écris est exactement la problèmatique soulevée par la dépèche.
Tu devrais peut-être commencer par lire la dépèche.
[^] # Re: DNSSEC pas si compliqué
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Est-ce qu'OVH fournit son outil de gestion sous licence libre ? De façon déployable par tout un chacun ? Sinon tant mieux pour leurs clients, mais ce n'est pas ce qui est évoqué dans la dépêche.
[^] # Re: DNSSEC pas si compliqué
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
C'est pas qu'on s'en éloigne, c'est qu'on file à l'autre bout de la galaxie : la solution OVH est du pur claoude. On peut aimer mais question liberté, c'est pas ça…
# DANE et DNSSEC
Posté par Yggdras . Évalué à 2.
À propos de DANE, je ne comprends pas trop pourquoi il oblige à utiliser DNSSEC. Je trouve que DANE sans DNSSEC apporte déjà de la sécurité, en compliquant la tâche de l'attaquant, même si ça reste sensible à certaines attaques man-in-the-middle. Ça permet déjà de se protéger de "proxy ssl", en passant par le serveur DNS de son choix, et en vérifiant que le certificat présenté par le proxy est correct.
Je voudrais bien utiliser DANE pour mes sites, mais je trouve DNSSEC bien compliqué à mettre en place, surtout que je n'ai pas de serveur DNS installé. Est-ce que je me trompe, et est-ce que je devrais envisager de gérer le DNS moi-même ?
[^] # Re: DANE et DNSSEC
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
LinuxFr.org n'a pas de serveur DNS en propre. On utilise ceux de TuxFamily.org (merci à eux).
[^] # Re: DANE et DNSSEC
Posté par claudex . Évalué à 4.
Si tu as un proxy SSL, rien n'empêche d'avoir un proxy DANE qui réécrit les réponse DNS à la volée. DNSSEC est donc nécessaire.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: DANE et DNSSEC
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
"Certaines" ? Non. Sans authentification, TLS est vulnérable à toutes les attaques de l'homme du milieu. Sans DNSSEC, le DNS est même vulnérable à l'homme du bord (pas besoin d'être homme du milieu pour faire un empoisonnement DNS.) Sans authentification, TLS ne protège que contre un attaquant passif (genre Firesheep).
# Re-signatures avec DNSSEC
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
Attention, c'est vrai qu'il faut re-signer périodiquement lorsqu'on utilise DNSSEC mais ce n'est pas forcément à la main, il est même au contraire très recommandé d'utiliser un outil automatique. Je suggère OpenDNSSEC (libre, évidemment, et tournant sur Linux, évidemment). http://www.opendnssec.org/
[^] # Re: Re-signatures avec DNSSEC
Posté par claudex . Évalué à 3.
Je n'ai pas compris l'intérêt de signer toutes les deux semaines. Quand on fait un certificat pour un site web, c'est valide un ou deux ans par exemple.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Re-signatures avec DNSSEC
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
Tout à fait. Une durée de validité des signatures DNSSEC de deux mois me convient tout à fait. Ceci dit, quand la re-signature est automatique (ce qui est fortement recommandé), la question du délai est moins cruciale.
Et la comparaison avec TLS n'est pas bonne car TLS ne permet pas facilement d'attaques par rejeu.
[^] # Re: Re-signatures avec DNSSEC
Posté par claudex . Évalué à 4.
Ok, je n'avais pas penser que c'était pour éviter le rejeu.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Risques pour les petits
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
Tout à fait d'accord sur le risque que la sécurité n'empêche les "petits" acteurs de se développer et les décourage, avant de les jeter dans les bras des gros silos fermés.
Pour LinuxFr, je suppose qu'il y a assez de compétences disponibles. Pour M. Michu qui voudrait faire un truc équivalent, on manque en effet d'outils simples et bien intégrés. Une bonne discussion avait eu lieu sur LinuxFr à ce sujet : https://linuxfr.org/users/bortzmeyer/journaux/rendre-l-auto-hebergement-facile-et-sans-douleur
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.