Auteur/autrice : webmaster

Problème de signature

Je coince sur la génération de lien, plus exactement sur la signature. Le résultat pour un lien déjà connu ne me donne pas la même signature… alors que le code pour vérifier la signature des liens existants marche bien maintenant.

Le code qui ne me retourne pas la bonne valeur :

function _l_gen($dat, $typ, $src, $dst, $met)
{ global $nebule_publ_entite, $nebule_priv_entite, $nebule_pass_entite;
  if ($nebule_publ_entite == '') return(false);
  if ($nebule_priv_entite == '') return(false);
  if ($nebule_pass_entite == '') return(false);
  if (! file_exists("o/$nebule_priv_entite")) return(false);
  if ($typ == '') return(false);
  if ($src == '') return(false);
  if ($dst == '') return(false);
  if ($met == '') return(false);
  if ($dat == '-') $dat = date(DATE_ATOM);
  $privcert=(nebReadObjText($nebule_priv_entite,10000));
  $private_key=openssl_pkey_get_private($privcert, $nebule_pass_entite);
  if ($private_key === false) { return(false); }
  $data='_'.$nebule_publ_entite.'_'.$dat.'_'.$typ.'_'.$src.'_'.$dst.'_'.$met;
  $hexsign='';
  $binary_signature='';
  $hashdata=hash("sha256", $data);
  $binhash = pack("H*", $hashdata);
  $ok=openssl_private_encrypt($binhash, $binary_signature, $private_key, OPENSSL_PKCS1_PADDING);
  unset($private_key);
  unset($hashdata);
  unset($binhash);
  if ($ok === false) return(false);
  $hexsign = bin2hex($binary_signature);
  return("$hexsign.sha256$data");
}

Avancement

Le code de sylabe à progressé sans cesse même pendant mes vacances, mais les versions intermédiaires ne sont pas encore assez stables pour être mise en ligne.

En changements récents, je mettais en place le Téléchargement et suivi de liens u et suite avec notamment un fichier .htaccess . Mais suite à la réflexion Echanges via http – suite, j’enlève tout ça pour revenir à une solution finalement plus simple…

Il faut attendre encore un peu pour une mise en ligne…

T̩l̩chargement et suivi de liens u Рsuite

Suite au post Téléchargement et suivi de liens u, la réflexion peut être poussée plus loin.

Le dossier /o/ va recevoir tout un tas d’objets, dont du code divers, varié et avarié. Si le serveur web qui héberge sait interpréter du code (donc autre chose que du HTML), alors le dossier /o/ ne doit pas être accessible directement. Dans ce cas la redirection et le traitement par une interface dédiée telle que sylabe est obligatoire.

Téléchargement et suivi de liens u

Avant de mettre en place le téléchargement d’objets et de liens via sylabe et non sur une URL directe, je voulais terminer la résolution du suivi des liens de type mise à jour u.

Mais la mise à jours des icônes dans sylabe est bloquée en l’état faute de pouvoir les faire télécharger. Encore que leur chargement peut être fait par une URL directe. C’est dans ce cas le serveur web qui donne le bon type mime.
Et puis ce n’est pas au serveur, donc aux programmes derrières, de déterminer si on envoi l’objet demandé ou sa version la plus à jour, c’est à dire un autre objet. Le serveur doit qui qu’il arrive transmettre le bon objet ou une erreur.

Cependant, la méthode de chargement direct par une URL ne permet pas le chargement de contenus chiffrés. Ou plutôt ils sont bien téléchargés, mais chiffrés. Il n’est pas possible de les faire afficher directement dans le navigateur. La seule possibilité est de déchiffrer l’objet chiffré dans une zone réservée, puis de permettre le transfert vers le navigateur.

De base, on peut donc tout simplement accéder aux objets et liens publics sans modifier le serveur web. Il n’est donc pas besoin d’insérer non plus de code dans le programme index.php .
Pour les objets chiffrés (privés), il faut cependant être authentifié. Cela ne peut être réalisé que par programme sylabe.php .

Si l’on veut rester dans un fonctionnement standard de nebule, y compris pour les objets privés, il faudra ajouter un fichier .htaccess (pour Apache) qui transformera les demandes en /o/ et /l/ vers leur équivalent, c’est à dire /?o= et /?l= . Le programme sylabe.php se chargera ensuite de transmettre l’objet en zone public ou privée en fonction de l’état de l’authentification…

EDIT 13/09/2013 : Grosse erreur corrigée, ce n’est pas un lien f mais un lien u…

Avancement

Hier soir, j’ai appliqué les modifications d’arborescence proposées dans le précédent post Arborescence sur serveur web.

Tous les serveurs web qui héberge une copie de sylabe ont été modifiés en conséquence, c’est à dire :

Ces sites sont un peu lents dans le traitement de sylabe parce que la validité des liens est vérifiée systématiquement pendant le traitement, y compris la signature… On s’assure ainsi que les liens sur le serveur sont valides, mais c’est beaucoup plus lent. Ce comportement ne sera pas forcément celui par défaut plus tard.

Arborescence sur serveur web

L’implémentation de référence de nebule en bash utilise cette arborescence pour son fonctionnement :

  • pub
    • o
    • l
  • priv
    • o
    • l
  • tmp

On trouve notamment dans pub et priv un fichier e contenant l’identifiant de l’objet entité, la clé publique pour le premier et la clé secrète pour le seconde.

Dans pub, on peut encore trouver sur certaines machines gnav.php et un répertoire g. C’est la page de tracé du graphe d’un objet. Cette page php est vouée à disparaître sous cette forme.

Le contenu du répertoire pub avait été volontairement séparé, c’est à dire les répertoires o et l en dessous, des scripts et autres fichiers bash, clés RSA, etc… Est apparu avec le temps les dossiers priv et tmp pour manipuler les objets soit qui ne devaient pas être diffusés soit les fichiers temporaires. Et le répertoire pub à rapidement servit à stocker aussi de nouvelles pages web en php comme gnav.php et webcli.php . Ce répertoire devenait donc directement public, ce pour quoi il est fait dès le début en fait…

Lors de la mise en place de sylabe, j’ai conservé cette arborescence par défaut. Mais elle pose problème.
Les objets et liens sont téléchargés sur des url du type http://site.net/o/ ou http://site.net/l/ . Or le serveur web utilise par défaut le dossier parent pour l’affichage des pages. Cela nécessite de faire le lien entre le pseudo dossier o et son réel emplacement en pub/o . En fonction du système d’exploitation et du logiciel serveur web, la manière de contourner ce problème est différente. Ce n’est pas vraiment optimal.

Il faut cependant pouvoir faire cohabiter simultanément les scripts bash et les pages php, voir peut-être d’autres choses par la suite.

Il y a une solution, remettre le dossier pub comme répertoire par défaut dans le serveur web, c’est à dire l’arborescence racine. Les scripts bash peuvent rester dans le répertoire parent sans entrer en conflit avec les pages php dans pub, tout en exploitant la même base d’objets et de liens. En bash, les objets sont dans pub/o alors que en php ils sont dans o tout simplement.

Et comment dans sylabe va-t-on gérer les fichiers temporaires et fichiers à ne pas partager ?
Cela peut être fait de deux façons. Soit on crée un sous dossier avec des restrictions via un fichier .htaccess. Cette méthode à inconvénient de se restreindre à un seul type de serveur web. Et plus grave, tous les objets privés de toutes les entités connectées sont ainsi mélangés… Soit on fait du déchiffrement à la volée et du stockage de petits objets dans la session php.
Les fichiers temporaires peuvent eux être mélangés tant qu’ils ne sont pas écrasés ou réutilisés entre deux sessions différentes. Dans ce cas il faut peut-être prévoir un sous dossier tmp.

Avancement

Le code n’est pas publié ce soir puisque cela n’a pas encore d’intérêt, mais la fonction _l_lsx sait maintenant supprimer les liens qui ont un lien similaire mais en x, ainsi que les liens x aussi. Ainsi, a notion de suppression de lien devient fonctionnelle dans sylabe.

Par contre, seuls les liens x générés par la même entité signataire sont pris en compte. Il faudra ajouter une sorte de pondération social pour accepter ou non la suppression d’un lien par une entité tierce. C’est à dire gérer les relations de confiances…

Par la suite, on va pouvoir gérer les liens de type u. Et en particulier la mise à jour de code php. On doit pour cela savoir suivre les mises à jours de ces codes, mais aussi de tenir compte de suppressions de ces mises à jours, en cas de problème…

Avancement

Aujourd’hui, correction de quelques petits buggs sur le code de index.php, pas d’évolution.

Dans la vue obj, les objets sont maintenant affichés dans l’ordre alphabétique. C’est un peu plus facile pour retrouver un objet… Mais vue la quantité d’objets, ce n’est certainement pas la vue la plus intéressante. Côté performance, la lecture des objets ainsi que leur réorganisation prend environ une seconde alors que leur affichage reste de l’ordre de la minute pour environ 9000 objets. Il faudra peut-être supprimer l’affichage du type et du nom de chaque objet pour revenir à des temps plus raisonnable… CF http://zulu.nebule.fr/sylabe.php?mod=obj

Avancement

Les images des logos nebule et sylabe qui apparaissent dans les interfaces web ont été encodées pour être intégrées directement dans la page html. Cette méthode évite de traîner la copie de ces images vers de nouveaux sites web. Tout est dans un seul fichier php, ou trois dans le cas de sylabe.
Cependant, ce n’est pas tout à fait neutre pour les performances. Ces images qui auparavant se retrouvaient tout de suite dans le cache du navigateur, et donc n’étaient plus téléchargées par la suite, sont maintenant systématiquement re-téléchargées avec la page html.
Il est prévu pour palier ce petit problème de nébuliser plus tard ces images et simplement d’y faire référence comme objet dans le code php. On résoudra ainsi à la fois le problème de téléchargement multiple et le problème des fichiers images annexes. Il en sera de même pour les différentes petites icônes que l’on trouve un peu partout dans sylabe…

Un autre changement a été mis en place. Un changement pas très visible mais assez important.
La page par défaut d’un site web nebule/sylabe référence en fait le fichier index.php . Au lieu de simplement afficher la page par défaut de nebule, cette page commence enfin à devenir une page de démarrage à par entière. Elle peut en effet créer tous les dossiers et fichiers nécessaires à nebule et donc aussi à sylabe. Une partie du code sait télécharger l’entité bachue qui va référencer les programmes de base. Ce n’est que le début, à terme il suffira de poser ce fichier index.php spécifique à nebule pour avoir instantanément la possibilité de mettre en place sylabe ou d’autres interfaces.
L’entité bachue est destinée à gérer la diffusion des différentes implémentations de référence.
La page index.php spécifique à nebule peut appeler par défaut une interface et rester invisible. Mais elle pourra bientôt vérifier aussi que l’interface appelée (un objet nebule) n’a pas été modifiée, dès que sylabe sera intégralement nébulisé.
Cela donne par exemple la page http://stephane.nebule.fr/?bootstrap :

20130819capture

Si on supprime l’option /?bootstrap du lien, on arrive aujourd’hui directement sur sylabe. Cela pourra être personnalisé.

Avancement

Cette fois-ci, la vérification de la signature des liens marche enfin !
C’est une étape importante, la première en fait, puisque c’est ce qui permet de vérifier la validité des échanges, c’est à dire les liens.

Suite à ça, on peut maintenant espérer permettre la génération de nouveaux liens, mais aussi la réception de liens déjà signés. Cette réception marche d’ailleurs, pas la génération, mais si les liens existants sont bien vérifiés, il y a encore un petit bugg qui empêche la vérification d’un lien importé. Ça progresse…
Il y a aussi des variables permettant de désactiver la synchronisation d’objet ou de liens depuis le serveur, mais aussi le transfert d’objet ou de lien vers le serveur. CF upl sur zulu :

capture2013081101

D’un autre côté, il y a des problèmes avec certaines fonctions dans php.
La fonction hex2bin n’est pas reconnu avant la v5.4.0 alors que la fonction inverse bin2hex était déjà présente dans la v4. Il faut à la place utiliser la fonction pack (v4).
La fonction openssl_verify est bien présente depuis la v4.0.4, mais sha256 n’est pas reconnu dans les fonctions de hashage supportées avant la v5.4.8 . Il faut à la place utiliser des fonctions plus basiques comme hash (v5.1.2) et openssl_public_decrypt (v4.0.6). Les anciennes versions stables de Debian et Ubuntu incluaient déjà php en v5.3, je pense que c’est maintenant suffisamment ancien pour ne pas risquer la perte de fonctionnalité.
Donc soit on est compatible uniquement avec des versions très récentes de php, et donc adieux les versions pré-packagées pour serveur (Debian ou Ubuntu par exemple). Bienvenue à la compilation à la demande et tous les problèmes de maintenances inhérents. Soit on utilise d’autres fonctions au prix peut-être de performances moindres, c’est donc le cas pour l’instant, et ça marche :

capture2013081102

Avancement

Je suis toujours en train d’essayer de faire fonctionner la vérification des signatures des liens. Ça ne marche pas mais ça progresse… Je corrige des erreurs au fur et à mesure.

En partant d’un exemple de signature/vérification trouvé sur internet, j’ai pu vérifier que l’ensemble est capable de le faire. C’est ajouté dans le mode log. Cela permet de savoir si le serveur fonctionne correctement et sait signer et vérifier un lien :

capture2013081001

Puisque ce petit bout de code fonctionne, il n’y a pas de raison qu’il ne fonctionne pas ailleurs…

Avancement

Pour cette fois, c’est la possibilité de synchronisation qui a été ajouté. Cela concerne deux choses en fait.

Pour tout objet, on a un lien web dans l’interface qui permet de synchroniser les liens de cet objet sur les entités connues. Ce lien web est présent en haut de la description de l’objet et ouvre un nouvel onglet du navigateur pour afficher l’avancement de la synchronisation. La vérification de la signature des liens n’étant pas encore au point, ces liens ne sont pas inclus localement aux reste des liens.

Pour tout objet dont on ne dispose pas localement d’une copie, on peut essayer de le télécharger chez les entités connues. Ce lien web est présent uniquement avec l’alerte signalant l’absence d’un objet et ouvre aussi un nouvel onglet du navigateur. Si trouvé et valide, le téléchargement de l’objet est effectif.

Voici ce que cela donne, en haut à gauche :

capture01

Et la page de synchronisation ressemble à ça :

capture02

Les liens web dans l’interface, mais surtout cette page, ne sont accessibles que si l’entité est déverrouillée. Cela permet en principe d’éviter le téléchargement d’objets non désirés (malveillant ou autres) sur un serveur.

Avancement

Je galère avec la vérification de la signature des liens. Ces liens sont valides puisqu’ils ont été générés et vérifiés via l’implémentation de référence de nebule en bash.
En fait, je n’ai pas encore trouvé comment transmettre les différentes données à la fonction openssl_verify, si c’est bien celle qui doit être utilisée. Les différentes erreurs qui remontent ne sont pas assez explicites. Les exemples sur le web ne m’aident pas beaucoup, tout le monde copie-colle la documentation du site de php. Et l’exemple ne marche pas.

Il y a aussi un problème de gestion de sha2 par openssl dans php. La variable OPENSSL_ALGO_SHA256 n’est pas reconnu pour php en version inférieur à la 5.4.8 (cf lien). Par défaut, c’est sha1. Par exemple, sous Ubuntu Linux 12.04, la LTS donc, on est en 5.3.10 (cf lien). Il faut passer en 13.04 pour avoir une version suffisante… alors que cela fait maintenant quelques années que l’on préconise l’utilisation de sha2 au lieu de sha1 dans tout nouveau projet!
Pour Debian Linux, ce n’est pas mieux, il faut passer en unstable pour avoir une version suffisante (cf lien). La nouvelle Wheezy ne nous aidera pas.

Avancement

Le déverrouillage (connexion) d’une entité est maintenant fonctionnel. Le mot de passe est vérifié sur la clé privé. Si la clé privée ne peut être lu, la connexion échoue.

Il va maintenant être possible de créer des liens directement depuis l’interface de navigation. Et à terme, il sera possible de déchiffrer des objets.

Vérification de mot de passe de clé RSA

J’ai eu un peu de mal à vérifier si le mot de passe saisie dans sylabe pour déverrouiller une entité était le bon mot de passe.

Il semble y avoir un petit bugg de la fonction openssl_pkey_get_private. Lorsque l’on charge le fichier contenant la clé privée chiffrée et qu’on le passe à cette fonction, on a le code erreur suivant :

error:0906D06C:PEM routines:PEM_read_bio:no start line

En fait, il faut envoyer la concaténation de la clé publique puis de la clé privée…

Le code php qui fonctionne :

$publcert = file_get_contents("pub/o/$nebule_publ_entite");
$privcert = file_get_contents("pub/o/$nebule_priv_entite");
$cert = "$publcert$privcert";
$r = openssl_pkey_get_private($cert, $nebule_pass_entite);
if ( $r === false ) { return false; } else { return true; }

Ce serait bien si le message d’erreur était plus clair… comme dirait l’autre…

Maintenant que je peux m’assurer si le mot de passe est bon, je peux essayer d’utiliser la clé RSA :-)

Avancement

Les changements ne sont pas très visibles sur l’interface, mais ça avance tout de même.

J’ai fait un peu d’optimisation de code afin d’accélérer l’affichage des objets, et surtout des liens. Gain qui m’a permit de faire un tri par date des liens à afficher.
Un code de lecture basique des liens avait été copié/collé partout (oui je sais c’est pas bien). Il faut remplacer ce bout de code par l’appelle à une fonction dédiée. Il en reste encore mais le principal est fait.

Et puis il fallait aussi sécuriser un minimum la lecture du contenu des objets qui sont affichés dans la page web. Il ne s’agirait pas de permettre une injection de code via un objet piégé.

Par contre, la crypto, ce n’est pas encore pour cette fois-ci…

Sur la vue d’affichage des liens, chaque lien est directement affiché en tout petit avant sa traduction. C’est vraiment petit, mais le lien est là :