Bug SSL dans Python
Depuis deux semaines, le site de la banque BNP Paribas se met parfois à s'arrêter brusquement de répondre à une requête HTTPS. Or ceci est bien fâcheux, car bien que weboob impose un timeout de 15 secondes à urllib2, il se trouve qu'en l'occurrence l'appel du module à la méthode urlopen() ne se termine jamais.
Armé de strace, j'ai pu constater que systématiquement il s'agit d'un appel à la fonction système read() qui n'obtient pas de réponse. Un peu plus d'investigation m'a révélé que cela se produit lors du handshake SSL.
Après avoir cherché en vain l'explication dans les sources du wrapper SSL de Python, j'ai trouvé un rapport de bug daté de 2007 et concernant la version 2.6. Il explique que le constructeur de la classe SSLSocket effectue le handshake directement, et ce avant qu'il ne soit possible d'interagir avec la socket pour la rendre non bloquante ou, ce qui m'intéresse davantage, de définir un timeout.
Le patch qui a été proposé et intégré introduit un paramètre do_handshake_on_connect, par défaut à True, ainsi que la méthode do_handshake(). Il s'agit d'une solution bas niveau, qui certes s'harmonise très bien à l'API de la lib SSL de Python qui ne brillait déjà pas par sa qualité.
Or le problème que j'ai avec weboob, est qu'on ne tape évidement pas directement dans ssl, mais qu'on passe par mechanize, qui utilise urllib2, qui utilise httplib, qui utilise ssl (ouf). Et aucune de ces bibliothèques ne supporte ce paramètre.
Malgré le fait que mechanize implémente tous les design patterns baveux existants, rendant son code complètement illisible, il ne semble pas possible de changer aisément le handler HTTPS, chose qui aurait pu permettre de surcharger la classe de httplib pour effectuer moi-même le handshake après avoir désactivé do_handshake_on_connect.
La solution crade que j'ai choisie m'a été inspirée d'un patch tout aussi crade envoyé dans un ticket pour contourner un bug de Debian Wheezy (toujours présent d'ailleurs) qui rend OpenSSL inopérant avec le site de la Banque Postale dès lors que l'on utilise le protocole par défaut (SSLv23).
Le code est le suivant, bien dissimulé au fond de weboob/tools/browser/browser.py :
import ssl
def mywrap_socket(sock, *args, **kwargs):
kwargs['do_handshake_on_connect'] = False
kwargs['ssl_version'] = kwargs.get('ssl_version', ssl.PROTOCOL_TLSv1)
sock = ssl.wrap_socketold(sock, *args, **kwargs)
sock.settimeout(StandardBrowser.DEFAULT_TIMEOUT)
# check if we are already connected
try:
sock.getpeername()
except:
sock.do_handshake_on_connect = True
else:
sock.do_handshake()
return sock
ssl.wrap_socketold=ssl.wrap_socket
ssl.wrap_socket=mywrap_socket
httplib utilise la fonction wrap_socket pour créer la socket SSL. En remplaçant cette méthode, en changeant les arguments et en effectuant le handshake nous-même dans le cas où nous sommes déjà connectés, ça peut enfin fonctionner.
Et dire que nous sommes en 2012.
DRM de NolifeTV
Le site Nolife TV permet de visualiser les émissions de la chaîne de télévision du même nom via un player flash. Il existe un module Weboob pour se passer de logiciel propriétaire, mais comme on va le voir, ils ont mis en place un mécanisme afin d'empêcher le contournement. En vain.
Première version
Fin 2011 je suis tombé sur ce post de leur forum, qui inclus cette mention :
Merci de ne pas intégrer la lecture des vidéos de Nolife Online dans votre client NoAir sans passer par l'interface web de Nolife Online. De façon générale, ne développez pas de lecteur accédant directement aux vidéos de Nolife Online sans notre accord.
Y voyant une provocation au libriste que je suis, et bien que n'étant pas intéressé par les émissions de cette chaîne, je me suis mis en tête de pondre un module weboob. À des fins de recherche, évidemment.
L'analyse du site m'a permis de constater que le player flash faisait deux requêtes à /_newplayer/api/api_player.php :
skey=9fJhXtl%5D%7CFR%3FN%7D%5B%3A%5Fd%22%5F&connect=1&a=US
Celle-ci effectue un connect=1 pour s'annoncer, je ne sais pas trop pourquoi.
skey=9fJhXtl%5D%7CFR%3FN%7D%5B%3A%5Fd%22%5F&a=UEM%7CSEM&quality=0&id%5Fnlshow=1234
Cette requête renvoie entre autres l'URL du fichier vidéo. On constate dans les paramètres le champ id_nlshow qui contient l'ID de la vidéo. Rien de bien compliqué, donc, mis à part cette skey dont je n'arrivais pas à déterminer l'origine.
Après diverses recherches, j'ai fini par comprendre qu'il s'agissait d'une constante. Un peu déçu de ne pas y avoir pensé alors que c'est une « protection » commune, et sans comprendre comme d'habitude l'intérêt de faire ça, j'avais atteint une version fonctionnelle de mon module et savourais ma première victoire.
Seconde version
Il y a quelques mois, une nouvelle version du site de Nolife TV a été mise en ligne, cassant sans ménagement le module de weboob. N'ayant alors pas le courage de me replonger sur le code d'un module que je n'utilise pas, j'ai laissé les choses trainer… jusqu'à aujourd'hui.
Je n'ai pas été déçu du voyage. Après avoir corrigé l'authentification, la recherche et autres trivialités, je me suis alors penché sur la récupération de l'URL des vidéos.
Le player effectue maintenant non pas deux mais trois appels à /_nlfplayer/api/api_player.php :
skey=1b6cf46e6e484e03b370f528441357fd&a=MD5×tamp=1351359574
Renvoie des paramètres qui ne semblent pas être utilisés par la suite, probablement l'équivalent du connect=1 de la précédente version.
a=EML&skey=893873357e374594eb6fac475846574b&id%5Fnlshow=30833×tamp=1351359576
Récupère quelques méta-informations sur la vidéo.
quality=0&a=UEM%7CSEM%7CMEM%7CCH%7CSWQ&skey=005f9ae80d77db93b557cc14c404aa76&id%5Fnlshow=30833×tamp=1351359579
Enfin, le graal, l'URL de la vidéo.
Facile me diriez-vous ? Ce n'est sans compter un petit détail : le paramètre skey change d'un appel à l'autre. On constate également la présence du paramètre timestamp, ce qui laisse immédiatement penser que la clef est calculée à partir de lui. Mais de quelle manière ?
C'est probablement un checksum MD5, et il y a fort à parier qu'une clef privée est utilisée comme salt. Et pour la retrouver, ça risque d'être coton.
Je me suis alors penché sur divers outils pour tenter d'analyser le player flash. swftools, flasm ou flare n'en sont pas venu à bout. J'ai juste été capable de décompresser le .swf, mais aucune information dans ce qui restait un binaire ne m'ont donné la solution.
C'est alors que je suis tombé sur ce site qui m'a sorti ce fichier parfaitement lisible.
On y découvre les lignes suivantes :
public function nl_dataloader(){
this.loaded_data = new Object();
super();
salt = chaine([97, 53, 51, 98, 101, 49, 56, 53, 51, 55, 55, 48, 102, 48, 101, 98, 101, 48, 51, 49, 49, 100, 54, 57, 57, 51, 99, 55, 98, 99, 98, 101]);
}
public static function addKey(_arg1:URLVariables):URLVariables{
_arg1.timestamp = new Date().time;
_arg1.skey = getKey(_arg1.timestamp);
return (_arg1);
}
public static function getKey(_arg1):String{
return (MD5.encrypt((MD5.encrypt(String(_arg1)) + salt)));
}
À partir de là, la solution est évidente. Transposé en python dans le module weboob, ça donne le code suivant :
SALT = 'a53be1853770f0ebe0311d6993c7bcbe'
def genkey(self):
timestamp = str(int(time.time()))
skey = md5(md5(timestamp).hexdigest() + self.SALT).hexdigest()
return skey, timestamp
Et ça marche. Le module NolifeTV fonctionne de nouveau. Le commit complet pour régler le problème est visible ici.
Conclusion
Comme toujours, les mesures de protection que tentent de mettre en place les sites de streaming video se contournent très facilement. Il n'est plus à démontrer que les seules personnes que ça emmerde, ce sont les utilisateurs honnêtes qui ne peuvent pas regarder leur contenu payant sur la plateforme de leur choix, ni de les voir offline.
Vérification des certificats
Jusqu'alors, un problème dans la sécurité de Weboob est qu'il ne vérifie pas la validité du certificat envoyé par le serveur lorsqu'on établie une connexion SSL. Ceci est dû à l'utilisation de mechanize, la bibliothèque qui simule le comportement d'un navigateur, et qui n'offre pas de tel mécanisme.
L'écriture par Laurent du Browser 2 se passant de mechanize pour le remplacer astucieusement par requests devrait résoudre ce problème proprement dans une prochaine version de Weboob. Malheureusement, ce nouveau browser n'étant pas encore terminé, une solution alternative et provisoire a été proposée par Florent.
Comme mechanize a une gestion opaque du SSL (du fait des multiples couches le séparant de la bibliothèque openssl, et de la médiocrité du code), l'idée est d'établir une première connexion en utilisant directement openssl et de valider le certificat à partir du fingerprint préalablement renseigné dans le module, avant de poursuivre le déroulement normal via mechanize.
Cette mesure de protection peut facilement être contournée, puisqu'il suffit à l'attaquant, dans le cas d'un Man-in-the-middle, de relayer la première connexion, et de s'interposer pour les suivantes qui elles ne seront pas vérifiées par mechanize.
Néanmoins, ce mécanisme temporaire est efficace dans la plupart des cas.
Pour les développeurs de modules, il suffit de renseigner au
BaseBrowser
l'attribut de classe CERTHASH contenant le SHA-256 de la chaîne de certificats du serveur :
class BNPorc(BaseBrowser):
DOMAIN = 'www.secure.bnpparibas.net'
PROTOCOL = 'https'
CERTHASH = '5511f0ff19c982b6351c17b901bfa7419f075edb13f2df41e446248beb7866bb'
Une autre façon de faire est d'appeler directement la méthode StandardBrowser.lowsslcheck :
browser.lowsslcheck('www.secure.bnpparibas.net', '5511f0ff19c982b6351c17b901bfa7419f075edb13f2df41e446248beb7866bb')
Afin de calculer ce fingerprint, vous pouvez aisément procéder de la manière suivante :
$ python Python 2.7.3rc2 (default, Apr 22 2012, 22:30:17) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>> from hashlib import sha256 >>> domain = 'www.secure.bnpparibas.net' >>> sha256(ssl.get_server_certificate((domain, 443))).hexdigest() '5511f0ff19c982b6351c17b901bfa7419f075edb13f2df41e446248beb7866bb'
Bien évidement, il vaut mieux être certain de ne pas soi-même être victime d'une attaque à ce moment là, car aucune vérification n'est effectuée.
Il ne s'agit que d'une mesure temporaire, en attendant mieux dans le Browser 2.
RMLL 2012
Cette année se sont déroulées les Rencontres Mondiales du Logiciel Libre à Genève.
Pour la première fois, Weboob avait son stand, conjointement à celui de Salut à Toi, ce qui permit non seulement de faire connaître le projet à de nombreuses personnes et d'avoir moult conversations intéressantes, mais aussi et surtout d'avoir un lieu pour poser mes fesses.
Comme il y a deux ans, j'ai donné une conférence au sujet de Weboob. Bien que je l'ai très peu préparée et qu'il y avait moins de monde que la dernière fois, ça s'est plutôt bien passé.
Sont disponibles la vidéo et les slides.
Enfin, concernant Genève même, tout est effectivement très cher, il n'y a pas particulièrement de spécialités culinaires, ce qui fait que j'ai mangé italien, chinois, français… Quant au critère discriminant pour moi, à savoir la bière, il faut savoir qu'il est juste impossible de trouver autre chose que de la pisse.
Flux RSS des modules mis à jour
Une contrainte qui avait été relevée par les utilisateurs relative au nouveau système de dépôts, est la possibilité d'être informé lorsque les modules sont mis à jour, notamment pour des problèmes de sécurité.
C'est à cette problématique que j'ai répondu en créant un flux RSS actualisé au moment où sont poussées les nouvelles versions de modules, et contenant les dernières mises à jour accompagnées des messages de commits liés.
Afin d'en profiter, abonnez-vous à l'un de ces deux liens, suivant la version de Weboob que vous utilisez :
Dépôts Weboob
Un problème majeur que l'on rencontre avec Weboob, est l'évolutivité imprévisible des sites web supportés, qui peuvent casser un module si celui-ci n'est pas suffisamment tolérant, ou si le changement est trop conséquent.
Pour réduire le désagrément de l'utilisateur qui ne peut plus utiliser les fonctionnalités qui améliorent sa vie au quotidien, il convient d'être réactif sur trois points :
La détection du bug
Ce premier point est effectué soit par le buildbot (via ses tests journaliers et post-commits), soit par l'utilisateur qui va sagement produire un rapport de bug. Une idée d'amélioration permettant l'envoi automatisé d'un bugreport contenant toutes les informations nécessaires sera l'objet d'un futur billet.
L'écriture d'un correctif
Chaque module est en principe maintenu par une personne qui l'utilise au quotidien. Malheureusement, il arrive que des modules voient leur mainteneur disparaître sans donner de nouvelles. Il est toujours possible pour un membre de la Core Team dévoué et chômeur d'intervenir rapidement sur un de ces modules, mais ce n'est malheureusement pas toujours possible, notamment en ce qui concerne les modules supportant des sites bancaires.
La diffusion du correctif
Ce point est celui qui va retenir notre attention aujourd'hui.
Jusqu'alors, les modules étant distribués directement avec les sources de Weboob, il convenait de sortir une nouvelle version de l'ensemble du logiciel pour diffuser le moindre correctif.
Pour l'utilisateur, il convenait par simplicité d'utiliser les dépôts Debian de Weboob pour bénéficier du système APT afin de mettre aisément à jour les modules. Pour une installation depuis les sources (sans passer par git), c'est plus contraignant.
C'est pourquoi il a été décidé de développer un système de dépôts Weboob (inspiré de celui de tucan) pour distribuer les modules et de gérer leurs mises à jour.
Les dépôts
Concrètement, lorsqu'on installe Weboob, seuls le core et les tools sont présents sur le système.
Dès que l'utilisateur cherche à ajouter un backend, si le module correspondant n'est pas installé, l'application s'occupe d'aller le chercher sur les dépôts, puis l'installe dans son ~/.weboob/.
Pour mettre à jour les modules, l'utilisateur se contentera de taper la commande suivante :
$ weboob-config update
Ça va chercher sur les dépôts si de nouvelles versions des modules installés sont présentes, et si oui les installe.
Ce n'est pas plus compliqué que ça pour l'utilisateur, qui se contente de mettre à jour de temps en temps, ou lorsqu'il rencontre un problème avec un module, pour vérifier si un correctif n'est pas déjà mis à disposition.
Architecture
Un dépôt est un répertoire servi par HTTP qui contient un fichier modules.list, ainsi que, pour chaque module, un .tar.gz (le module lui-même) et un .png (son icône).
Il existe un dépôt pour chaque version de Weboob, avec plusieurs déclinaisons : main et nsfw.
Côté client, chaque utilisateur possède un fichier ~/.weboob/sources.list contenant les liens vers les dépôts.
Par défaut, il contient :
# List of Weboob repositories # # The entries below override the entries above (with # backends of the same name). http://updates.weboob.org/%(version)s/main/ # To enable NSFW backends, uncomment the following line: #http://updates.weboob.org/%(version)s/nsfw/ # DEVELOPMENT # If you want to hack on Weboob backends, you may add a reference # to sources, for example: #file:///home/rom1/src/weboob/modules/
Un éditeur externe peut donc créer son propre dépôt sur lequel il distribue ses propres modules Weboob.
L'outil weboob-repos permet de gérer un dépôt. Lorsqu'un module est mis à jour, sa version (sous forme AAAAMMJJHHMM) est incrémentée.
Développement
Afin de développer des modules sans avoir à les uploader sur un véritable dépôt pour les tester, il est possible de référencer des pseudo-dépôts locaux.
Pour ce faire, il suffit de spécifier le chemin vers le répertoire contenant les modules de cette manière :
file:///path/to/modules/
Après un weboob-config update, les modules qui s'y trouvent sont utilisables directement.
Contrairement aux dépôts distants, les modules des dépôts locaux n'ont pas à être installés. Ils sont chargés directement depuis le répertoire indiqué dans le sources.list.
Conclusion
Ce mode de distribution des modules permet de pousser des mises à jour de modules immédiatement pour tous les utilisateurs d'une version donnée. Pour tester, il vous suffit d'installer la version git, et de lancer une update pour installer tous les modules référencés dans votre fichier ~/.weboob/backends.
La prochaine étape devrait être de sécuriser le téléchargement de ces modules, en utilisant un système basé sur GPG pour signer les tarballs.
Télécharger une recherche de vidéos
Les applications consoles de Weboob fournissent tout un tas d'options et de paramètres qui peuvent paraître complexes ou superflues pour les utilisateurs qui ont eu l'audace de lire la sortie de --help, mais elles apportent quand même la possibilité d'étendre les usages de Weboob.
Je pense que je vais écrire de courts billets fréquemment pour évoquer des astuces d'utilisation de Weboob qui ne sautent pas aux yeux immédiatement mais qui peuvent se révéler fort utiles.
Aujourd'hui, nous allons voir comment télécharger toutes les vidéos résultant d'une recherche faite avec videoob :
$ videoob search lol -s url \
--no-keys -f multiline | wget -i-
Si on regarde de plus près :
- search lol: la commande de recherche et le pattern voulu
- -s url: dans la sortie, on ne veut que le champ 'url' de chaque vidéo
- -f multiline: le formateur par défaut (très joli et tout) n'est pas celui que l'on veut, on prend multiline qui affiche un champ par ligne
- --no-keys: on indique que l'on ne veut pas afficher la clef du champ, mais uniquement la valeur
- | wget -i-: on pipe à wget en lui indiquant de lire les URLs dans l'entrée standard
On aurait également pu utiliser les options -b ou -n pour sélection un backend particulier ou limiter le nombre de résultats (par défaut à 10), ou même rajouter un ou deux filtres sur les résultats avec le paramètre -c.
À comparer avec une solution ruby :
videoob search lol|ruby -ne 'lambda{|a|puts a if a}[$_.scan(/\* \((.+?)\)/).flatten]'|xargs -I@ videoob download @
StandardBrowser
Ce matin j'ai effectué un changement au système de browser que je voulais faire depuis un moment et qui est de séparer la classe BaseBrowser en deux.
Nous trouvons donc maintenant deux classes :
- BaseBrowser, dont le fonctionnement reste inchangé et qui a pour objectif d'être dérivée, afin de gérer toutes les interactions possibles que l'on peut avoir avec le site web, et dont les rouages internes doivent être opaques pour l'utilisateur de l'objet.
- StandardBrowser, qui se veut être utilisable telle quelle, comme le mechanize.Browser, avec la gestion des proxy, cookies, parsers, exceptions, et autres helpers.
J'ai donc cherché à l'utiliser dans le backend OuiFM qui était cassé, et ça donne ceci. On constate que ça va être très pratique dans l'écriture de backends concis que Noé réclame de pouvoir faire depuis longtemps.
Opérations bancaires
Boobank, l'application de gestion des comptes bancaires de Weboob, est une des plus anciennes, car directement issue d'un script que j'avais développé pour le site de la BNP et qui existait avant Weboob. C'est aussi je pense l'une des applications qui a le plus de potentiel, car elle touche à un élément moteur de la vie quotidienne — l'argent — et qu'elle permet de répondre fortement au vide laissé par le fossé qu'il y a entre les sites web des banques et les besoins des utilisateurs.
En plus de permettre la visualiser de ses comptes et des opérations, et d'effectuer des transferts, ce potentiel de boobank est dans le traitement des données ainsi exportées, et des ordres que l'on pourrait automatiquement programmer. C'est de là qu'est venue dans un premier temps le plugin boobank pour Munin, permettant de grapher l'évoluer de ses comptes bancaires dans le temps :
Mais une idée plus intéressante est une application qui permettrait de mettre en relation non seulement les backends de banque, mais également ceux de messages, afin d'avoir un démon qui monitor ses comptes bancaires automatiquement et qui est capable, suivant des règles pré-établies, d'envoyer des alertes (via ces backends ICapMessagesPost), voire de prendre lui-même une décision.
L'exemple d'un fichier de configuration type de cette application boobank-monitor permet de mettre en avant les possibilités :
[main] interval = 3600 email = weboob@example.org [alert:MAIL] type = mail address = weboob@example.org [alert:SMS] type = message to = 0623456789@sms message = Attention mon gars, il ne reste que %(CHEQUE.balance)s neuros sur ton compte chèque et %(LIVRET_A.balance)s sur ton livret A. [alert:DLFP] type = message to = T@dlfp title = Donnez pour Tuxfamily message = Bonjour, nal. Le compte de Tuxfamily est dans le rouge, envoyez les brouzoufs [account:CHEQUE] id = 1234567891234567@bnporc [account:LIVRET_A] id = 4567891234567892@bnporc [account:LIVRET_JEUNE] id = 9876543219876543@bnporc [rule:Ctoomuch] if = CHEQUE.balance > 1500 1 = transfer, CHEQUE, LIVRET_A, LIVRET_A.balance - 1500 2 = alert, MAIL [rule:Cnotenough] if = EMPTY_CHEQUE and LIVRET_A_ENOUGH_MONEY 1 = transfer, LIVRET_A, CHEQUE, 500 2 = alert, MAIL 3 = alert, SMS [rule:Cwtf] if = EMPTY_CHEQUE or not LIVRET_A_ENOUGH_MONEY 1 = ACTION_PANIC [condition:EMPTY_CHEQUE] if = CHEQUE.balance < 0 [condition:LIVRET_A_ENOUGH_MONEY] if = LIVRET_A.balance > 500 [action:ACTION_PANIC] 1 = alert, MAIL 2 = alert, SMS 3 = alert, DLFP
C'est ce chantier qu'il me semble important de mettre en œuvre car la demande est importante. Rien que le fait de n'avoir commité que très récemment le support du format QIF (et encore, il faudrait supporter cette merde d'OFX) et qui a pourtant été apprécié, montre qu'il y a une attente qu'on ne devrait pas aussi tarder à combler.
Création du planet weboob
Dans le but de consolider les équipes du projet Weboob, j'ai mis en place le Planet Weboob.
Le but sera de permettre à chaque contributeur du projet de publier des articles relatifs à son travail sur tel ou tel backend, les astuces utilisées pour boobiser un site, explication de difficultés rencontrées, etc.
La langue retenue pour le moment est le français. En effet, même si Weboob est un projet
qui se veut international, la majorité des contributeurs et des sites supportés sont
français, aussi même en maîtrisant l'anglais écrit, il est plus aisé de rédiger de longs
textes lyriques dans sa langue natale.
Si par la suite cela s'avère nécessaire, on pourra changer.
Les développeurs de Weboob qui souhaitent donc pouvoir bénéficier de cette tribune peuvent m'envoyer par mail un flux RSS correspondant à une catégorie de leur blog qui ne comportera que des articles relatifs à Weboob. Le but de ce planet n'est pas de réunir les histoires de vacances ou les péripéties sexuelles des gens qui gravitent autour du projet, mais bel et bien des articles consacrés à celui-ci.