Microsoft, Exchange, Outlook Web, et non respect des standards IMAP

Dans un environnement Microsoft Exchange, lorsque vous changez la langue d’utilisation via Outlook Web, cette opération va changer le nom des dossiers spéciaux sur le serveur, ce qui amène à une belle fantaisie.

IMAP recommande pourtant que ces dossiers spéciaux restent en anglais sur le serveur, et que ce soit le logiciel client qui fasse la traduction au vol.

Microsoft n’en a cure, et depuis toujours (Outlook Express, Windows Mail) il va créer des nouveaux dossiers sur le serveur, quitte à perturber complètement le fonctionnement des autres appareils connectés à la même boîte mail.

Avec Exchange il y a un petit mieux. L’utilisateur la le choix de renommer ou non les dossiers spéciaux, et cette option est cochée par défaut. Peut-être n’est-ce pas le bon choix.

Voyez en images. Il s’agit d’une boîte mail chez OVH, accédée simultanément en IMAP avec Thunderbird, et via le Webmail qui est Outlook Web.

Cette boîte est configurée en anglais mais a déjà été utilisée en français dans le passé.

Voici avant le changement:

Voici comme se présente la boîte mail depuis Thunderbird

A partir du webmail OWA, changement de la langue vers le français

hé bien non c’est impossible, il reste des traces qui empêchent ce changement !

Choisissons le néerlandais alors

et voyons ce que ça donne sur Thunderbird après un refresh… mais quel bazar !!

Mais pourquoi ne voit-on pas les dossiers fantômes sur le serveur ?

J’ai pu remettre en anglais, mais Thunderbird “voit” toujours les dossiers en néerlandais ET ceux en anglais…

Collection de liens

Cet article est destiné à être en évolution permanente.

Outils Internet-Webmaster-etc.

  • Pingdom Tools (http://tools.pingdom.com) : Analysez le temps de réponse de votre site Internet
  • Google Tools (Pagespeed Insights) : Analysez la qualité globale de votre site Internet, tel qu’il est vu depuis un PC et/ou un mobile
  • Cliparts, parfois complètement kitsch: Korben
  • Vérifiez si l’adresse IP de votre serveur mail est blacklistée:

1. http://MultiRBL.Valli.org
2. http://JustSpam.org
3. http://BlacklistAlert.org/ 

  • Retrouvez l’historique des adresses IP sur lesquelles un site a été hébergé: viewDNS.info
  • Wormly (https://www.wormly.com/tools) : Vérifiez si votre serveur SMTP est correctement configuré. Vérifiez si votre site SSL possède des certificats corrects et utilise les bonnes options TLS, et pas de SSL v2 v3, etc.
  • Carte mondiale des câbles sous-marins submarinecablemap.com
  • SSLLabs : Vérifiez si votre site SSL est bien conforme aux standards du protocole.
  • imirhil : permet aussi de tester SSL sur d’autres ports que 443
  • Testez la validité de votre DNS et DNSSEC via zonemaster.net
  • Comment StartSSL, une boîte israélienne fournissant des certificats SSL gratuits ou bon marché, a été rachetée incognito par des Chinois qui ont cru pouvoir faire n’importe quoi dans ce monde très strict des autorités de certification: article de Arstechnica.
  • DNSViz va analyser l’exactitude de votre zone DNS. Notamment détecter les anomalies DNSSec.
  • Comment écrire mon nom sans aucun caractère latin ? FᚱēⅾēᚱᎥс Ꭰе Ⅿееѕ http://www.irongeek.com/homoglyph-attack-generator.php
  • SIte WordPress piraté ? Voyez cet article de Sucuri
  • QR code generator: https://goqr.me/

Vie Privée

http://www.youronlinechoices.com/fr/controler-ses-cookies/

Plongée sous-marine

Aviation

  • orbifly.fr (lien vers la page météo de ce site d’écolage d’aviation aux instruments)
  • buienradar.be (lien vers un site hollandais qui annonce les précipitations)

Linux Tools

Windows stuff

Installer NextCloud sur un hébergement mutualisé Perso chez OVH

Dans ce tuto, nous allons installer NextCloud version 24.0.0.12 dans un hébergement mutualisé OVH de type ‘perso’.

NextCloud est un applicatif écrit en PHP et il utilise une base de données pour pouvoir fonctionner.

L’hébergement mutualisé Perso OVH dispose de 100 GB d’espace disque, dont on va utiliser ½ GB pour NextCloud lui-même, et une base de données MySQL de 200 MB dont environ 10 MB vont être utilisés dès le départ par NextCloud.

L’installation présuppose que vous êtes familier avec les hébergements OVH, et qu’il n’y a pas déjà une installation NextCloud dans cet hébergement.

Vous êtes supposé être capable de :

  • créer un nouveau site via la page ‘multisite’ de l’espace client,
  • activer un certificat SSL sur ce site
  • utiliser un client FTP comme FileZilla,
  • utiliser le protocole sftp plutôt que ftp,
  • créer une base de données MySQL
  • ou utiliser une base existante et en récupérer le mot de passe

Afin de ne pas alourdir inutilement le texte, les instructions qui y sont relatives pourront être concises.

Pour cet exemple, j’ai même utilisé l’hébergement Perso d’un autre domaine que celui qui nous intéresse:

Ce hébergement existe depuis 2008, ce qui explique la présence de fichiers portant cette date.

Voici la liste des fichiers via FTP:

On peut y voir ‘www’ et ‘drive’, qui sont les ‘dossiers racine’ des deux sites hébergés sur cet hébergement.

J’ai aussi créé ‘drivedata’ qui est destiné à contenir les fichiers utilisateur de NextCloud. Je recommande que ce répertoire ne se trouve dans aucun des dossiers racine des sites hébergés. Ainsi aucun site n’y a accès, en-dehors de NextCloud ou d’une autre application PHP hébergée.

Passons aux préparatifs sérieux.

Configurez l’hébergement avec la version la plus récente de PHP, actuellement stable64 et PHP 8.1.

Configurez le multi-site, afin que votre cloud ait une adresse unique (p.ex. drive.example.com mais pas www.drive.example.com)

N’activez pas le firewall. Activez les logs séparés ou non, selons vos désirs. Activez SSL, puis allez dans la page générale pour regénérer le certificat.

Téléchargez depuis https://nextcloud.com/install/#instructions-server

Vous allez recevoir un téléchargement du fichier ‘latest.zip’ (143 MB à la date de rédaction 15/05/2022, version 24.0.0.12).

Dézippez-le : 346 MB, 19500 fichiers et 3200 dossiers.

Il faut maintenant ‘pousser’ tout le contenu dans votre hébergement FTP, dans le répertoire /drive si vous avez suivi mon exemple. Ca prendra “un certain temps” ou “un temps certain”. A la fin vous aurez ceci :

Pendant que ça copie, vous pouvez préparer la base de données.

Vous devez être en possession de 4 paramètres (adaptez nomdelabase):

  • serveur: nomdelabase.mysql.db
  • base de données: nomdelabase
  • utilisateur: nomdelabase
  • mot de passe: vous seul le connaissez

Si cette base existe déjà (par exemple pour un site WordPress déjà présent) voyez dans les fichiers de configuration quels sont ces 4 paramètres (dans le cas de WordPress, vous pouvez consulter wp-config.php). Ne changez pas le mot de passe via l’espace client, car vous rendriez ce site inopérant.

Maintenant, lorsque la copie est terminée, vous pouvez visiter votre site en appelant son adresse définitive dans un navigateur (avec votre nom de domaine et https)

Vous devrez préciser une série d’informations ET ABSTENEZ-VOUS D’APPUYER sur ENTER ou de cliquer OK tant qu’on n’a pas rempli tous les champs:

  • login et mot de passe du futur admin
  • sélection de MySQL/MariaDB –> complétez les 4 paramètres nécessaires
  • sélection du répertoire data (je conseille /drivedata plutôt que /drive/data, voyez plus haut)

L’installation commence, et se termine sur un magnifique “Gateway Timeout”.
Attendre 5 minutes et se reconnecter à l’adresse du site.
Tout semble être là et parfaitement opérationnel.

Connectez-vous avec le compte admin.

Dans les réglages:

  • Administration > Paramètres de base, serveur e-mail: mode d’envoi “Sendmail”
  • Personnel > Informations personnelles > mettre une adresse mail > vous devriez recevoir un mail
  • Applications (depuis le menu à droite) > Pack d’applications
    Eventuellement ajouter “Calendar” et “Contacts”.
  • Aller dans la gestion des utilisateurs ; créer un ou des groupes ordinaires et créer des utilisateurs non privilégiés dans ce groupe.
  • A partir de maintenant traviller exclusivement avec ces utilisateurs non privilégiés.

L’installation n’a pas été testée en profondeur dans des conditions réelles.

Considérez ceci comme une facilité à usage personnel.

N’allez jamais construire un cloud dans un tel hébergement web mutualisé, et qui deviendrait peu à peu un élément critique pour votre activité professionnelle.

Lors de mes essais, j’ai pu charger plusieurs centaines de photos et des vidéos pesant jusqu’à plus de 260 MB, alors que phpinfo() me dit: post_max_size 130M et upload_max_filesize 128M. C’est encourageant.

Bientôt la version de MySQL 5.6 proposée par OVH ne sera plus supportée par NextCloud, un jour ce sera autre chose, etc.

Sachez aussi qu’en ultime recours, vous trouverez :

  • les fichiers dans le répertoire ftp /drivedata
  • les événements Calendar sont dans la table `oc_calendarobjects`, dans le champ [blob] calendardata
  • de même les contacts se trouvent dans la table `oc_cards`, dans le champ [blob] carddata

SPF, DKIM, DMARC, petit rappel

Bonjour,

Je fais ici un petit rappel de théorie.

SPF, DKIM, DMARC, ça sert à quoi ?

Ces protocoles sont destinés à authentifier les e-mails émis par les utilisateurs de votre domaine . Ils n’empêchent pas la falsification (quelqu’un qui se fait passer pour vous ou vos collaborateurs) mais ils aident à les contrer d’une manière relativement efficace.
En fin de compte c’est le serveur en réception qui va consulter ou non vos directives (SPF, DKIM, DMARC) et éventuellement rejeter le mail falsifié si vous avez donné instruction qu’il fallait les rejeter.

OVH implémente SPF.
OVH n’implémente pas DKIM, ce qui en 2022 est assez inacceptable.
DMARC ne devrait pas être conseillé si vous n’avez pas DKIM. Chez OVH je le déconseille donc.

SPF sert à publier les adresses IP des serveurs qui sont autorisés à émettre des mails de votre domaine (typiquement ce sont les serveurs d’OVH. Si vous faites appel à une société extérieure pour des mailings, il faudra ajouter leurs serveurs)
Le SPF est publié dans votre zone DNS, dans un enregistrement TXT.

DKIM authentifie sur base d’une signature numérique dans les en-têtes SMTP, vous ne la voyez habituellement pas. A toute clé numérique il y a une partie privée (dans le cas de DKIM: détenue exclusivement par votre serveur mail d’envoi), et une partie publique, publiée dans votre zone DNS.
Le serveur en réception consulte la clé publique dans votre zone DNS pour vérifier la signature électronique du mail reçu. Si ça colle, alors le mail est authentique, quelle que soit l’adresse IP du serveur qui l’a envoyé.

Je rappelle que les serveurs d’envoi OVH n’insèrent pas de signature DKIM. Donc pas besoin de mettre une clé publique dans DNS non plus.

DMARC vous permet de donner des instructions aux serveurs en réception et comment ils doivent se comporter face à des mails qui échouent au contrôle SPF et DKIM. Le but est d’indiquer “si un mail échoue à SPF et DKIM alors il est frauduleux et il faut le refuser”.

Faire confiance à SPF tout seul est une loterie car un message qui fait l’objet d’une redirection ou via une mailing list sera considéré comme frauduleux, puisque l’adresse IP du serveur de l’émetteur n’est plus celle du domaine d’origine. (sauf si le redirecteur adhère à SRS, ce sera peut être l’objet d’un autre article !)

Scam sur Facebook, ne vous faites pas avoir !

Annonce sur Facebook : Un appareil à 1 euro chez Media Markt !  Assurément une offre bien trop alléchante pour être vraie !

Le lien mentionne un site qui n’est nullement Media Markt. Il me donne envie de cliquer dessus, rien que pour voir ce qu’ils vont encore inventer comme arnaque cette fois-ci.

Le résultat est au-dessus de mes espérances: une fausse page “vous avez été infecté par un Trojan Spyware”. Voyez plutôt… c’est tout du bidon… sauf le numéro de téléphone auquel les racailles attendent le pigeon pour mieux l’escroquer.

Capturé le 09/12/2021

The 2020 Web Almanac

Voilà une compilation d’informations à garder en référence.
https://almanac.httparchive.org/en/2020/

Par exemple prenons le chapitre 11 sur la sécurité des sites Web. C’est d’une précision rarement atteinte dans tout ce que j’ai pu lire jusqu’à aujourd’hui.

https://almanac.httparchive.org/en/2020/security

Voici la table des matières de ce chapitre 11, capturé le 11 décembre 2020:

IndexIndex

    Introduction
        Methodology
    Transport security
        Protocol versions
        Cipher suites
        Certificate Authorities
        Browser enforcement
            HTTP Strict Transport Security
    Cookies
    Content inclusion
        Content Security Policy
        Subresource integrity
        Feature policy
        Iframe sandbox
    Thwarting attacks
        Security mechanism adoption
        Preventing XSS attacks through CSP
        Defending against XS-Leaks with Cross-Origin Policies
        Web Cryptography API
        Utilizing bot protection services
    Relationship between the adoption of security headers and various factors
        Country of a website's visitors
        Technology stack
        Co-occurrence of other security headers
    Software update practices
        WordPress
        jQuery
        nginx
    Malpractices on the web
    Evolution & conclusion

Domoticz, Zigbee, Sonoff, Tasmota, Raspberry Pi…

Ca fait un bail que je suis resté silencieux à propos de mon installation Domoticz (voir ici)

Pour rappel mon Domoticz tourne sur un Raspberry Pi 3B équipé d’un adaptateur PiZiGate, et mes périphériques sont: IPX-800, divers Sonoff, et des bidules Zigbee.

Entre-temps j’ai acheté un petit SSD (32€) et un adaptateur USB2-SATA (7€). En effet je n’ai pas envie d’attendre que la carte micro-SD de 8GB me claque entre les mains en raison de sa lente et inévitable usure.

J’ai installé un détecteur de fumée Zigbee, la transmission d’alerte par Telegram fonctionne.

Le dernier Sonoff Basic R2 que j’ai acheté n’a pas voulu fonctionner avec ESPeasy. Du coup j’ai essayé Tasmota et je l’ai adopté.

Enfin nous avons commandé des stores, et j’ai demandé une livraison avec moteur classique commandé par fil (et non avec une télécommande propriétaire Somfy). En attendant la livraison et l’installation, j’ai déjà préparé la commande à distance.

Pour chacun il y aura un relais Wifi à 2 canaux avec relais inverseurs à contact sec, avec la ferme intention de les flasher avec Tasmota comme j’ai fait précédemment avec les derniers Sonoff. Et surprise, alors que la photo montrait clairement les petits trous dans le circuit imprimé pour y brancher un câble série, le modèle que j’ai reçu en fait défaut !

Déception ! Du coup je me suis intéressé à piloter Domoticz > IFTTT > eWelink > relais et j’y suis arrivé avec un certain succès. Sauf que… eWelink est payant si on veut l’interfacer, statut VIP 10$/an ; et IFTTT est devenu payant si on veut avoir plus que 3 scripts, statut Pro 2$/mois !

Tout ça pour avoir un relais qui s’actionne avec 5 secondes de retard, voire plus, et être à la merci d’une défaillance de l’accès internet, de IFTTT, et/ou de eWelink. Payer et devoir dépendre des autres, non merci ! C’est l’occasion de rappeler tout le mal que je pensais de l’application eWelink qui demande de se foutre (virtuellement) à poil devant son appareil.

Après d’intéressantes lectures sur internet, notamment de data sheets du PSF-B04 en chinois (identification du chip en montage surélevé), je sors mon fer à souder équipé de sa panne la plus fine, pour souder 4 fils dont deux sur des pattes de circuit de 1 mm de large. Ceci me donne accès à GND (zéro volt), Vcc (+3.3) et les classiques TX et RX. Et hop, ça y est Tasmota est flashé dans l’appareil !

 

Je déclare cet appareil comme un Sonoff 4CH Pro même s’il n’a que 2 sorties.

Au niveau du câblage qui est prévu pour le store électrique, le relais 1 amène le courant ou le coupe, et le relais 2 est utilisé comme inverseur pour activer un moteur ou l’autre. Il est donc impossible de commander à la fois la montée et la descente, et il ne faut pas dépendre d’une fonction “interlock” du relais.

A ce stade, on peut commander les relais au moyen de la télécommande RF433 qui est livrée avec (si on a choisi ce modèle bien sûr), ou bien avec les boutons sur l’appareil, ou bien à partir de la page Web Tasmota à l’adresse IP où il se trouve. C’est peu convivial et uniquement une solution de secours.

On va lui ouvrir l’horizon. Dans Domoticz, on déclare 2 switches on/off virtuels à partir de Setup > Hardware > Virtual Sensors, et pour ces 2 switches, on leur donne un nom à chacun et la commande HTTP qui actionne le switch (ou MQTT pour ceux qui l’ont implémenté).

 

[Edit: avec MQTT configuré sur Tasmota, les On et Off Actions sont superflues]

On peut maintenant créer une ou plusieurs scènes où on va actionner ces switches pour en faire ce que l’on veut.

J’ai commandé des boutons Zigbee (ici ou ici ou autre modèle ici)

et la petite notice en chinois bien sûr, ici la page qui montre comment l’ouvrir pour changer la pile

Appairage:

Ces boutons différencient le simple clic et le double-clic. Celui-ci supporte aussi le triple et quadruple-clic, tandis que d’autres modèles reconnaissent un appui long. Je vais utiliser le simple-clic pour actionner le store (en inversant le sens) et le double-clic pour un arrêt immédiat. J’ai essayé avec des scènes et des scripts Blockly sans y arriver. Finalement un script dzVents de quelques lignes fait le travail à merveille

return {

   on = { devices = { 94 }},        -- idx of button

   execute = function(dz, item )
           dz.log("state of " .. item.name .. " is " .. item.state)
           if item.state == "1 Click" then
            dz.devices(73).toggleSwitch()    -- idx of up/down switch
            dz.devices(72).switchOn()      -- idx of power switch
        elseif item.state == "2 Click" then
            dz.devices(72).switchOff()    -- idx of power switch
        end
   end
}

Un mot d’explication:

Si le bouton idx=94 est activé, le script est exécuté. Si l’état est “1 Click” alors on inverse le switch2 (idx=73) pour monter/descendre et on allume le switch1 (idx=72) qui donne l’alimentation électrique. Lors de l’action “2 Click” (arrêt du store) le switch 1 est éteint.

En outre un timer de 17 secondes avait été mis sur le switch1, à régler quelques secondes de plus que l’ouverture ou la fermeture complète, ainsi on ne laisse jamais le store sous tension en permanence.

A remarquer que l’utilisation directe des boutons sur les relais, ou des télécommandes RF433 n’informent pas Domoticz de cette action. Une commande MQTT telle que ‘domoticz/in’ avec un payload ‘{ “idx” : 72, “nvalue” : 0}’ permet de changer l’état dans Domoticz sans que Domoticz n’envoie en écho (et possiblement en boucle infinie) un ordre d’extinction au relais.

Au niveau de Tasmota, avec les configurations MQTT et Domoticz complétées, plus aucun échange en http n’est encore nécessaire. La réactivité est bien meilleure et fiable dans les deux sens.

 

A propos des e-mails, S/MIME, chiffrement, signature

S/MIME permet de signer un e-mail, et/ou d’encrypter (le mot correct est: chiffrer) à des destinataires connus. Ceci se fait avec des certificats, clés privées tout comme pour les sites web https ou signer du logiciel.

Le mail signé apporte une preuve d’authenticité, de non-falsification et de non-répudiation
– authentique: le certificat de la personne ou entité qui a signé est attaché au mail signé. Une autorité (par exemple Comodo) a délivré ce certificat à une personne, une société… en vérifiant l’identité et l’adresse e-mail de cette personne. La signature possède aussi la date et l’heure de l’ordinateur utilisé.
– non-falsification: un hash (check-sum) est calculé sur l’entièreté du mail, et c’est le hash qui est signé. Si on n’enlève ne fût-ce qu’une virgule, la signature est invalidée.
– non-répudiation(*): Sur base de cette signature on peut attester qui a signé et quand, et la personne qui a signé ne peut pas se rétracter.

(*) selon le certificat qu’on a acquis

Pour l’encryptage, pourquoi destinataires connus ? Parce qu’envoyer un message encrypté à un destinataire inconnu n’a simplement pas de sens.

S/Mime agit au niveau des clients mails (logiciels de mail) et non au niveau des serveurs. On parle de sécurisation de bout en bout.
Au niveau des serveurs, un message signé et/ou encrypté est juste un message comme un autre, pouvant contenir des sections relatives à S/Mime.

Il y a une quinzaine d’années, il y a eu Thawte (sud-Africain) qui a proposé des certificats gratuits pour faire du mail. Ils ont arrêté cette offre.

Il y a une dizaine d’années StartCom StartSSL a fait quelque chose de similaire, puis StartSSL s’est fait racheter par des Chinois, sans rien annoncer au public. Les Chinois ont merdé avec des pratiques inacceptables (production de certificats anti-datés, etc, donc faux en écriture) et ils se sont fait bannir, plus personne n’a reconnu les certificats qu’ils émettaient. Ils ont mis la clé sous le paillasson début 2018.

Il y a aussi eu notoirement Comodo, mais là c’est fini aussi.

Depuis, pour trouver un certificat gratuit émanant d’une autorité de certification il faut se gratter.

La carte d’identité belge permet de signer numériquement des documents, par exemple via Adobe Reader, mais ne permet pas de signer un e-mail. En effet la Belgique atteste de votre identité, mais absolument pas que votre adresse e-mail correspond à votre personne.

Lecture: http://kb.mozillazine.org/Getting_an_SMIME_certificate

Alternative, faire son propre CA et générer ses certificats soi-même,
Comme l’échange encrypté ne s’improvise pas, on peut envoyer ses certificats à ses correspondants par un autre moyen que le mail et on se fait confiance réciproquement. Ca fonctionne.

Signer avec un certificat qu’on a fabriqué soi-même n’apporte de la valeur ajoutée qu’auprès des correspondants réguliers qui peuvent enregistrer le certificat dans leur registre d’émetteurs de confiance.

Alternative: regarder du côté de gpg, système anarchique (sans autorité centrale) et qui fonctionne via un réseau de confiance.

Noter qu’aucun webmail ne peut valablement sécuriser vos e-mails car l’admin du webmail peut être le maillon faible.