:D

Bien utile quand un shell interactif (shell Oracle, MySQL, ...) n'implémente pas les fonctionnalités de base comme l'historique des commandes et les raccourcis clavier : ledit (line editor) agit comme un wrapper et implémente ces fonctionnalités essentielles.

ÉDIT DU 12/07/2015 à 11h05 : Benvii me signale que rlwrap est quand même plus mieux meilleur vu qu'il fonctionne aussi via telnet. FIN DE L'ÉDIT.

Pas mal. :')

1) « Dans le cadre d'un projet du laboratoire d'innovation, les experts de la CNIL ont développé Cookieviz ». Innovation en France = réinventer la roue. Non parce que voir un graphe des cookies trackers, ça se fait tout aussi bien depuis quelques temps avec l'extension Collusion (Lightbeam depuis, https://www.mozilla.org/en-US/lightbeam/) pour Firefox par exemple.

2) Le plus beau est le tutoriel vidéo proposé :
    a) Dans la barre personnelle du navigateur : « PhpMyAdmin », « SQL ORDER BY », « SQL CREATE TABLE ». La messe est dite : je ne suis pas surpris des vulnérabilités de type SQL injection et XSS découvertes (http://seclists.org/fulldisclosure/2014/Nov/3). En 2014 ... allo ?!

    b) Faire une recherche, d'une, sur Google, de deux, pour aller consulter le site web du Wall Street Journal ... Dans un tutoriel de la CNIL ... Non mais allo. Effet de prescription toussa :'(

Via : http://seenthis.net/messages/308591

« Ainsi, l’étude Data Miles, réalisée à partir d’un sondage organisé en août 2014 sur la plate-forme communautaire Tonula auprès de 4000 personnes (dont 1000 en France) utilisant les transports en commun, révèle que chaque employé quitte son bureau avec 470 Go de données en moyenne. Soit mille fois plus que le volume qu’il échange sur Internet dans le même laps de temps, selon le rapport prévisionnel Cisco VNI 2013-2018. A titre d’exemple, chaque jour, pas moins de 350 pétaoctets de données (350 millions de Go) transitent physiquement par la seule ville de Paris qui reste bien modeste en regard des 1,4 exaoctets (1400 Po) de New York. Le métro parisien en transporte à lui seul 138 Po quotidiennement.

Des volumes impressionnants qui resteraient anecdotiques si les risques qui accompagnent leur circulation physique ne constituaient pas un réel problème. De fait, l’étude estime que 41% des utilisateurs ont perdu un appareil contenant des données de l’entreprise au cours des 12 derniers mois. « D’énormes quantités de données professionnelles sont en péril aux heures de pointe », note l’étude un brin alarmiste. En région parisienne, c’est sur le RER A, entre Cergy (Val d’Oise) et Paris, que la densité de données qui empruntent les transports en commun est la plus soutenue (45 Po). »

Ces chiffres sont intéressants en eux-mêmes mais à prendre avec des pincettes : « Mozy la solution de sauvegarde en ligne simple, automatique et sécurisé pour les entreprises et particuliers. » ... Le côté alarmiste de cette étude en prend un coup.

Via : http://seenthis.net/messages/308652

Encore faut-il avoir assez d'espace libre sur le système de fichiers pour pouvoir installer Unbound, c'est tout mon problème sur un WRT54GL :'(

Via : https://twitter.com/fcambus/status/529572131303333888

« The Name Service Switch (NSS) configuration file, /etc/nsswitch.conf, is used by the GNU C Library to determine the sources from which to obtain name-service information in a range of categories, and in what order. Each category of information is identified by a database name. »

Pour bypasser le fichier /etc/hosts (sauf localhost ;) ), il faut indiquer « hosts: dns » dans ce fichier en lieu et place de « hosts: files dns ».

Pour bypasser /etc/services, « services: db » au lieu de « services: db files ». Même chose pour /etc/protocols.

« Là nous avons le cas de policiers qui, lors des enquêtes, récupèrent les photos de nus des téléphones et les partagent entre eux. Ils disent même que c'est un "jeu" parmi les officiers. Et ça fait des années que ça dure.
NON, ce n'est pas un jeu, c'est inacceptable.

(Et si vous croyez que les employés de Facebook, Google, Apple, Snapchat et autres ont un standard de moralité plus élevé que la police, ma fois, ce n'est pas qu'un doigt que vous vous fourrez dans l’œil.) »

« Le raid matériel est très performant, les contrôleurs sont très chers, les groupes raid créés ne sont pas “portables” sur un autre type de contrôleur (en cas de panne, de changement de matériel…). Le raid matériel est totalement transparent pour l'utilisateur et le système. Le “fake raid” n'a aucun avantage sur le raid logiciel, il est même moins souple et pas plus performant. Son seul atout pourrait-être une relative “transparence” pour l'utilisateur. »

+ une liste des commandes utiles et indispensables.

ÉDIT DU 19/11/2014 à 17H55 : pour ceux qui se demandent pourquoi .xyz arrive en tête : « Contestation des chiffres du .xyz : NetworkSolutions en enregistre d'autorité pour ses clients. #lesChiffres #RINDD [NDLR : Rencontres Internationales des Noms de Domaine 2014] ». Source : https://twitter.com/bortzmeyer/status/534996806258950144 FIN DE L'ÉDIT.

Il y a tellement de mises en prod' le vendredi à 16h un peu partout que ça ne veut plus rien dire le "ho noooon on ne met rien en prod' le vendredi". M'enfin bref ...

Un exemple de plus d'altération du trafic par un FAI ... Adieu, neutralité des réseaux. Ça me rappelle la pub incrustée sur les sites web à l'époque du 56k (ou celle remplacée par celle de la régie affiliée au FAI, c'est bien pareil) et les récursifs-cache DNS menteurs.

Via http://sebsauvage.net/links/?3O14uA

« J'utilise ici le terme “hacking” dans son sens noble: Comprendre le fonctionnement et modifier pour l'adapter à ses besoins.

Je vais donc décrire ici la manière d'examiner et modifier une application Android (fichier .apk). La motivation est double:
    - S'amuser à bidouiller et comprendre le fonctionnement des applications (en particulier le code machine Dalvik d'Android).
    - Protéger sa vie privée en coupant certaines fonctionnalités des applications (géolocalisation, etc.) »

J'ai voulu tester Gogs, réputé plus léger que Gitlab.

Pour l'installer, plusieurs méthodes sont possibles : sources, binaires ou dépôt apt. J'ai choisi dépôt apt.

Les instructions : https://packager.io/gh/pkgr/gogs/install?bid=87#wheezy . C'est le minimum syndical puisqu'on utilise "root" pour se connecter à la base de données au lieu d'utiliser un compte dédié à gogs. Bon, on peut toujours améliorer soi-même mais je trouve que la sécurité devrait être beaucoup plus prise en compte dans les instructions d'installation surtout quand elle n'est pas complexe à déployer.

IMPORTANT : à la fin complète de l'installation, il faut : ln -s /etc/gogs/conf/app.ini /opt/gogs/custom/conf/app.ini (mieux qu'un cp car, comme ça, vous avez un seul fichier à modifier). Sans ça, il est impossible d'utiliser les fonctionnalités git (clone, push, ...). L'utilisateur voit : « fatal: protocol error: bad line length 8208 », « fatal: The remote end hung up unexpectedly » et dans les logs (/var/log/gogs/serv.log), on a « Fail to execute git command: exit status 128 » O_O

C'est assez curieux. Le fichier /etc/gogs/conf/app.ini est utilisé par une partie de gogs mais pas par la commande « gogs serv » qui est celle lancé lors d'un git over SSH. Si on lance ce binaire à la main, il nous dit :
« [W] No custom 'conf/app.ini' found, please go to '/install'
Hi XXX ! You've successfully authenticated, but Gogs does not provide shell access. »
Évidemment, le warning n'a pas une valeur d'avertissement mais d'arrêt critique ...

Mon avis sur Gogs ? Plutôt négatif.
    + Plus léger que Gitlab, c'est clair.

    - Codé en Go ... Juste N-O-N ... Après les serveurs XMPP en erlang/lua, voici venu un code en Go sur nos serveurs de prod'. Juste N-O-N.

    - C'est en rolling release (dev' continu). Donc les màj via apt fusent (on peut toujours géler le package gogs, http://shaarli.guiguishow.info/?TccM8g, mais c'pas le top), les versions aussi, ... On ne peut pas avoir une branche stable avec juste les màj des sécu ? C'est le minimum pour un environnement de prod' bowdel.

    - Le code n'est pas clair, surtout dans la version packagée : un warning qui devrait être un critical, un fichier de conf' utilisé par une partie du code, un autre fichier de conf' par une autre partie du code, ...

    - Des templates pas super bien conçus, particulièrement celui de la page d'accueil. Et si je veux changer le titre (<h1> et <h2>, pas <title>) ? Tout comme pour <title>, une variable de config devrait être proposée.

Merci à Nath96 (http://www.nath96.netlib.re/) pour la motivation à essayer ce bouzin et pour le debug. :)

« Multiple security issues have been found in Iceweasel, Debian's version of the Mozilla Firefox web browser: Multiple memory safety errors, buffer overflows, use-after-frees and other implementation errors may lead to the execution of arbitrary code, denial of service, the bypass of the same-origin policy or a loss of privacy.

[...]

In addition, this update also disables SSLv3. »

Jusque là c'est parfaitement légitime.

« This update updates Iceweasel to the ESR31 series of Firefox. The new release introduces a new user interface. »

WTF ?! Pardon ?! O_O Depuis quand une security update s'occupe d'autre chose que de sécurité ?! Une mise à jour de sécurité doit corriger les failles détectées, un point c'est tout. C'est ça pour moi, l'une des qualités de Debian stable : la production ne pète pas à la tronche de l'adminsys ! Quand bien même c'est l'interface graphique d'un des logiciels que j'utilise le plus sur mes machines hors prod'. Que j'apprécie ou pas l'interface Australis de Firefox n'entre pas en ligne de compte dans cette histoire. J'imagine qu'il y a une raison derrière (comme par exemple que la team Debian Security avait annoncé qu'elle n'allait plus s'occuper des navigateurs web car c'trop le bordel) mais quand même, je suis très déçu de voir ça.


ÉDIT du 01/11/2014 à 16h25 : même chose aujourd'hui avec le DSA 3061-1 sur Icedove :
« Multiple security issues have been found in Icedove

[...]

This update updates Iceweasel to the ESR31 series of Thunderbird. In addition Enigmail was updated to version 1.7.2-1~deb7u1 to ensure compatibility with the new upstream release.

Mozilla implemented TLS 1.2 in NSS version 3.15.1 and Thunderbird 31.0 uses this as the default. It won't fall back to older protocol versions.

This means every connection from Thunderbird/Icedove to a mail server will using TLS 1.2 with no fall back if you have configured TLS/SSL or STARTTLS for your connections. »

D'après mes tests, ce n'est pas aussi disruptif que ça en a l'air : en désactivant TLSv1.2 dans smtpd de Postfix, Icedove (configuré pour utiliser STARTTLS) accepte de négocier TLSv1.1 (cf le log Postfix :  « TLS connection established from <lala>: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) »). En désactivant TLSv1.2 et TLSv1.1, Icedove accepte de négocier TLSv1.0 . Je n'ai pas pu tester la partie IMAP/STARTTLS puisque Dovecot permet seulement de désactiver SSLv2, SSLv3 et TLSv1.  FIN DE L'ÉDIT.


ÉDIT du 08/12/2014 à 20h25 : même chose aujourd'hui avec Icedove qui ne supporte plus SSLv3 : « Due to the  BEAST vulnerability Icedove does not support SSLv3 encrypted connections by default any longer. ». C'est une bonne chose en soi mais est-ce à une màj de sécurité annoncée pour autre chose (cf le DSA ne parle pas de cette désactivation de SSLv3) de faire ce choix ? Par ailleurs, BEAST concerne aussi TLSv1.0 quand des ciphers CBC sont utilisés donc l'argument est un peu moisi ...  FIN DE L'ÉDIT.

« On a deux instances d'OpenDNSSEC, instance A et instance B, sur deux machines différentes. L'instance A signe déjà 4 zones. L'instance B, une seule. On souhaite factoriser et garder une seule instance OpenDNSSEC, c'est-à-dire basculer la zone de l'instance B vers l'instance A. Le serveur DNS qui fait autorité sur la zone ne change pas, lui, seule l'instance OpenDNSSEC derrière change.

Évidemment, durant cette transition, il ne faut pas casser (même temporairement) la chaîne de confiance ni faire un roulement des clés (le roulement planifié ayant eu lieu récemment, cette solution serait possible mais sans intérêt) sinon c'est trop facile et ce n'est pas fun. »

POODLE, tout comme Heartbleed en son temps, fait couler beaucoup d'octets dans les internets ces derniers jours. Je vais donner mon avis sur ce que je pense être un effet de mode et surtout, une précipitation.

Disclaimer :
    1) Je ne suis pas un security guru.
    2) Ce que je vais dire s'applique dans le cadre de petits serveurs (auto-hébergés ou non) sans trop de trafic et sans contrainte. J'veux dire que je ne tiendrais pas le même discours s'il s'agissait du site web d'une banque ou d'un site web d'e-commerce ou d'un site web à très fort trafic (sur la partie ECDSA versus RSA). On constate d'ailleurs que, dans ces contextes-là, la réalité est toute autre que celle que je vais décrire car il y a le côté opérationnel à prendre en compte : https://imirhil.fr/ssl.html ;)


Commençons par POODLE (voir, entre autres http://seenthis.net/messages/302666) : il s'agit d'une faille dans le protocole SSLv3, pas d'un bug dans une implémentation particulière (comme OpenSSL). Ça m'en touche une sans faire bouger l'autre dans le sens où TLSv1.0 c'est so 1999 et que SSL est déprécié depuis fort longtemps. C'est un problème humain (adminsys consciencieux) et opérationnel (gérer les vieux clients dans certains contextes comme banques/e-commerce, frilosité au changement, ...). Sur nos petits serveurs persos, ça devrait être désactivé sans soucis à moins que les parts de marché d'IE6, 3,8 % au niveau mondial et 0.8 % en France en septembre 2014 revendiquées par Microsoft (https://www.modern.ie/en-us/ie6countdown), la réalité doit être légèrement supérieure ainsi que des appliances/automates proprios désuets ne vous intéressent. Après si le raffut inutile de ces derniers jours permet des  prises de conscience, pourquoi pas ...




L'ennui, c'est que je vois, principalement sur IRC, des adminsys se questionner sur la conf' TLS de leurs logiciels serveurs, ce qui est une bonne chose comme je viens de le dire, mais en poussant le vice trop loin. Mon plus grand conseil sera le suivant : gardez la raison, ne faites pas n'importe quoi, n'affaiblissez pas vos confs en croyant les renforcer. La sécurité dans l'urgence ne marche jamais. N'écoutez pas aveuglément toutes les ressources sur le web, n'écoutez pas aveuglément un validateur quand bien même il est aussi bien foutu que celui de ssllabs (https://www.ssllabs.com/ssltest/) ! À ce sujet, voir, par exemple, l'illustration avec BEAST : https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat - « Unfortunately, the only way to mitigate the BEAST attack is to enforce the use of RC4 suites whenever TLS 1.0 and earlier protocols are used (which is most of the time at this point). I say "unfortunately", because very shortly after we had started requiring server-side mitigations, new research about RC4 came out and we found out that this cipher was much weaker than previously thought. The weaknesses were not of immediate concern, but it was clear that RC4 was on the way out. » :)


Parmi ces questionnements, on retrouve les questions liées au résultat du test (ssllabs ou autre) et des débats plus profonds : ECDSA ou RSA ? SHA-1 ou SHA256 pour condenser mon certificat ? Quelle liste d'algorithmes cryptographiques autoriser ? Je déploie DANE, HSTS et compagnie ? ... C'est un vice de raisonnement, à mon humble avis. La priorité, ce n'est pas de passer en ECDSA comme si RSA vivait ses derniers instants ou de passer immédiatement à SHA256 pour condenser son certificat ou de passer à RSA 4096 bits au lieu de 2048 bits parce qu'un validateur vous l'a *conseillé* (« When renewing, ensure [...] »). L'important à l'heure actuelle, à mon humble avis, et ça sera mon deuxième grand conseil, c'est de garder la confiance et pour ça, de ne pas générer d'erreurs du côté de l'utilisateur et pour ça, de ne pas casser vos certificats x509 et les configurations de vos logiciels serveurs. On corrige donc les failles bien actuelles comme Poddle et, si l'on en a la motivation, on durcit la conf' TLS de ses logiciels serveurs en douceur.


Je vais quand même donner mon avis sur ces questionnements, ça serait idiot de dénigrer au lieu de guider.
    - Courbes elliptiques (ECDSA) versus RSA : c'est un débat théorique qui amuse les cryptologues mais ça n'a aucune réalité pratique. Les limites de la cryptographie interviennent sur des choses beaucoup plus connes et concrètes (générateur de nombres pseudos aléatoires pas assez aléatoires, bug logiciel, cryptographie mal utilisée (de la crypto avec IE6 sous XP, comment dire ...), ...) Les deux procédés sont toujours d'actualité. Le seul argument de plus en faveur des courbes elliptiques est leur faible taille (à niveau de sécurité jugé équivalent) et des temps de traitement plus courts donc une montée en charge des sessions TLS avec de nombreux clients facilitée. Les algos ECDHE-* sont moins gourmands que leurs homologues DHE-*. Sur des serveurs persos, ce gain n'a pas d'intérêt. Ce n'est pas pour autant que je crache sur ECDSA. Quant à utiliser les courbes elliptiques dans les certificats x509, le gain est encore moins évident : la validation du certificat se fait au début de la session TLS, pas en continu et sur le client (usage standard). Ne cassez pas vos certificats actuels parce qu'on vous a dit que RSA c'est fini à cause de POODLE, ça serait contre-productif !


    - SHA-1 / SHA256 comme fonction de condensation dans les certificats x509. SHA-1 sera peut-être dans les prochains algos cryptographiques à tomber donc il faut préparer la migration vers mieux (SHA256) mais, pour l'instant, on n'a aucune attaque efficace et imminente contre SHA-1.  Alors oui, je sais, le méchant Google a annoncé qu'ils vont favoriser de pas beaucoup les sites web accessibles en HTTPS puis qu'ils vont virer SHA-1 à eux tous seuls (voir : http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html) ... Tout ça pour se racheter suite aux révélations de Snowden, ce qu'il ne faut pas faire. :)

        1) On ne panique pas et je ne suis pas seul à tenir ce discours :  https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know . De plus, Google vont pénaliser d'abord les certificats auto-signés, ne nous faisons pas d'illusions donc SHA-1 versus SHA256, ça se place là dans l'ordre des priorités quoi.
        2) Google est-il vraiment indispensable pour la survie de nos sites web persos pas monétisés ?
        3) On regarde les certificats des AC (oui, toute la chaîne de confiance doit être SHA256, pas que les certificats finaux, sinon c'est stupide) présents dans le magasin de certificats Debian (ça serait pareil avec celui de Mozilla, juste ce check s'automatise bien) et on voit que la messe est dite :
                Total : 960 - 100 %
                        md5 (/!\ depuis le temps que MD5 est *mort* ce qui n'est même pas encore le cas de SHA-1)  : 66 - ~ 7 %
                        sha1 : 744 - 77,5 %
                        sha256 : 114 - ~ 12 %
                        sha384 : 36 - 3,75 %

        Donc, passer à SHA256 lors du prochain renouvellement normal de votre certificat (car il va expirer), c'est une bonne idée, bien sûr. Dans le contexte actuel, crise/peur (avérée ou imaginée, ça revient au même), c'est une mauvaise idée pour si peu : maintenir la confiance est primordiale (surtout avec les certificats autosignés ou AC autosignée) comme je l'ai écrit plus haut.


    - Je pense le plus grand bien de DANE (voir http://shaarli.guiguishow.info/?y6WIyg) mais déployons déjà DNSSEC (qui est un pré-requis) convenablement, avec des procédures (roulement des clés) éprouvées et on pourra ensuite se mettre à DANE. Il n'y a aucun serveur/client dans sa branche stable (au sens Debian, lala :D) qui utilise ces enregistrements donc rien ne presse : le gain de sécurité ne sera pas imminent. Mais là encore, ajouter ça sur sa TODO des choses à faire à moyen terme est une bonne idée.


    - HSTS (voir : http://www.bortzmeyer.org/6797.html) est encore une bonne idée. Mais réfléchissez bien avant de déployer : la configuration doit être parfaite car la moindre erreur est bloquante et mise en cache quand on active HSTS ! Par ailleurs, les certificats autosignés génèrent des erreurs donc ça va plutôt mal se passer avec HSTS.


    - Faut-il tuner le cache des sessions TLS ? S'il n'y a aucun inconvénient à l'activer, Il faut mesurer le gain d'aller le tuner finement. Sur un service avec 10 connexions (css/images inclues pour un site web) par tranche de 30 mns, bof, le cache va pas servir des masses donc aller tuner ça comme pour un site à fort trafic, c'est sans grand intérêt, àmha, autant se reposer sur les paramètres par défaut des logiciels serveurs. Sur un serveur mail, avec la concentration des acteurs, l'abonnement à des ML, ... ça se justifie déjà plus mais stay relax quand même. :D




Pour les confs TLS de mes logiciels (elles sont disponibles à la fin de ce shaarli et valent ce qu'elles valent), je me base sur ces ressources déjà pointées dans d'autres de mes shaarlis :
    - Conf' « SSL/TLS » par Benjamin Sonntag à Il était une fois Internet. Les configurations présentées après un exposé plus général sont détaillées et expliquées. http://confs.fr/ssltls-benjamin-sonntag/
    - Pour des configurations clé en main de logiciels serveurs courants et une liste d'algorithmes à privilégier (attention, Mozilla, ça peut être biaisé pour garder la compatibilité avec les anciennes versions de Firefox/Thunderbird/autre) : https://wiki.mozilla.org/Security/Server_Side_TLS


Enfin, àmha, la priorité (en général, pas POODLE), ce n'est pas tellement nos petits serveurs web qui servent des sites web à contenu informatif (donc pas e-commerce / banque / dépôt de  données personnelles / contenu "sensible" où sensible se défini du point de vue du visiteur, pas du nôtre). Non, la priorité c'est nos serveurs mails (SMTP *ET* IMAP) et nos serveurs XMPP (C2S et S2S). C'est là qu'est le vrai contenu privé que l'on veut protéger. D'ailleurs, pour tester la conf' TLS votre serveur XMPP, voir : http://shaarli.guiguishow.info/?AKSlXA .

Donc, pour résumer : -SSLv2/-SSLv3, -RC4 (oui, je sais, BEAST mais sur nos petits serveurs persos, je pense qu'on peut ignore l'usage de TLSv1.0), +PFS (Perfect Forward Secrecy, confidentialité persistante, les échanges sécurisés précédant une compromission d'une clé privée ne sont pas eux-mêmes compromis et restent donc secrets. Donc Diffie-Hellman éphémère donc algos DHE-*, ECDHE-*) et on se relaxe. \o/




Les configurations TLS de mes logiciels serveurs :

ÉDIT DU 03/01/2016 À 23H00 : J'ai mis à jour ces configs avec les dernières directives de configuration disponibles dans les versions packagées dans Debian GNU/Linux Jessie. FIN DE L'ÉDIT.

Apache2 :
    SSLEngine on
   
    SSLCertificateFile    /etc/apache2/ssl/viki.crt
    SSLCertificateKeyFile /etc/apache2/ssl/viki.key

    SSLProtocol All -SSLv2 -SSLv3
       
    SSLCipherSuite ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    SSLHonorCipherOrder on

    # Par defaut
    SSLCompression off
    SSLSessionCacheTimeout 300

    # Parametres DH - Ils sont auto generes selon la taille de la cle
    # utilisee. Si l'on veut des dhparam personnalises, cela necessite
    # openssl 1.0.2 pas encore dans Jessie ou de les concat a la fin du
    # fichier contenant le certif x509 aka c'est crade...
    # SSLOpenSSLConfCmd DHParameters "/etc/apache2/ssl/dh_4096.pem"

    # Cache partages des sessions TLS : mod_socache_* sont necessaires
    # mais pas encore dispo dans Debian stable (01/02/2014)
    # Un cache partages des sessions TLS ne se justifie pas ici :
    # contenu simple : pas besoin de plusieurs connexions simultanees
    # et utilisateurs qui ne reviennent pas dans des delais brefs, en majorite




nginx :
    ssl on;

    ssl_certificate /etc/nginx/ssl/pokedex.crt;
    ssl_certificate_key /etc/nginx/ssl/pokedex.key;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_ciphers ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM;
    ssl_prefer_server_ciphers on;

    # Compression TLS desactivee par defaut dans nginx

    # Parametres DH
    ssl_dhparam /etc/nginx/ssl/dh2048.pem;

    # Par defaut
    ssl_session_timeout 5m;

    # Un cache partages des sessions TLS ne se justifie pas ici :
    # contenu simple : pas besoin de plusieurs connexions simultanees
    # et utilisateurs qui ne reviennent pas dans des delais brefs, en majorite




Dovecot :
    ssl = required

    ssl_cert = </etc/postfix/ssl/pokedex.crt
    ssl_key = </etc/postfix/ssl/pokedex.key

    ssl_protocols = !SSLv2 !SSLv3

    ssl_cipher_list = ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    ssl_prefer_server_ciphers = yes

    # Parametres DH. 4096 bits dans cet exemple car
    # ca correspond a la taille de ma cle
    ssl_dh_parameters_length = 4096

    # Dovecot ne propose aucune autre option




ejabberd :
    ## c2s (bloc listen)
    -
      port: 5222
      ip: "::"
      module: ejabberd_c2s
      max_stanza_size: 65536
      shaper: c2s_shaper
      access: c2s

      # TLS est obligatoire entre un client XMPP (gajim par ex) et le serveur
      starttls: true
      starttls_required: true

      # attention, il faut chainer le certificat x509 et la cle privee.
      # Exemple : cat pokedex.crt pokedex.key > pokedex.crt+key
      certfile: "/etc/ssl/mycert/pokedex.crt+key"
     
      protocol_options:
        - "no_sslv2"
        - "no_sslv3"
        - "cipher_server_preference"

      ciphers: "ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM"

      # Parametres DH. Pas avant ejabberd 15.06 qui n'est pas dans Debian Jessie
      # J'utilise des parametres de 4096 bits car en accord avec la taille
      # de la cle utilise dans mon certificat x509
      dhfile: "/etc/ejabberd/ssl/dh_4096.pem"

    [...]

    # s2s (pas de bloc specifique)

    # TLS est obligatoire entre deux serveurs XMPP. Attention, beaucoup de
    # serveurs XMPP ne supportent pas TLS (exemple : Google) donc ça peut
    # empecher de parler a des contacts. On peut mettre la valeur a optional
    # dans ce cas
    s2s_use_starttls: required

    # Voir la remarque ci-dessus pour certfile
    s2s_certfile: "/etc/ssl/mycert/pokedex.crt+key"

    # Voir la remarque ci-dessus pour protocol_options
    s2s_protocol_options:
      - "no_sslv2"
      - "no_sslv3"
      - "cipher_server_preference"

    s2s_ciphers: "ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM"

    # Voir la remarque ci-dessus pour dhfile
    s2s_dhfile: "/etc/ejabberd/ssl/dh_4096.pem"




Postfix :

ÉDIT DU 20/06/2020 : cette configuration est erronée. Voir la nouvelle ici : http://shaarli.guiguishow.info/?m68qkQ . FIN DE L'ÉDIT.

    # TLS - serveur
    smtpd_tls_security_level = may

    # On n'accepte pas d'auth si pas de TLS
    smtpd_tls_auth_only = yes

    smtpd_tls_cert_file = /etc/postfix/ssl/pokedex.crt
    smtpd_tls_dcert_file = $smtpd_tls_cert_file
    smtpd_tls_key_file = /etc/postfix/ssl/pokedex.key
    smtpd_tls_dkey_file = $smtpd_tls_key_file

    smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

    smtpd_tls_protocols = !SSLv2, !SSLv3

    smtpd_tls_mandatory_ciphers = medium
    tls_medium_cipherlist = ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    smtpd_tls_exclude_ciphers = aNULL, eNULL, EXP, RC4, 3DES, MD5, LOW
    tls_preempt_cipherlist = yes

    # Parametres DH. Oui, 1024 -> 4096 ... ça vient de la doc Postfix
    # J'utilise des parametres de 4096 bits car en accord avec la taille
    # de la cle utilise dans mon certificat x509
    smtpd_tls_dh1024_param_file = /etc/postfix/ssl/dh_4096.pem

    # Cache partages des sessions TLS (expire au bout d'une heure par defaut)
    smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_tls_cache

    smtpd_tls_loglevel = 1


    # TLS - client
    smtp_tls_security_level = $smtpd_tls_security_level

    smtp_tls_cert_file = $smtpd_tls_cert_file
    smtp_tls_dcert_file = $smtpd_tls_dcert_file
    smtp_tls_key_file = $smtpd_tls_key_file
    smtp_tls_dkey_file = $smtpd_tls_dkey_file

    smtp_tls_CAfile = $smtpd_tls_CAfile

    smtp_tls_protocols = $smtpd_tls_protocols

    smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
    smtp_tls_exclude_ciphers = $smtpd_tls_exclude_ciphers

    # Cache partages des sessions TLS (expire au bout d'une heure par defaut)
    smtp_tls_session_cache_database = btree:${data_directory}/smtp_tls_cache

    smtp_tls_loglevel = $smtpd_tls_loglevel




Quelques précisions :
    - Oui, je ne me fais pas chier avec une liste de ciphers longue comme le bras car c'est, àmha, trop chiant à maintenir pour un gain de sécurité pas évident du tout à mesurer par rapport à utiliser les groupements OpenSSL (ou GnuTLS, c'est bien pareil) et à exclure quelques suites d'algos. Du coup, je vire simplement les algos pourris (RC4, 3DES, MD5, ceux classés en LOW dans OpenSSL) ou inexistants (aNULL, eNULL) et j'utilise les algos classés comme HIGH puis comme MEDIUM. L'ordre sera celui du serveur : le client prendra la suite d'algos la plus forte qu'il supporte.

    - Vu que j'ai un seul certificat x509 par machine, les /etc/<logiciel_serveur_>/ssl/lala.(crt|key) sont des liens symboliques vers /etc/ssl/mycert/ . Factorisation toussa.

    - Oui, je ne fais pas encore le chaînage des certificats pour fournir une chaîne de confiance complète à mes visiteurs, c'est sur ma TODO pour le prochain renew des certificats.

    - Rappel des valeurs par défaut dans mes confs c'est juste pour m'en souvenir / retrouver facilement.

Dans un labo de recherche français, il y a du matos Newport SMC100CC pour piloter des moteurs avec le logiciel Micro-Manager (Java mais LGPL/BSD donc ça va :D). Notons que la version GNU/Linux compilée depuis les sources ne gère pas le boîtier Newport alors que la version winwin gère pour une raison encore non identifiée :/

Le but étant de monter une plate-forme d'acquisition : images prises au microscope de cellules/embryon et des moteurs pour déplacer le sujet entre chaque prise.

La caméra apposée au microscope, une Hamamatsu, n'a pas (encore ?) de pilote libre utilisable sous GNU/Linux donc c'est plié. En revanche, le Newport SMC100CC, boîtier d'interfaçage avec les moteurs, se pilote via un port série. La datasheet étant disponible en ligne (http://assets.newport.com/webDocuments-EN/images/SMC100CC_And_SMC100PP_User_Manual.pdf), on sait quelles commandes il faut passer pour communiquer avec les moteurs. \o/

Ici nous  utilisons un convertisseur série<->USB d'où ttyUSB0 mais ça n'a pas d'importance. Pour savoir sur quel /dev/ttySxx le port série de votre ordinateur a été mappé par le noyau, voir : http://shaarli.guiguishow.info/?ciyU6w

Évidemment, vous devez être root, ou, beaucoup plus propre, être membre du groupe dialout ou, beaucoup plus crade, chmod o+rw /dev/ttySx (ou ttyUSB0) pour lire/écrire sur le port série, comme d'hab.

Avec Minicom, il faut penser à ajouter le caractère LF en plus de CR pour le retour à la ligne car c'est ce qu'attend le SMC100CC. Winwin style quoi. Pour ce faire : on entre dans le mode configuration de minicom (ctrl-a + z) -> « Ecran et clavier » -> p (« Add linefeed). On peut ensuite passer des commandes.

Ensuite, on se fatigue en essayant et on se dit qu'écrire directement dans le device avec echo, ça a la classe. Allons-y.

On a un seul boîtier SMC100CC (ID = 1), on l'initialise (OR), on se déplace à la position 42.0 (PA42.0, le paramètre est un double), on revient à la position 0 (PA0.0), puis on reset le boîtier (RS).
echo -e '\r\n\r\n1OR\r\n\r\n' > /dev/ttyUSB0 (moins lisible, en héxa : echo -e '\x0d\x0a1OR\x0d\x0a\x0d\x0a')
sleep 1
echo -e '\r\n1PA42.0\r\n\r\n' > /dev/ttyUSB0
sleep 5
echo -e '\r\n1PA0.0\r\n\r\n' > /dev/ttyUSB0
sleep 5
echo -e '\r\n1RS\r\n\r\n' > /dev/ttyUSB0

Notons que lors d'une initialisation (OR), le moteur revient à sa position initiale (0) mais comme le temps dépend du déplacement à faire (sisi, sans blague), il vaut mieux revenir à la position d'origine avant de reset dans le but que l'initialisation se fasse en un temps fini, sans surprise.
 

Ces boîtiers peuvent être chaînés pour piloter plusieurs moteurs en même temps. Un boîtier qui reçoit des instructions par le port série a toujours un ID = 1 !

Dans un premier temps, il faut indiquer son ID à chaque boîtier. Pour cela, il faut le relier en série à l'ordinateur et positionner le jumper sur « first ». On initialise (OR), on change son ID pour 2 (SA2), et on reset (RS). Le boîtier se souviendra de son ID tout le temps à partir de maintenant, même en cas de reset, reboot électrique ou autre.
echo -e '\r\n\r\n1OR\r\n\r\n' > /dev/ttyUSB0
sleep 1
echo -e '\r\n1SA2\r\n\r\n' > /dev/ttyUSB0
sleep 1
echo -e '\r\n1RS\r\n\r\n' > /dev/ttyUSB0

Pareil pour le deuxième boîtier :
echo -e '\r\n\r\n1OR\r\n\r\n' > /dev/ttyUSB0
sleep 1
echo -e '\r\n1SA3\r\n\r\n' > /dev/ttyUSB0
sleep 1
echo -e '\r\n1RS\r\n\r\n' > /dev/ttyUSB0


Maintenant, on stacke les boîtiers, on positionne les jumper (« first » sur le boîtier qui recevra la connexion série, « other » sur le boîtier d'ID = 2 et « last » sur le dernier boîtier de la chaîne. On peut maintenant les initialiser :
echo -e '\r\n\r\n1OR\r\n\r\n' > /dev/ttyUSB0
sleep 1
echo -e '\r\n\r\n2OR\r\n\r\n' > /dev/ttyUSB0
sleep 1
echo -e '\r\n\r\n3OR\r\n\r\n' > /dev/ttyUSB0
sleep 1

Maintenant, on peut s'amuser (on déplace le moteur du premier boîtier en 42, celui du 2e en 12, ...) :
echo -e '\r\n1PA42.0\r\n\r\n' > /dev/ttyUSB0
echo -e '\r\n2PA12.0\r\n\r\n' > /dev/ttyUSB0
echo -e '\r\n3PA6.0\r\n\r\n' > /dev/ttyUSB0

Toutes les commandes que l'on utilisait avec un seul boîtier sont disponibles, il suffit de simplement de changer l'ID du boîtier auquel on s'adresse.


Pour le fun :D :
for ((i=0; i<43;i=i++)); do
  echo -e "\r\n\r\n1PA$i\r\n\r\n" > /dev/ttyUSB0
  echo -e "\r\n\r\n2PA$i\r\n\r\n" > /dev/ttyUSB0
  echo -e "\r\n\r\n3PA$i\r\n\r\n" > /dev/ttyUSB0
  sleep 5
done

On va par palier de 1 car certains moteurs sont assez sensibles.


Pour changer un numéro d'ID. On initialise, on entre dans le mode configuration (PW1), on change l'ID pour x (SAx), on quitte le mode configuration (PW0) et on reset (RS) :
echo -e '\r\n\r\n1OR\r\n\r\n' > /dev/ttyUSB0
sleep 1
echo -e '\r\n\r\n1PW1\r\n\r\n' > /dev/ttyUSB0
sleep 1
echo -e '\r\n\r\n1SA3\r\n\r\n' > /dev/ttyUSB0
sleep 1
echo -e '\r\n\r\n1PW0\r\n\r\n' > /dev/ttyUSB0
sleep 1
echo -e '\r\n\r\n1RS\r\n\r\n' > /dev/ttyUSB0
sleep 1

Maintenant, il ne manque plus qu'une interface plus pratique pour les utilisateur qui écrira sur le port série de cette manière mais on a au moins compris le fond des choses et le fonctionnement de ces boîtiers. \o/

Sur une machine GNU/Linux, on observe plein de fichiers /dev/ttySx même sur les machines qui ne sont pas équipées d'un port série (RS232).

Comment savoir sur quel device (/dev/ttyS?) a été mappé le port série de votre ordinateur ?

find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
  - Pourquoi j'exclu les fichiers dans /sys/class/tty/ ? Pour ne pas avoir les devices eux-mêmes
  - Pourquoi j'exclu les fichiers qui se trouvent dans un chemin contenant "serial8250" ? La ressource pointée par ce shaarli l'explique très bien : « ttyS* under "serial8250" probably doesn't exist (they are present by default because it's hard to detect if they are present or not)  »

Exemples :
  - Sur une machine sans port série :
    $ find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
    $ [ Aucun résultat ]

  - Sur une machine avec un port série soudé sur la carte mère :
    $ find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
    /sys/devices/pnp0/00:08/tty/ttyS0 [ notre port série est donc mappé sur /dev/ttyS0 ]

  - Sur une autre machine avec un port série soudé sur la carte mère :
    $ find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
    /sys/devices/pnp0/00:0b/tty/ttyS0  [ notre port série est donc mappé sur /dev/ttyS0 ]

Un tool, codé en Java certes, pour lire et injecter sur les canaux RFCOMM bluetooth.

blucat devices (recherche des périph' bluetooth dans le voisinage) et blucat services (découverte des services offerts par un périph') c'est du déjà vu avec hcitool.

blucat scan -> scanner tous les canaux RFCOMM.

blucat -url -> se connecter à un canal RFCOMM et voir ce qui y passe en infos (par exemple : cet outil a été utilisé pour voir ce que Firechat laisse fuiter : http://seenthis.net/messages/301715 )

Pour créer un serveur : blucat -v -l -e /bin/bash . Ici on va donc créer un lien série et spawn un shell bash lors de la connexion du client. L'URL (utilisable avec blucat -url donc) sera donnée par la commande.

Je n'ai rien trouvé de conviviale pour faire un chat over bluetooth comme on peut le faire avec netcat ...
  - $ blucat -v -l -e /usr/bin/write guigui
     #Mon Oct 13 15:42:59 CEST 2014 - Listening at btspp://C4D9874240F4:2
     #Mon Oct 13 15:43:09 CEST 2014 Connected
     #Mon Oct 13 15:43:09 CEST 2014 - Process Redirect Connection: /usr/bin/write guigui

     Message from guigui@porygon on (none) at 15:43 ...
     #Mon Oct 13 15:43:09 CEST 2014 Connection Closed
     #Shutting down
     #Bye

   - $ blucat -v -l -e /bin/bash
     Sur le client : echo $$. On obtient le PID du shell.

     Sur le serveur :
       - Pour recevoir des messages du client : cat /proc/<PID>/fd/0 -> la lecture est bloquante, don't panic
       - Pour envoyer des messages au client : echo "lala" > /proc/<PID>/fd/1

Voir aussi la présentation de cet outil lors de DEFCON 21 : https://www.youtube.com/watch?v=hWPPmgQOKpk

:D