Harry a écrit 18 commentaires

Je suppose que ça mériterai une entrée dans le suivi. D'ailleurs, il y a déjà 3 tickets en rapport avec l'HTTPS :

• Suivi - Administration site Avoir une meilleur configuration HTTPS
• Suivi - Flux Atom Les liens des flux atom sont en HTTP
• Suivi - Flux Atom Liens en HTTPS dans les flux rss / atom

Cette entrée est un doublon de #1475.

La CNIL semble effectivement la bonne solution : Vous souhaitez vous opposer à l'utilisation commerciale de vos données.

Le fait que ce soit marqué n'implique pas automatiquement que ce soit légal, même si je pense avoir effectivement donné mon accord en validant les CGV il y a quelques années. J'ai cependant le droit de demander l'arrêt de l'envoi de ces messages, comme l'indique la CNIL :

Vous souhaitez stopper des sollicitations commerciales par courrier électronique.

La prospection par courrier électronique est interdite, sauf :
- si vous avez donné votre accord pour recevoir cette prospection,
- si vous êtes client de la société qui vous prospecte.

L’expéditeur doit vous permettre de stopper gratuitement ces messages.

Sinon, je suis d'accord sur l'excellence des services offerts par Captain Train ;)

La clé utilisée par le projet Linux Mint pour signer les hashs des ISO (sha256sum.txt.gpg) est celle du développeur principal. Il est malheureux de constater que c'est une clé DSA 1024 (que le NIST considère actuellement comme non-sûre).

Pour information, l'achat a été remboursé dès le lendemain :

Suite à votre demande, nous avons procédé, à titre exceptionnel et unique, au remboursement de votre achat Contact+ contesté, d'un montant de 4.68 €. Ce montant sera déduit de votre prochaine facture ou de la suivante.

Rootkit générique ? Rootkit dédié ? Je ne suis pas sûr de comprendre ce que tu écris.

Comme je l'ai écrit dans mon commentaire précédent, la backdoor RCS supporte bien Linux, ce qui montre que c'est bien une cible pour Hacking Team. Pourquoi refuser la réalité, et ne pas accepter que Linux aussi est la cible d'attaques, que ce soit des serveurs ou des postes clients ?

Les failles "à distance", comme tu les appelles, ne sont pas rares, au contraire. Preuve en est le nombre de serveurs piratés grâce à des vulnérabilités dans des langages de script comme PHP au hasard. Enfin, Linux sur un poste client peut aussi constituer une cible de choix, par exemple si l'utilisateur administre d'autres serveurs, si c'est un développeur d'un projet important, etc.

Est-ce que tu as vu https://github.com/hackedteam/core-linux ? C'est la version Linux de leur backdoor RCS.

Et je ne pense pas qu'un antivirus sur ton poste de travail change grand chose, vu le travail important réalisé par Hacking Team pour que leurs binaires ne se fassent justement pas détecter. Par contre ça peut te donner l'illusion que tu es protégé.

Si on lit la discussion sur reddit, on peut justement apprendre que ce n'est pas une faille dans SELinux. Contrairement à ce que laissent penser les noms des binaires, ce sont des exploits pour la vulnérabilité put_user (CVE-2013-6282), corrigée dans le noyau Linux en octobre 2012.

La backdoor RCS crée des fichiers dont le nom ressemble à ceux générés par whoopsie pour ne pas éveiller de soupçons chez l'utilisateur. En aucun cas whoopsie ne crée de fichiers de la forme suivante :

• /var/crash/.reports-%u-%s
• /var/tmp/.reports-%u-%s
• ~/.config/autostart/.whoopsie%s.desktop

Et la backdoor ne concerne pas uniquement des serveurs, mais surtout des postes clients.

Qu'en est est-il de la sécurité du protocole ? Un challenge a eu lieu fin 2013, avec $200,000 à la clé pour la première personne réussissant à casser le protocole. Il n'y a eu aucun gagnant, ce qui pourrait laisser croire que le protocole est sécurisé. Malheureusement ce type de challenge ne prouve rien du tout, comme l'a écrit Moxie Marlinspike dans un billet sur son blog.

Je pensais pouvoir recommander une alternative viable, mais TextSecure a arrêté le support des SMS/MMS chiffrés.

Le manque de références et d'arguments donne un ton très commercial à cette dépêche. Dommage, des benchmarks pour justifier l'impression de vitesse ou des comparatifs avec d'autres environnements de bureau seraient, à mon avis, les bienvenus.

Il est aussi difficile de voir les modifications apportées par Elementary OS à Ubuntu. Pourquoi créer une nouvelle distribution plutôt que d'intégrer ces modifications à Ubuntu ? Pourquoi avoir choisi Launchpad ?

Le chiffrement ne résout pas uniquement le problème de la confidentialité (des logins, mots de passe, cookies, etc.), mais aussi celui de l'intégrité. Il est très désagréable de visiter un site web sur lequel de la publicité est rajoutée par le fournisseur d'accès. Plus grave, un attaquant peut effectuer du man-in-the-middle pour injecter du contenu dans une page web afin d'exploiter une vulnérabilité dans le navigateur web ou un de ses plugins pour finalement en prendre le contrôle.

Avoir un site en HTTPS dont l'intégralité du contenu est en HTTPS (ie : il ne dépend pas de ressources en HTTP) protège l'utilisateur de ces différentes menaces.

PS (trop tard pour éditer le commentaire) : avant de lire cette réflexion, je préciser que Google est une entreprise qui est détestable sur bien des points, mais que ça n'empêche pas de tenter d'avoir un point de vue impartial sur certains aspects de ses services.

Je lis souvent cette affirmation, et j'estime au contraire que Gmail est un des hébergeurs mail les plus sécurisé. Penser faire le poids en hébergeant ses mails sur son propre serveur me semble catastrophique, et les solutions libres ne sont pas la question.

Le but de Gmail est d'utiliser les données de ses utilisateurs pour vendre de la publicité, et a tout intérêt à protéger au mieux ces données (qui ne sont d'ailleurs pas revendues à des tiers). Ce n'est pas un hasard si Google a des équipes de sécurité excellentes, et a été une des premières boîtes à proposer des bug bounties sur ses services en ligne. Par ailleurs, on a pu voir la réactivité des équipes de Google pour chiffrer le trafic entre ses data-centers lorsqu'il est devenu public que la NSA avaient accès à ces données.

Là où le bas blesse, ce sont les réquisitions judiciaires. Gmail respectera la loi, et fournira les mails d'un utilisateur pour n'importe quelle demande suffisament justifiée.

Je parle de Gmail en particulier, car la plupart des services de messageries ne sont clairement pas à ce niveau. Tu évoques par exemple Yahoo qui a mis plusieurs jours à patcher la vulnérabilité Heartbleed, entraînant la fuite aléatoire de milliers de login/password d'utilisateurs.

Enfin, héberger ses mails sur un serveur me semble partir d'une bonne intention mais se révèle désastreux du point de vue de la sécurité à long terme. Appliquer les correctifs de sécurité à temps prends du temps, beaucoup de temps ; et sécuriser une machine nécessite des compétentences que tout le monde n'a pas. Il est souvent tentant d'héberger d'autres services sur la même machine, qui augmentent la surface d'attaque. Qu'est-ce qui garantit que l'hébergeur n'est pas compromis ? Que les OS fournis par ce même hébergeur ne sont pas compromis ? Que des administrateurs ont accès au machine par des options d'administration matérielles ?

Une excellente analyse d'AppArmor a d'ailleurs été effectuée par Dan Rosenberg en 2012, qui montre les différents problèmes inhérents à ce type de solution.

Il ne faut pas oublier qu'une application peut contenir des vulnérabilités. Des vulnérabilités sont par exemple régulièrement trouvées dans les navigateurs web, et peuvent être exploitées lors de la visite d'un site web malveillant.

De nombreuses distributions intègrent un LSM empêchant le debug d'un autre processus. Ubuntu utilise par exemple Yama dont le sysctl /proc/sys/kernel/yama/ptrace_scope est par défaut à 1.