Yves a écrit 383 commentaires

Je ne suis pas expert du sujet, mais je vais tenter une réponse.

Effectivement, il y a plusieurs rebonds. Cependant, en situation « nominale », le chemin est assez court :

1. ton client (ex. Thunderbird) contacte ton fournisseur (ex. monFAI.fr) ;
2. ton fournisseur contacte le fournisseur du destinataire (ex. sonFAI.fr).

C’est tout. En réalité, il peut y avoir plus de rebonds, car selon la topologie de réseau, on peut vouloir subdiviser le traitement des email, ou en externaliser certaines parties.

À l’origine, tout cela est un peu « open-bar », et petit à petit, on a protégé les choses, notamment l’étape 2. ci-dessus :

DKIM et SPF visent globalement à s’assurer que le domaine qui envoie (@monFAI.fr) est véridique. SPF liste les serveurs habilités à envoyer au nom de ce domaine, et DKIM permet de vérifier par une signature cryptographique que seul un serveur habilité a effectivement pu envoyer le mail.

Rien n’est spécifiquement fait pour s’assurer que le domaine récepteur est le bon. Là, on fait confiance au DNS (MX, AAAA…). C’est un autre sujet, pour lequel d’autres techniques existent.

Reste à sécuriser l’étape 1. ci-dessus. Là, en général, on s’appuie sur un login et un mot de passe. Et comme sur le web, tu n’entres pas ces données sans que le canal de communication ne soit sécurisé. Le serveur qui vérifie ton accès est celui qui gère @monFAI.fr, et donc c’est entre toi et ce serveur qu’il faut chiffrer la communication. Le besoin s’arrête là. Il ne s’agit pas de sécuriser tout le trajet jusqu’au destinataire.

Le trajet entre serveurs de messagerie (notamment l’étape 2. ci-dessus) passe par le port 25, généralement en clair. Pour cette raison, pour masquer le contenu d’un email, il faut une action de chiffrement à ton initiative, indépendante du transporteur. On utilise souvent S-MIME ou GnuPG pour ça. Il suffit que l’émetteur et le destinataire se comprennent.

C’est comme avec La Poste : tout le monde voit l’extérieur (émetteur, destinataire, tampons d’acheminement…), mais tu peux décider, à ton initiative, de mettre le contenu dans une enveloppe pour que seul le destinataire puisse le lire ; tu peux aussi décider de laisser tout visible par tout le monde : la carte postale, ce que pratiquement tout le monde fait en matière d’e-mail.

Enfin, pour la dernière question : non, il n’y a aucun moyen de savoir, à moins de connaître le « postmaster » ou que les logiciels côté serveur laissent des traces révélatrices en en-têtes.

Pour « Eu », « ¤ », et « × », d’excellentes réponses ont déjà été données.
Au passage, je ne comprends pas l’intérêt de prendre un espace précieux avec ¼, ½, ¾… même en BÉPO ; il aurait été plus judicieux de proposer les multiples possibilités d’Unicode avec Compose ; par exemple : Compose,1,4 pour ¼. Régulièrement, je veux faire 2/3, et là je me trouve coincé :-(

Pour « \ », au risque d’être provocateur, je dirais que c’est le séparateur standard sur Windows, et que « le législateur » ne connaît que ça. Si des déviants utilisent Linux ou OS.X, ça n’est pas leur problème ; eux sont des gens sérieux.
Alors, oui, parfois, il (le législateur) « lance Internet » (vous savez, le e bleu avec un anneau), et demande à l’accueil (ie. :-p Google) de lui montrer par exemple « résultats de sondage » ou encore « wikipedia.org » (qui a besoin de la barre d’adresse ?).
Bref, « / » ? Pourquoi faire ? « ÷ » le remplace avantageusement…

Allez, bon vendredi !

Je confirme.

Ayant eu une panne de Box FAI chez moi pendant 1 semaine ½, quelques jours de downtime ne m’ont aucunement pénalisé, le temps que je bouge le serveur chez quelqu’un d’autre.
Bon, évidemment, si j’avais attendu 1 semaine ½ pour faire ça, j’aurais pu perdre des mails… mais jusqu’à 5 jours, la probabilité de perdre des mails est assez faible.

Et ça, c’est une grande force de SMTP ! Eussions-nous été encore le 1er de ce mois, j’aurais bien évoqué SMTP-o-PV, « SMTP over Pigeon Voyageur » de son nom complet, mais j’arrive trop tard…
(en vrai, cette résilience de SMTP est très rassurante/apaisante pour un auto-hébergeur !)

Toujours en open-source, je ne peux que recommander le jeu BlackVoxel!

Dans une ambiance solitaire (imaginez-vous dans « Seul sur Mars ») — mais êtes-vous vraiment seul ? —, des missions vous guident dans le rétablissement d’un environnement technologique, en partant de la seule machine sauvée du crash de votre vaisseau…

Oui, sans hésitation.
C’est la norme dans quelques administrations françaises et grandes entreprises où j’ai travaillé.

Le principe est simple :

• Le navigateur (IE, Firefox…) connaît les autorités de confiance habilitées à valider un certificat de site web.
• L’entreprise/administration établit au sein du groupe un poste de travail standard, dans lequel le(s) navigateur(s) intègrent une « autorité de confiance » interne (gérée par l’IT du groupe).
• Quand tu visites un site, ça passe par le proxy-MITM du groupe, qui ne fait que te répondre (signé avec un certificat généré à la volée et authentifié par l’autorité de confiance interne) ce que le vrai site a répondu. Si tu ne regardes pas le certificat, c’est complètement transparent.

Pourquoi faire ça ? Tout simplement pour la « sécurité », la surveillance, etc.
Historiquement, les entreprises aiment bien regarder ce qui entre et sort du réseau interne, pour vérifier que ça ne parle pas de jeu, de boursicotage, de sites sociaux… bref tout ce qui pourrait faire perdre en productivité. Tout cela se fait sous couvert (en partie justifié) de « sécurité » : audit, lutte contre la fuite de données, etc.
Avec SSL puis TLS, c’est plus compliqué. MITM et le DPI sont vus comme des solutions à ce genre de difficulté.

Triste conclusion des actualités…
Merci Mozilla pour la poursuite des efforts et la maintenance de ce navigateur au service de ses utilisateurs.
Merci aux rédacteurs pour cette page d’information.

« Chacun voit midi à sa porte », comme on dit (heure d’hiver ou d’été, je laisse chacun décider :-p )

Pour ma part, sachant qu’une faille logicielle a déjà failli m’atteindre, sur un logiciel en lequel j’avais pleinement confiance (exim), sur une distribution en laquelle j’avais pleinement confiance (Debian stable + màj. securité), et sachant que derrière il y a toute ma vie en scan (revenus, impôts, etc.), en mails, etc., je mets du coup la barre assez haut.

Tout d’abord, je te remercie pour ton commentaire nuancé et constructif :-)

Je voulais juste donner une anecdote amusante sur l’absence de réseau (avec un lien pour les plus curieux), et non m’étendre sur les détails, qui sont un peu hors-sujet, mais bon… je vais essayer de donner quelques précisions… Il faut par contre garder à l’esprit que c’est un projet en cours (non achevé).

De base, dans ma DMZ, à quelques exceptions près, l’accès sortant à Internet est bloqué. Et ce, par un paramétrage nftables qu’aucun service systemd n’a le droit d’altérer.

— Du côté de HAProxy, en cible, il y aura une isolation de namespace filesystem (comme un chroot) donc aucun accès à du contenu. À ce jour, il n’y a que de la protection par l’obscurité : HAProxy ne « sait » tout simplement pas où sont les rares données accessibles en DMZ (mais ça n’est pas si difficile à deviner). Comme tu l’as souligné, ça apporte un certain degré de sécurité mais ce n’est pas idéal…

=> En cas de faille permettant de faire exécuter par HAProxy un binaire quelconque, ce dernier n’aura sur le principe rien à communiquer avec l’extérieur, et s’il pourra peut-être recevoir des requêtes, il ne pourra en revanche pas en émettre.

— Du côté de Nginx, seules les sockets-Unix exposées servent à communiquer avec l’extérieur : recevoir des requêtes et y répondre. C’est le résultat d’un effort en cours pour retirer tous les accès réseau à Nginx ; à ce stade, je devrais pouvoir prochainement mettre en place une véritable isolation par namespace réseau, ce qui est ma cible.

=> En cas de faille permettant de faire exécuter par Nginx un binaire quelconque, ce dernier ne pourra pas utiliser le réseau, et n’aura de toute façon que peu de données accessibles.

— Php-fpm m’ennuie davantage… l’accès au réseau est restreint de manière similaire, mais il est plus délicat de mettre en place des restrictions sans aller jusqu’à ségréguer les applications PHP…

Hors DMZ, mais accessible depuis celle-ci, non ?

Oui, dans la « SafeZone » (hors-DMZ), on a accès aux données sensibles. Le point important est surtout que les logiciels qui y sont, et sont donc plus sensibles, ne sont pas directement exposés sur Internet : Nginx (en DMZ) agit en proxy et limite les possibilités de créer des paquets sur-mesure pour déclencher des bugs. Ça n’est pas entièrement sûr, mais ça l’est davantage qu’un accès direct ou par simple redirection de port.

Bref, tu as l’air de déjà le savoir : la sécurité n’est pas un interrupteur qu’on active ; c’est un millefeuille où chaque couche participe… et est insuffisante. Le choix du « nombre de feuilles » au millefeuille est un équilibre à trouver entre le risque, le coût de mise en œuvre et le coût d’une faille.
Comme je fais ce projet dans un but d’apprentissage en plus de son utilité immédiate, pour ma part, tant que ça reste 100% automatisé (ansible), ça me va ;-)

Nginx a 3 sections de configuration :

• une pour le contenu HTTP, en écoute sur (je simplifie) /run/http ;
• une pour le contenu HTTPS, en écoute sur /run/https ;
• une pour le contenu HTTPS accédé depuis une IP de confiance ou une IP ayant port-knocké le bon « mot de passe », en écoute sur /run/https+.

Sur la DMZ, nftables gère le port-knocking et redirige sur un port interne spécifique en cas de port-knock réussi ; j’ai donc 3 ports HTTP(S), sur lesquels haproxy est en écoute.

Outre la gestion de quelques subtilités (type tunnel), haproxy se contente en gros de rediriger le traffic HTTP sur /run/http, le traffic HTTPS sur /run/https, etc. (je ne détaille pas les divers paramétrages systemd)

Ainsi :

• haproxy a accès au réseau mais à aucun contenu,
• nginx a accès au contenu (non-sensible) mais pas au réseau,
• pour le contenu sensible, nginx doit faire appel a un service back-end hors DMZ, par exemple Nextcloud qui tourne sur un uwsgi.

C’est en tout cas plus compliqué. En quoi est-ce plus sûr ?

Je comprends bien qu’en l’absence de carte réseau virtualisée l’OS invité n’en dispose plus et donc n’a plus, en théorie, de réseau.
Finalement, c’est un peu la même chose avec les espaces de nommage réseau.

Il me semble en fait que tu pars du principe qu’un programme malveillant pourra contourner l’isolation de son espace de nommage (et donc accéder à l’espace de nommage réseau de l’hôte), mais qu’une telle chose est impossible dans une VM… Il me semblait pourtant que des programmes malveillants avaient été observés, qui contournaient l’isolation de la VM pour accéder à l’hôte.

Plus de détails m’intéressent, si tu as des liens.

Anecdote amusante à ce sujet : sur mon serveur auto-hébergé, je suis probablement un des rares individus de la planète à faire tourner son serveur web (nginx) sans accès au réseau !

Depuis qu’une backdoor a failli s’installer sur mon serveur il y a quelques années via une faille d’Exim dans Debian (je n’y ai échappé que parce que j’avais monté ma partition noexec), je suis devenu un peu parano au niveau sécurité… Mais il y a encore pire que moi :-D

C’est simple : on appâte le chaland avec un prix imbattable, puis une fois qu’on l’a capturé, on lui fait payer le renouvellement bien plus cher… mais bon, qui a envie de s’embêter à changer une fois que tout fonctionne… Et donc, ça marche.

C’est exactement pareil que les offres du type :

Seulement 10€/mois ! (*)

(*) pendant 2 mois, puis 50€/mois.

Le plus dangereux, ce n’est pas ceux qui connaissent ou ceux qui ne connaissent pas.

C’est ceux qui croient connaître. C’est pratiquement une règle universelle…

Ah, peut-être pas, c’est vrai. Tout va bien, alors :-)

Et à part ça, s’être marié le jour de la bascule de 1999, c’est quand même une coïncidence amusante !

La correction est-elle du niveau du firmware ou du software ?
En gros, je me pose la question, pour OSMAnd, de savoir si on doit attendre une mise à jour Android, ou OSMAnd…

Démarche intéressante. Il est vrai qu’IPv6 change la donne à ce niveau. Mais encore faut-il que ton PC soit allumé quand tu n’es pas chez toi… Et un PC, c’est gourmand comparé à un petit serveur dédié et pas cher ;-)

Certes. Après, c’est son journal, que tu n’es pas obligé de lire. Il ne s’agit pas d’une dépêche…

C’est la meilleure synthèse de cette question que j’ai vue jusqu’à présent (du moins pour les « individus », pas pour les entreprises).

Et pourtant, un bémol quand même : rien ne nous oblige à faire notre pause-repas à 12h UTC. Le fait que notre journée ne soit pas organisée symétriquement autours du repas de « mi-journée » n’a donc aucune incidence sur le choix du fuseau horaire.

Au final, l’impact du choix du fuseau horaire n’est qu’administratif : révision des horaires d’ouverture des lieux divers, horaires de trajets, etc. ; et donc également financier.

Ce qui me paraît le plus logique est l’heure ± solaire (celle du fuseau dans lequel on est), mais notre société s’organise sur des critères financiers et non logiques.

Quand à la solution UTC-pour-tous, elle est simple et attirante (et supprime le saut de jour actuel à la longitude 180°), mais soulève évidemment la question du choix de la référence universelle : pourquoi UTC ? Les américains voudrons certainement CST, les chinois je ne sais pas…

Ah… OK je comprends.

D’ailleurs, paradoxalement, je trouve que côté compta, c’est pas terrible sur Linux, en tout cas en disposition BÉPO : certains logiciels (LibreOffice, Gnucash, d’autres ?) sont… hyper-pointilleux dans le respect de la langue française. Du coup, si je saisis 9.81 sur le pavé numérique, c’est considéré comme invalide parce que j’aurais dû saisir 9,81 :-(

Pour le côté DIY, c’est pas faux :-)

Et pourtant, si, ça sert.
Là, on ne parle pas d’afficher en temps réel un jeu 3D, mais simplement d’effectuer un dépannage en ouvrant à distance un Firefox, un Thunderbird, un Gnucash, un Keepass, une quelconque appli de tableau de bord…
Ça fonctionne encore.

Sans me prononcer sur la taille que représentent 400 personnes, je suis cependant d’accord avec Ysabeau sur le fait que le mode de communication de Wikimedia ne passe pas… Je ne saurais dire pourquoi. Un décalage culturel peut-être.

Compta ?? Pas compris…

J’explique : il est fréquent qu’un mot de passe contienne des chiffres, et dans ce cas là, l’endroit le plus accessible sur un clavier complet, c’est le pavé numérique. Je vois tout le monde autour de moi utiliser le pavé numérique ainsi.

Alors, oui, les français sont particulièrement touchés, mais il ne sont pas les seuls, car AZERTY n’est pas limité à la France. De plus, les ordinateurs portables sont concernés aussi, en taille 17″ ou supérieure.

Et il ne faut pas négliger la part de marché importante des PC un peu anciens, des gamers, bref… tous ceux qui pour une raison ou une autre utilisent un PC fixe.

Probablement pas.
Avant, le filtrage en entreprise, en gros c’était : HTTP ça va ; FTP, SMTP, IMAP, XMPP, etc. refusés. Et HTTPS… c’est compliqué, alors oui ou non selon là où on bossait.

Puis 2 choses sont arrivées :

1. Le contenu HTTP s’est mis à migrer vers HTTPS, et au lieu d’avoir HTTPS pour les banques et autres sites « sérieux » (c’était en fait un préjugé), on s’est mis à avoir HTTPS pour tout, y compris les loisirs, sites sociaux, etc.

2. HTTP(S) s’est mêlé de la messagerie avec les webmails, du transfert de fichiers directement en HTTP, de la messagerie instantanée (et assimilée : Facebook, etc.), des jeux, des bureaux distants, et j’en passe.

Les administrateurs de réseau n’ont donc pas eu d’autre choix que d’inspecter le HTTP et le HTTPS, pour savoir si c’est du HTTP normal ou de la messagerie (ex-SMTP/IMAP), ou du transfert de fichiers (ex-FTP), ou encore autre chose…

Oui, c’est ça. Dans les cas que je rencontre, ça marche bien. Je combine souvent avec le bit “s” sur le groupe principal.

Il est vrai que dans d’autres cas d’usage (notamment avec des fichiers qui se promènent beaucoup), il peut y avoir le problème que les ACL sont appliquées à la création, pas en cas de déplacement de fichier…

Avec parfois des conséquences : chez mon FAI (Bouygues), si je me connecte au SMTP depuis chez moi, j’ai 2 possibilités:

1. soit le port 25 de manière anonyme (ils vérifient juste que c’est une de leurs lignes DSL) ;
2. soit le port 587 authentifié.

A priori, j’aurais tendance à préférer le second, qui a en outre l’avantage de fonctionner aussi depuis pas-chez-moi. MAIS :

1. sur le port 25, je peux envoyer ce que je veux, notamment les mails de mon propre nom de domaine, en mode « smarthost » d’Exim ;
2. sur le port 587, seuls les alias@bbox.fr sont acceptés, sinon : « Sender address rejected: not owned by user monAdresseBouygues@bbox.fr »