Data leak at Elinchrom

As I'm paranoid, I create a brand new email address each time I've got to register on a web site. It's easy enough and allows me to partition usages and detect abuse. If one of those dedicated addresses ends up in the wild (spammers for example), I just destroy it.

CCBY ©Yuri Samoilov via Flickr

CCBY ©Yuri Samoilov via Flickr


So, in 2010 I registered a support account on Elinchrom's web site with a tailored address : elinchrom (@patpro.net of course). Later, during September 2014, I've received a big spam at that address, neither from Elinchrom nor from one of their partner. After a quick search I've found many other spams blocked by my server. The earlier arrived in 2013.
I've contacted the company, explained the problem, and sent extracts from my mail server logs. After few days, they could find no evidence of a compromise or a data leak on their side. Fair enough, that's not the kind of things you can detect easily, especially if it's years old. On a side note: it's not impossible that I've used the same email address for a contest or event registration affiliated with Elinchrom but not run by them. My bad. At least, this time they deserved the benefit of the doubt.
Following this leak, I've changed the address email to elinchrom2014 (still @patpro.net) and changed the associated password.
The 31th of December 2015 I've received my very first email at this new address: a Paypal phishing attempt, out of a hacked web server somewhere…
Fine.

As I'm super-vigilant since 2014 not to use this address anywhere, the only possible scenario is a data leak at Elinchrom. Going back into my logs, I've found the earliest spam blocked dated from the 24th of October:

Oct 24 17:17:50 postfix/smtpd[84170]: NOQUEUE: reject: RCPT from unknown[202.71.131.54]: 550 5.7.1 Client host rejected: cannot find your hostname, [202.71.131.54]; from=<apache@corp17.net4india.com> to=<elinchrom2014@...> proto=ESMTP helo=<smtp.net4india.com>

I've immediately destroyed this email address, created a new one (longer, with random characters), changed the password again.

Elinchrom: seriously, that's ridiculous, do something. Even the user authentication does not use HTTPS. WAKE UP, it's 2016.

Un shell taillé pour le roaming, la 3G et les cages d’ascenseur

Les fans de la ligne de commande, ou ceux qui sont obligés de s'en servir, le savent : garder un shell distant ouvert et réactif peut parfois être très compliqué, voire impossible. Vous lancez une manip un peu longue mais après quelques temps vous devez changer de réseau. Vous devez intervenir d'urgence via une connexion mobile de très mauvaise qualité. Vous êtes coincé dans un ascenseur avec quelques kbps de bande passante sur un WIFI intermittent. Autant de raisons qui vous feront aimer mosh.

passer-sur-mosh
Mosh pour Mobile Shell, est un outil client et serveur qui supporte le roaming, et qui fonctionne particulièrement bien sur les connexions de mauvaise qualité.
L'architecture de mosh est bien pensée : elle ne nécessite pas d'intervention lourde sur vos serveurs pour en permettre l'utilisation et elle s'appuie sur un serveur ssh existant pour gérer l'initialisation de la connexion, dont la phase d'authentification.

Vous devez simplement installer mosh sur votre poste et sur votre serveur. À partir de là, la connexion fonctionne selon ce principe :
- vous lancez mosh en pointant sur votre login@serveur
- mosh ouvre une connexion ssh login@serveur ce qui permet de procéder à votre authentification
- dès que vous êtes authentifié, mosh lance mosh-server sur le serveur, sous votre UID
- mosh ferme la connexion ssh, et passe la main au mosh-client
- mosh-client se connecte en UDP sur votre mosh-server distant.

Bien sûr, les paquets UDP sont chiffrés, garantissant la sécurité de la connexion. Mosh dispose aussi d'une fonction local-echo très utile sur les liens à forte latence : vous voyez ce que vous tapez immédiatement, contrairement à ce qu'il se passe sur une connexion ssh, où votre entrée devra arriver sur le serveur, être traitée, être renvoyée à votre terminal puis enfin affichée. Cela ajoute un agrément très appréciable sur les lignes très lente ou de mauvaise qualité.

Aussi, l'utilisation de l'UDP, un protocole non-connecté, autorise une implémentation simple de l'itinérance. Plus de problème quand votre portable change de réseau Wifi, passe de l'ethernet à la 4G, etc. Votre connexion avec le serveur reste ouverte, et utilisable dès que le réseau est disponible.

J'encourage vivement les curieux à approfondir les aspects techniques, c'est intéressant et innovant.
Attention cependant, mosh ne supporte pas les utilisations non-intéractives de ssh : scp, les tunnels, X-Forwarding… C'est vraiment fait - actuellement - pour remplacer la bonne vieille session interactive.

Les binaires sont disponibles pour de nombreuses plateformes, même pour Mac OS X 10.5... vous n'avez plus aucune excuse.

Rotation des clés DKIM

La signature des emails par clé DKIM est une composante importante d'un système de messagerie sain et bien géré. Comme tout système cryptographique fonctionnant sur la base d'un couple clé publique / clé privée, il est nécessaire de renouveler les jeux de clés régulièrement.
En effet, plus longtemps une même clé est utilisée, plus elle a de chance d'être cassée. De la même manière, plus elle est petite, plus elle sera facilement cassée.
Comme toujours, avec la correspondance par email, rien n'est instantané. Contrairement à un serveur web par exemple qui pourrait changer de certificat SSL en quelques minutes et faire immédiatement disparaître l'ancien de la circulation, les clés DKIM doivent changer selon un roulement tuilé : quand la nouvelle clé remplace l'ancienne, cette dernière doit rester disponible encore quelques temps pour permettre la validation des signatures présentes dans des messages encore en cours de livraison.
Ainsi, le besoin de faire tourner régulièrement les clés DKIM tout en garantissant un tuilage, ajouté à la complexité (relative) d'une architecture mixte à base de serveur DNS, serveur de mail, logiciel de signature DKIM, rendent nécessaire la mise en place d'une procédure claire, fiable et automatique.

Évolution de l'utilisation de DKIM mesurée au niveau de l'antispam en entrée de mon serveur de mails

Évolution de l'utilisation de DKIM mesurée au niveau de l'antispam en entrée de mon serveur de mails, entre fin 2005 et début 2015

Pour mes propres besoins, j'ai conçu un script shell utilisable pour faire tourner les clés d'un domaine donné. Ce script s'appuie sur un serveur Bind local : la modification des zones DNS se fait par modification directe des fichiers. Il utilise l'implémentation DKIM de OpenDKIM.
Il serait tout à fait possible de concevoir un script qui utilise un serveur DNS distant ou local via la commande nsupdate(8), mais cette approche laisse la main totalement à Bind pour l'écriture des fichiers de zones. Il fait alors disparaître tous les commentaires, il change l'ordre des enregistrements, etc. Ce n'était pas souhaitable pour moi qui stocke des informations en commentaire dans mes fichiers de zones.

Prérequis pour utiliser ce script

- Être root sur le serveur ;
- Disposer d'un serveur DNS Bind, ou compatible (c'est OpenDKIM qui écrit les enregistrements DNS), maître pour les zones concernées par la rotation de clés ;
- Disposer sur la même machine d'une installation OpenDKIM fonctionnelle ;
- Avoir une version de sed qui supporte l'option -i (in place).

Comportement

Le premier argument obligatoire du script est l'action : renouvellement ("new") ou nettoyage ("clean"). Le second argument obligatoire est le domaine cible et le troisième argument (facultatif) est la longueur des nouvelles clés.
Pour l'action "new" et un domaine donné, le script renouvelle l'ensemble des clés DKIM. Par défaut, il génère des clés de la même longueur que celles qu'il remplace, et les sélecteurs sont nommés en `date "+%Y%m"` suivi d'un tiret et des 8 premiers caractères retournés par la commande uuidgen(1). Si une longueur de clé est imposée en argument, l'ensemble des clés du domaine utilisera cette nouvelle valeur. Pour l'action "clean" et un domaine donné, le script vidange les anciennes clés.
Pour assurer un tuilage d'une semaine par exemple, il faut donc le jour J lancer le script avec "new", et à J+7 lancer le script avec "clean" sur le même domaine. Ainsi, avant le jour J, la clé N est utilisée pour signer les messages. À partir du jour J, la clé N+1 est utilisée pour signer les messages, mais la clé N est encore disponible pour vérifier de vieux messages qui seraient encore en circulation. À partir de J+7, l'ancienne clé N disparaît.

Syntaxe des fichiers de zone DNS

Deux contraintes ici :
- Le numéro de série de la zone doit être seul sur sa ligne et suivi du commentaire " ; Serial" pour que le script puisse facilement le localiser et l'incrémenter.
- Les enregistrements DNS des clés DKIM doivent être en inclusion dans le fichier de la zone et résider respectivement dans le fichier dkim-active.${DOMAIN} pour les clés actives et dans le fichier dkim-retired.${DOMAIN} pour les clés inactives. Cela donne pour le fichier de zone patpro.net :

...
$INCLUDE "/etc/namedb/master/dkim-active.patpro.net"
$INCLUDE "/etc/namedb/master/dkim-retired.patpro.net"
...

Ainsi, le script peut très facilement déplacer les clés actives vers le fichier dkim-retired quand de nouvelles clés sont fabriquées et intégrées à dkim-active.

OpenDKIM

Les clés doivent être rangées par domaine, dans des répertoires qui portent le nom du domaine. Cela donne chez moi :

opendkim/patpro.net/201501-62e79011.private
opendkim/patpro.net/201501-62e79011.txt
opendkim/patpro.net/201501-82a3edc5.private
opendkim/patpro.net/201501-82a3edc5.txt
opendkim/proniewski.net/201502-e47af46c.private
opendkim/proniewski.net/201502-e47af46c.txt

Les clés utilisées doivent être référencées dans un fichier KeyTable unique que le script analyse pour retrouver les sélecteurs à remplacer, et réécrit avec les nouveaux sélecteurs.

Utilisation

crontab pour renouvellement automatique mensuel :

0 0 1 * *    /usr/local/sbin/rotate-dkim.sh new patpro.net
0 0 8 * *    /usr/local/sbin/rotate-dkim.sh clean patpro.net

ligne de commande pour changer la taille des clés d'un domaine :

rotate-dkim.sh new proniewski.net 2048

Corpus Scripti

#!/usr/local/bin/bash
# rotate DKIM keys
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# settings
ACTION=${1}
DOMAIN=${2}
NBITS=${3}; NBITS=$(( $NBITS+0 )) # force number
CHROOT=/var/db/opendkim
GENKEY=/usr/local/sbin/opendkim-genkey
KeyTable=/usr/local/etc/opendkim/KeyTable
ZONEROOT=/etc/namedb/master
USERGROUP=root:opendkim
ARCHIVE=/tmp/
MAXKEY=4096
MINKEY=512

onerror() {
case "$1" in
	"args")
		echo "usage: $(basename $0) new|clean domain.name [bits]"; exit 1
		;;
	"chroot")
		echo "\$CHROOT must exist and be a directory"; exit 1
		;;
	"genkey")
		echo "opendkim-genkey not found or not executable"; exit 1
		;;
	"ktable")
		echo "KeyTable not found"; exit 1
		;;
	"zoneroot")
		echo "\$ZONEROOT must exist and be a directory"; exit 1
		;;
	"usergroup")
		echo "User and group must exist"; exit 1
		;;
	"archive")
		echo "\$ARCHIVE must exist and be a directory"; exit 1
		;;
	"nbits")
		echo "Bits length must be greater than $MINKEY, and should not be greater than $MAXKEY"; exit 1
		;;
esac
}

# Checks
[ $# -ge 2 ] || onerror "args"
[ ${ACTION} = "new" -o ${ACTION} = "clean" ] || onerror "args"
[ -d ${CHROOT} ] || onerror "chroot"
[ -d ${ZONEROOT} ] || onerror "zoneroot"
[ -d ${ARCHIVE} ] || onerror "archive"
[ -x ${GENKEY} ] || onerror "genkey"
[ -f ${KeyTable} ] || onerror "ktable"
pw usershow ${USERGROUP/:*/} >/dev/null 2>&1 || onerror "usergroup"
pw groupshow ${USERGROUP/*:/} >/dev/null 2>&1 || onerror "usergroup"
if [ $NBITS -ne 0 ]; then
	[ $NBITS -gt $MINKEY ] || onerror "nbits"
	[ $NBITS -le $MAXKEY ] || onerror "nbits"
fi


archive() {
	echo "Putting away files for old DKIM selector ${1}"
	mv -v ${CHROOT}/${DOMAIN}/${1}.* ${ARCHIVE}
}

if [ ${ACTION} = "new" ]; then
	# Keytable: update SELECTOR
	# structure: 
	# arbitrary-name signing-domain:selector:keypath
	# for each line matching DOMAIN: 
	# - get SELECTOR. 
	# - key path derived from CHROOT/SELECTOR

	# get SELECTOR for DOMAIN:
	SELECTORLIST=( $(awk '/^[^#].* '${DOMAIN}':/ {split($2,a,":"); print a[2]}' ${KeyTable}) )

	# for each SELECTOR we must:
	# - destroy/archive private key 
	# - create a new SELECTOR + key + DNS
	# - rewrite KeyTable
	echo ""
	echo "Selector list for domain $DOMAIN has ${#SELECTORLIST[*]} member-s, lets renew each one:"
	for OLDSELECTOR in ${SELECTORLIST[@]}; do
		if [ $NBITS -ne 0 ]; then
			echo "Bits length set on command line to ${NBITS}, overriding current private key bits length"
			BITS=${NBITS}
		else
			echo -n "Get bits length for private key ${OLDSELECTOR}.private: "
			BITS=$(openssl rsa -in ${CHROOT}/${DOMAIN}/${OLDSELECTOR}.private -text -noout | awk '/Private-Key/ {gsub(/[^0-9]/,"",$2); print $2}')
			echo "$BITS"
		fi		
		echo -n "Create new selector: "
		UUID=$(uuidgen)
		SELECTOR="$(date "+%Y%m")-${UUID/-*/}"
		echo "${SELECTOR}"
		echo "Create new private key with ${SELECTOR}:"
		${GENKEY} -v -b ${BITS} -d ${DOMAIN} -D ${CHROOT}/${DOMAIN} -r -s ${SELECTOR}
		# permission adjustments:
		chown ${USERGROUP} ${CHROOT}/${DOMAIN}/${SELECTOR}.*
		chmod u=r,g=r ${CHROOT}/${DOMAIN}/${SELECTOR}.*
		ls -l ${CHROOT}/${DOMAIN}/${SELECTOR}.*
		echo -n "Update KeyTable: "
		sed -i .bkp -e 's/'$OLDSELECTOR'/'${SELECTOR}'/g' ${KeyTable}
		[ $? -eq 0 ] && echo "OK"
		archive ${OLDSELECTOR}
	done
	echo ""
	echo "End of selector renewal."
	# every SELECTOR for DOMAIN is updated, now deal with DNS
fi

echo ""
# calculate new serial for zone $DOMAIN
echo -n "Get old DNS zone serial for ${DOMAIN} and increment: "
NEWSERIAL=$(date +%Y%m%d%I)
OLDSERIAL=$(awk '/ ; Serial/ {print $1}' ${ZONEROOT}/${DOMAIN})
while [ $OLDSERIAL -ge $NEWSERIAL ]; do
	let NEWSERIAL=(NEWSERIAL+1)
done
echo "$OLDSERIAL -> $NEWSERIAL"
#
# Update SERIAL of DNS zone.
echo -n "Change serial in zone file: "
sed -i .bkp -e 's/'$OLDSERIAL' ; Serial/'${NEWSERIAL}' ; Serial/g' ${ZONEROOT}/${DOMAIN}
[ $? -eq 0 ] && echo "OK"

if [ ${ACTION} = "new" ]; then
	echo -n "Move old public keys to dkim-retired.${DOMAIN}: "
	cat ${ZONEROOT}/dkim-active.${DOMAIN} > ${ZONEROOT}/dkim-retired.${DOMAIN}
	[ $? -eq 0 ] && echo "OK"
	echo -n "Copy new public keys to dkim-active.${DOMAIN}: "
	cat ${CHROOT}/${DOMAIN}/*.txt > ${ZONEROOT}/dkim-active.${DOMAIN}
	[ $? -eq 0 ] && echo "OK"
elif [ ${ACTION} = "clean" ]; then
	echo -n "Clean old public keys of dkim-retired.${DOMAIN}: "
	echo "" > ${ZONEROOT}/dkim-retired.${DOMAIN}
	[ $? -eq 0 ] && echo "OK"
fi

echo ""
echo "Everything looks good, lets refresh world:"
named-checkzone ${DOMAIN} ${ZONEROOT}/${DOMAIN}
service named restart
[ ${ACTION} = "new" ] && service milter-opendkim restart

Les commentaires dans le code sont suffisants pour expliquer chaque étape du déroulement du script.

Bibliographie

DKIM
M3AAWG DKIM Key Rotation Best Common Practices (PDF)

Du SSL gratuit pour tout le monde ?

letsencrypt-logoLet’s Encrypt est une initiative toute récente de Mozilla, Cisco, l'EFF, Akamai, et IdenTrust. Elle vise à permettre à tout webmaster de proposer son site en HTTPS sans surcoût. Il s'agit de proposer aux administrateurs de serveurs web la possibilité d'obtenir gratuitement, automatiquement, et sans contrainte le précieux certificat SSL nécessaire au chiffrement des échanges entre le serveur et les clients. Le certificat sera bien évidemment reconnu nativement dans les navigateurs. C'est en tout cas la promesse du projet. Si cela permet de mettre fin à un racket que je dénonçais il y a quelques semaines, cela lève aussi quelques questions.

Un des principaux arguments des Verisign et autres Thawte pour vous facturer une fortune pour chaque certificat est que la création et le maintient d'une autorité de certification (CA) est extrêmement onéreux. Cela coûte en effet assez cher : les contraintes de sécurité sont immenses, les audits nombreux, etc. En effet la moindre compromission de l'autorité de certification réduit tous les efforts à néant : l'attaquant qui parviendrait à s'infiltrer dans la CA serait capable d'émettre des faux certificats passant pour tout à fait valides dans les navigateurs. Votre belle connexion sécurisée avec "barre verte" pourrait alors être détournée sans que vous n'en ayez conscience (sécurité ≠ confiance).
Mais on le sait ces grosses CA ne sont pas forcément plus fiables que les petites. Elles ne résistent pas forcément mieux aux pressions des agences gouvernementales, ni aux détournements ou piratages. Quelques exemples par ici. Finalement, ce surcoût n'a guère de valeur. Ce qui compte vraiment c'est de savoir si on peut faire confiance à la CA, ou pas.

Dans l'initiative Let’s Encrypt, la question de confiance peut se poser. Je n'ai pas de souci avec Mozilla, et la présence de l'EFF est rassurante. Par contre celle de Cisco m'interpelle. Snowden nous a montré comment la NSA s'amuse à intercepter les livraisons de matériels de cette marque pour caviarder les firmwares et ajouter des portes dérobées. Rien, bien évidement, n'incrimine Cisco directement dans ces magouilles. Néanmoins le doute raisonnable peut naître sur leur degré de connaissance de ces agissements.
Au bout du compte je n'ai pas trop envie de faire confiance à un groupement d'entités sachant que la duplicité d'une seule d'entre elles peut réduire à néant la sécurité des certificats délivrés.

Le protocole proposé (ACME) me laisse aussi dubitatif. J'avoue n'avoir pas lu l'ensemble du brouillon. Je n'ai pas de critique fondée à son encontre mais la débauche d'automatisme (le serveur web qui commande lui même le certificat par exemple) me laisse dubitatif, et je pense que j'attendrai sagement de voir ce que ça donne chez les autres avant d'essayer moi-même.

L'outils lets-encrypt est conçu pour fonctionner assez simplement. C'est sans doute une bonne idée au départ, mais cela laisse peu de maitrise sur le processus. Bien sûr, tout comme le protocole, il faudra attendre de voir ce que ça donne, quelles plateformes sont supportées, quels logiciels aussi. Mettre du SSL dans le web c'est sympa, mettre du SSL dans du mail (smtp, pop, imap) c'est primordial. A priori la première version sera livrée à l'été 2015, donc il reste un peu de temps.

Je souhaite profondément que Let’s Encrypt réussisse son pari. Fournir des certificats SSL reconnus et gratuits, avec des outils simples, basés sur une autorité de certification et sur des protocoles sûrs est un vrai défi.

Le racket des certificats SSL

Autrefois, Internet était un peu open bar. C'était un lieu de partage où tout le monde pouvait publier, échanger, créer librement. C'était l'insouciance. Puis il y a eu l'arrivée du commerce en ligne, avec des échanges d'argent numérique. Il a alors fallu créer la confiance, car dans nos vies pressées il n'est plus question de l'acquérir sur le long terme, non, il faut la créer de toute pièce pour en disposer immédiatement.
Sont alors arrivés en masse les sites marchands (ou non) proposant des connexions sécurisées "https". Plus récemment, l'usage des connexions sécurisées par SSL/TLS s'est beaucoup élargi, non plus pour protéger vos données bancaires d'une interception mais pour protéger votre vie privée. Il est en effet primordial de pouvoir publier sa vie sur facebook ou twitter sans qu'un méchant pirate puisse espionner directement sur votre connexion ce que vous écrivez sur ces sites.

C'est bien de promouvoir la sécurité des échanges sur internet, d'encourager les gens à proposer des services chiffrés, et les initiatives ce multiplient dans ce sens, avec par exemple des navigateurs qui vont tenter de se connecter à la version https d'un site web par défaut, et se rabattre sur la version http seulement quand la version sécurisée n'existe pas.

Pour transformer un service http classique en service sécurisé https, il faut disposer d'un certificat SSL/TLS. Malheureusement seuls les gens riches peuvent proposer des services sécurisés "de confiance". En effet il existe globalement trois manières de se procurer un certificat SSL. Vous pouvez le fabriquer vous même, c'est assez simple, cela prend quelques minutes et c'est totalement gratuit. Vous pouvez demander à un opérateur libre et gratuit comme CaCert.org de vous le proposer, c'est à peine plus long et toujours gratuit. Ou alors, vous avez de l'argent (beaucoup), et vous l'achetez chez un prestataire.
Et là, nous sommes face à trois obstacles majeurs, qui sont le Certification Authority Browser Forum, les moteurs de recherche, et le prix.

Chrome vous ment, ce qui ne profite qu'aux grosses entreprises

Chrome vous ment, ce qui ne profite qu'aux grosses entreprises

Le Certification Authority Browser Forum est un lieu d'échange entre les développeurs de navigateur d'une part et les autorités de certification d'autre part. Ces gens se mettent d'accord sur plein de détails techniques autour de l'implémentation de la sécurité des certificats dans les navigateurs. Notamment, c'est en partie là-bas qu'ils se mettent d'accord sur quelle autorité de certification (CA) va se trouvée incluse d'office dans la liste des CA valides des navigateurs. En effet, quand vous ouvrez une page web en https, le serveur présente son certificat. Ce dernier indique par quelle CA il a été signé. Si la CA est reconnue par le navigateur tout va bien, sinon l'utilisateur reçoit une alerte indiquant que la connexion n'est pas sécurisée, qu'on ne peut pas lui faire confiance, etc. Ces messages d'alerte ont d'ailleurs beaucoup évolué depuis quelques années. Actuellement, ils sont juste mensongers. Ils induisent pour son bien l'utilisateur en erreur allant jusqu'à prétendre à tort que la connexion n'est pas sécurisée. Ce mécanisme induit chez les utilisateurs une confusion (criminelle oserais-je dire) entre sécurité et confiance, en faisant passer "une confiance que l'outil ne peut vérifier" pour une "sécurité qui n'existe pas".

Confusion sécurité confiance

Confusion sécurité confiance

Les moteurs de recherche ne sont plus ce qu'ils étaient à leurs balbutiements dans les années 90. Ils intègrent désormais des algorithmes extrêmement complexes de classement (ranking) autorisant des recherches personnalisées et un placement de produits optimisé. En parallèle ils se sont arrogés le droit de surclasser ou de déclasser des résultats de recherche selon des critères tout à fait critiquables. Google a notamment décidé d'améliorer la visibilité des sites qui répondent à des critères de sécurité arbitraires. Essentiellement cela revient à surclasser les sites internet disposant d'un certificat SSL EV (extended validation, les plus chers).
Ainsi, si vous n'êtes pas en mesure de proposer votre site web en https, avec un certificat valide et de préférence un certificat EV, vous êtes déclassés au profit de la concurrence.

Comme vous l'avez compris, la seule planche de salut pour obtenir la confiance des navigateurs et donc des utilisateurs qui sont derrière est de proposer une connexion https avec un certificat acheté chez un fournisseur du commerce. Ces certificats sont excessivement chers. Et ce tarif ne permet simplement pas, même à des individus passionnés, de proposer une connexion https qui aurait les faveurs de Mozilla ou Google.
J'utilise sur ce serveur un certificat SSL de CaCert qui contient 20 noms différents (patpro.net, www.patpro.net, patpro.fr, etc.). Ce certificat ne me coûte rien, il me permet de proposer le chiffrement SSL/TLS pour mon serveur web et pour mon serveur de mail. Si je veux obtenir un certificat comparable chez les autorités de certification du commerce, il m'en coûtera 2582 euros chez Thawte ou 6280 dollars chez Verisign/Symantec, pour un certificat valide pendant une année. À ce tarif là, c'est un certificat d'entrée de gamme, qui sera reconnu dans votre navigateur, mais ne disposera pas de la belle "barre-verte-qui-stimule-la-confiance-du-visiteur-et-améliore-le-référencement".

La fameuse barre verte qui doit donner confiance aux utilisateurs

La fameuse barre verte qui doit donner confiance aux utilisateurs


Pour disposer d'une telle parure il me faut être une entreprise, montrer patte blanche, et débourser 18200 dollars chez Verisign, toujours pour 1 an et mes 20 noms de domaines.
Heureusement il existe des alternatives un peu moins coûteuses, comme chez Gandi par exemple, où je pourrai trouver un certificat répondant à mes besoins pour 210 euros par an, ou 1900 euros en version EV. C'est toujours un coût sérieux pour un individu.

Donc la situation actuelle se résume assez simplement : les gros acteurs du web, Google en tête, poussent très fort pour que les utilisateurs ne fassent pas confiance à des certificats autosignés, ou gratuits. Ils utilisent un discours tellement simpliste qu'il en devient mensonger. En trompant l'utilisateur, ils favorisent la visibilité sur internet des gens riches, au dépend de ceux qui n'ont pas les mêmes moyens. En diffusant des messages anxiogènes aux utilisateurs, ils dévoient la sécurité réelle proposée par des certificats SSL légitimes.

S’envoyer des SMS multilignes via l’API de free-mobile

Free vient de mettre à disposition de ses abonnés Free-mobile un moyen simple de générer via une API accessible en ligne des SMS à soi-même. L'utilisation est globalement très simple et tient presque toutes ses promesses (actuellement il ne semble pas possible de faire du POST, seul le GET fonctionne).
Il suffit aux intéressés de se rendre sur leur interface de gestion de compte Free-mobile, dans la section "Mes options", et d'y activer (vers le bas de la page) l'option ad-hoc. Une fois l'option activée, Free vous gratifie d'un mot de passe dédié à cet usage, et vous renseigne un peu sur le fonctionnement du service :

free-mobile-notification

Une fois l'option activée, l'utilisation se résume à une requête HTTP de cette forme :

curl 'https://smsapi.free-mobile.fr/sendmsg?user=***&pass=***&msg=coucou'

Vous recevez alors sur votre téléphone Free-mobile le SMS contenant le message "coucou".

La création d'un message multiligne est un peu plus délicate. La plupart des plateforme Unix/Linux envoie en guise de séparateur de ligne un \n qui se traduit par %0a une fois "url-encodé". Malheureusement, l'API n'accepte pas ce %0a et le message sera tronqué à la première occurrence.
Par contre, le séparateur de ligne \r, encodé en %0d est bien accepté par l'API Free-mobile. Il faut donc, avant d'envoyer un message sur plusieurs lignes, traduire les \n en \r.

J'ai conçu un script shell pour mes besoins personnels. Il prend ses données en entrée standard, par exemple via un pipe :

echo "mon message" | sms.sh

Ce qui est plus souple pour moi dans bien des situations, que de devoir invoquer le script et de lui servir le message comme argument, par exemple :

autresms.sh mon message

Voici donc le code de mon script qui prend les messages via stdin, et qui converti les \n en \r. Notez que le SMS à l'arrivée ne contient pas de saut de ligne, donc prévoyez des espaces en fin de ligne si vous ne voulez pas que la fin de ligne soit collée au début de la ligne suivante.

#!/usr/local/bin/bash  
#
# push notification via smsapi.free-mobile.fr
#
LOGGEROPT="-p security.notice -t SMS"
REPLOGG=1
REPMAIL=1
MAILTO=root
USR="****"
PSW="****"
URL="https://smsapi.free-mobile.fr/sendmsg"
CURL=/usr/local/bin/curl

report() {
        [ ${REPLOGG} -eq 1 ] && echo $@ | logger ${LOGGEROPT}
        [ ${REPMAIL} -eq 1 ] && echo $@ | mail -s "SMS $@" ${MAILTO}
}

eval $(${CURL} --insecure -G --write-out "c=%{http_code} u=%{url_effective}" \
        -o /dev/null -L -d user=${USR} -d pass=${PSW} --data-urlencode msg="$(cat|tr '\n' '\r')" ${URL} 2>/dev/null | tr '&' ';')

echo ${c} ${u}\&pass=***\&msg=${msg} | logger ${LOGGEROPT}

case ${c} in
        "200")
                exit 0
                ;;
        "400")
                report "parameter missing" ; exit 400
                ;;
        "402")
                report "too many SMS..." ; exit 402
                ;;
        "403")
                report "service unavailable for user, or wrong credentials" ; exit 403
                ;;
        "500")
                report "server error, try later" ; exit 500
                ;;
        *)
                report "unexpected result" ; exit 600
                ;;
esac

Utilisation :

echo "mon message 
sur plusieurs 
lignes" | sms.sh

Il reste à faire :
- ajouter l'enregistrement dans les log système de chaque utilisation du script sms.sh
- ajouter la gestion des codes de retour HTTP autres que 200.

Attention
Pour bénéficier d'une gestion d'erreur et d'une trace dans les log de la machine j'ai utilisé une grosse ruse très sale avec eval. Cela permet de créer des variables à la volée à partir de données fournie par l'utilisateur. C'est éminemment risqué car tout ce est qui généré par c=%{http_code} u=%{url_effective} sera évalué sans distinction (avec potentiellement des exécutions de code).
Pour un système de monitoring c'est un risque négligeable : les messages sont connus et fixés par le logiciel qui les génère, sans interaction avec l'utilisateur. Pour une utilisation dans tout autre mécanisme la prudence est requise.

Le PC dans mon téléphone

Précédemment, j'ai évoqué l'ordinateur de demain. J'ai fait un test grandeur nature façon corporate. Comprendre : vous aurez du mal à faire pareil chez vous. J'utilise en effet quelques artifices comme un accès VPN au réseau de mon employeur, et au travers de cet accès une machine virtuelle VMware View.
Au final, j'ai le bureau d'une machine Windows 7 affiché sur la TV du salon, j'ai un clavier et une souris bluetooth, le tout servi par mon téléphone malin, via un tunnel VPN dans une connexion WIFI. La connexion avec la machine virtuelle se fait via le client officiel View, de VMware (donc en PCoIP).

Windows dans ma TV sur mon téléphone

Ci dessus une photo de la TV affichant le bureau de la VM dans laquelle est lancé le client VSphere (outil d'administration de datacenter VMware).

À 2m50, le texte dans l'interface n'est pas hyper lisible sur l"écran 80cm, donc pour le PC dans le canapé, on repassera, ou alors on fera des réglages spéciaux sur la machine virtuelle.

Le client View se comporte relativement bien, néanmoins, il y a comme un petit souci avec le clavier. Ce dernier fonctionne parfaitement en azerty partout, sauf à l'intérieur du Windows, où il fonctionne en qwerty. Le client View dispose d'un champs de saisie qui permet de taper du texte à l'extérieur de la VM et de l'envoyer ensuite vers cette dernière. À cet endroit, c'est bien de l'azerty. Mais le même texte tapé directement dans la VM passe en qwerty. C'est peut être du à mon téléphone, qui est paramétré tout en anglais.

Aussi, suite à un blocage logiciel sur ma VM, j'ai tenté un ctrl-alt-suppr via mon clavier bluetooth. Le programme n'a pas rendu la main, la VM n'a pas rebooté. Non. C'est le téléphone qui a rebooté. Ça m'a fait rire.

Collecte en aveugle

Elle est belle celle-là :

213.61.149.100 […20:00:26 +0100] "GET / HTTP/1.0" 301 235 
213.61.149.100 […20:00:27 +0100] "GET /blog/ HTTP/1.0" 200 63772 
213.61.149.100 […20:00:28 +0100] "GET /www.patpro.net.tar.gz HTTP/1.0" 404 493 
213.61.149.100 […20:00:28 +0100] "GET /www.patpro.net.tgz HTTP/1.0" 404 493 
213.61.149.100 […20:00:29 +0100] "GET /www.patpro.net.zip HTTP/1.0" 404 493 
213.61.149.100 […20:00:29 +0100] "GET /www.patpro.net.sql HTTP/1.0" 404 493 
213.61.149.100 […20:00:30 +0100] "GET /patpro.tar.gz HTTP/1.0" 404 493 
213.61.149.100 […20:00:30 +0100] "GET /patpro.tgz HTTP/1.0" 404 493 
213.61.149.100 […20:00:31 +0100] "GET /patpro.zip HTTP/1.0" 404 493 
213.61.149.100 […20:00:31 +0100] "GET /patpro.sql HTTP/1.0" 404 493 

Et particulièrement astucieuse, je suis persuadé qu'elle permet de ramasser des tonnes de trucs très intéressants.