Un client "installé une bonne fois pour toute", ça n'existe pas (ou plus) car il est forcément mis à jour et le plus souvent automatiquement pour les petites mises à jour. Et il est tout à fait faisable de glisser la faille à laquelle vous faites référence (récupération des identifiants des utilisateurs) par ce moyen.
Avec le javascript, la mise en place volontaire de ce type de faille est juste un peu plus facile.
Nous étudions plusieurs pistes pour améliorer cela :
- stocker le code de l'application dans le navigateur et ne le modifier qu'en cas de réception d'une mise à jour dûment signée par la clé du gestionnaire du dépôt ; solution la plus intéressante puisque sans installation et donc utilisée par tout le monde, mais la faisabilité technique reste à valider ;
- proposer une extension de navigateur qui vérifierait que le code est correctement signé avant de l'exécuter, en utilisant le certificat HTTPS ; intéressant aussi parce que ça apporte une plus grande sécurité, mais la proportion de gens qui installeront cette extension risque d'être faible ;
- faire servir l'application par le daemon de synchronisation, ainsi elle n'est plus téléchargée à chaque fois ; comme la solution 1 sauf que ne fonctionne que sur les ordinateurs qui ont installé le daemon de synchronisation.
1.
Mais tout ceci vise surtout à résoudre le problème d'un attaquant qui diffuserait du code à notre place en piratant le serveur.
Se protéger de l'éditeur du logiciel est bien plus complexe... Mais ce type de problématique m'intéresse beaucoup. J'aimerais pousser loin la transparence (technique ici) pour arriver à réduire un maximum ce que j'appelle la "nécessité de confiance à un inconnu" : le fait d'avoir besoin de faire confiance à un inconnu ou groupe d'inconnus (l'éditeur) avant de pouvoir faire quelque chose (ici, accéder au service).
J'ai déjà pas mal réfléchi à tout cela mais votre message a indirectement attiré mon attention sur la confiance en un logiciel libre mais fréquemment mise à jour : s'il faut relire le code tous les jours pour savoir si on peut faire confiance au code ça n'est pas gérable.
[^] # Re: Hmm
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 1.
Bonjour,
Un client "installé une bonne fois pour toute", ça n'existe pas (ou plus) car il est forcément mis à jour et le plus souvent automatiquement pour les petites mises à jour. Et il est tout à fait faisable de glisser la faille à laquelle vous faites référence (récupération des identifiants des utilisateurs) par ce moyen.
Avec le javascript, la mise en place volontaire de ce type de faille est juste un peu plus facile.
Nous étudions plusieurs pistes pour améliorer cela :
- stocker le code de l'application dans le navigateur et ne le modifier qu'en cas de réception d'une mise à jour dûment signée par la clé du gestionnaire du dépôt ; solution la plus intéressante puisque sans installation et donc utilisée par tout le monde, mais la faisabilité technique reste à valider ;
- proposer une extension de navigateur qui vérifierait que le code est correctement signé avant de l'exécuter, en utilisant le certificat HTTPS ; intéressant aussi parce que ça apporte une plus grande sécurité, mais la proportion de gens qui installeront cette extension risque d'être faible ;
- faire servir l'application par le daemon de synchronisation, ainsi elle n'est plus téléchargée à chaque fois ; comme la solution 1 sauf que ne fonctionne que sur les ordinateurs qui ont installé le daemon de synchronisation.
1.
Mais tout ceci vise surtout à résoudre le problème d'un attaquant qui diffuserait du code à notre place en piratant le serveur.
Se protéger de l'éditeur du logiciel est bien plus complexe... Mais ce type de problématique m'intéresse beaucoup. J'aimerais pousser loin la transparence (technique ici) pour arriver à réduire un maximum ce que j'appelle la "nécessité de confiance à un inconnu" : le fait d'avoir besoin de faire confiance à un inconnu ou groupe d'inconnus (l'éditeur) avant de pouvoir faire quelque chose (ici, accéder au service).
J'ai déjà pas mal réfléchi à tout cela mais votre message a indirectement attiré mon attention sur la confiance en un logiciel libre mais fréquemment mise à jour : s'il faut relire le code tous les jours pour savoir si on peut faire confiance au code ça n'est pas gérable.