Bitmessage : Différence entre versions

De WikiOpenTruc
Aller à : navigation, rechercher
(Misc)
m (Pages connexes)
 
(74 révisions intermédiaires par 4 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
  
P2P, décentralisé, chiffré
+
<b><center>
 +
<span style="color:#CC0000">
 +
13/02/2018 : <br>
 +
A remote code execution vulnerability has been spotted in use against some users running PyBitmessage v0.6.2. <br>
 +
The cause was identified and a fix has been added and released as 0.6.3.2. If you run PyBitmessage via code, we highly recommend that you upgrade to 0.6.3.2. <br>
 +
Alternatively you may downgrade to 0.6.1 which is unaffected. We will release binary files for Windows and macOS tomorrow (2018-02-14).<br>
 +
In the mean time, users who use binaries should downgrade to 0.6.1 using the links below. <br>
 +
Bitmessage developer Peter Šurda's Bitmessage addresses are to be considered compromised.<br>
 +
We greatly apologize for the issue and we hope to release more information as it becomes available.
 +
</span>
 +
</center>
 +
</b>
  
Top language : python
+
NDLR : J'ai suivi le projet bitmessage pendant un certain temps.
 +
Ce projet m'a semblé présenter plusieurs soucis ... mais quel projet n'en a pas.<br>
 +
Puis il y a eu l'attaque du 13/02/2018 qui a pour le coup, concrètement, hélas validé certaines inquiétudes.<br>
  
* https://bitmessage.org/wiki/Main_Page
+
Il faut quand même noter que cette attaque ne s'est pas juste limitée à des soucis sur le logiciel et ses données.
 +
Le logiciel lui-même a carrément servi de vecteur / porte d'entrée d'attaque sur les machines noeuds.
 +
Récupération de clés, récupération de clés de cryptos-monnaies diverses et variées, etc.
 +
Tout ce qui est faisable sur une machine ouverte.<br>
 +
C'est non seulement l'utilité du logiciel qui est questionnée
 +
... mais là, non content de dysfonctionner, il s'avère en plus dangereux pour toute la machine support.
  
* https://github.com/Bitmessage/PyBitmessage sur github, projet actif en 2017
+
Et puis, à la suite de cette attaque, il y a eu la réaction, dans les jours qui ont suivi, du responsable principal du projet.
  
* https://fr.wikipedia.org/wiki/Bitmessage
+
Cette réaction n'est à mon avis pas du tout à la hauteur de l'attaque qui vient de se dérouler. Et cela sur plusieurs plans.
 +
* Déjà, il est certainement totalement illusoire de s'imaginer que la faille ayant permis l'attaque est fermée. La faille est en effet bien enkystée dans le code (novembre 2016) et témoigne de pas mal de légèreté de la part des responsables du projet. Revenir à une version n-1 ou passer à la version n+1 "corrigée" (soi-disant) en toute hâte me semble léger et tout à fait scabreux.
 +
* La rapidité à vouloir remettre les choses en route, à se repréoccuper de détails ultra-secondaires, comme si de rien n'était, mais sans témoigner de prise en compte de la gravité de la faille, ne m'inspire aucune confiance pour la suite. C'est comme s'il y avait eu une première moisson de pigeons ... et qu'on préparait benoîtement la suivante.
  
<br>
+
Il y aurait encore plusieurs autres points à souligner, mais je m'arrête là.
  
==Technique==
+
Le projet bitmessage a démarré en 2012.
 +
En 2018, l'équipe officielle de ce projet (dédié à la sécurité), compte une personne responsable. (Les canaux de discussion (wiki etc) sont verrouillés).
 +
Aucune grosse association dont la sécurité est le thème n'est sponsor ou soutien de ce projet.
  
* sauf erreur, la propagation est par flooding. Tout le monde reçoit tout (enfin du moins de son voisinage), mais seul ceux qui ont les clés décodent. (... tel quel, ça pose(rait) un gros problème de scalabilité, mais des améliorations sont envisagées sur ce point).
+
Bref, pour ce qui me concerne, ma courte expérience avec ce projet aura été très instructive, mais j'ai les plus grands doutes quant à la suite.
 +
Et j'arrête là le suivi.
  
* l'envoi d'un message passe par une PoW (pour éviter spam et attaques sybil)
 
  
* l'envoi d'un message est précédé d'une demande de clé au destinataire (vérifier les détails)
 
  
* les messages ont une durée de vie de 48h, donc pas de blockchain qui s'allonge à l'infini
+
{{Special:PrefixIndex/Bitmessage/}}
  
* Points communs avec bisq bitsquare https://bisq.network/blog/new-p2p-network/
 
Additionally to the publicly readable data like the offers there are data stored which need to remain private. There are trade process messages which are stored in a kind of mailbox in case the peer is offline. Those data are encrypted and signed and also sent to every node for storage. Only the receiver (who has the private key) can decrypt the data. A similar approach is used in Bitmessage.
 
  
<br>
+
Messagerie P2P, décentralisée, chiffrée.
  
==Install==
+
* https://bitmessage.org/wiki/Main_Page
* https://bitmessage.org/wiki/Compiling_instructions
 
  
Sur raspberry 3.
+
* https://github.com/Bitmessage/PyBitmessage sur github, projet actif en 2018
<pre>
 
... /home/pi# lsb_release -a
 
Description: Raspbian GNU/Linux 9.3 (stretch)
 
</pre>
 
  
<code>
+
* https://beamstat.com/ -> voir le chan bitmessage
apt-get update ; apt-get upgrade ; apt-get dist upgrade ; as usual
 
  
apt-get install python ; déjà installé ici
+
* https://fr.wikipedia.org/wiki/Bitmessage
  
apt-get install openssl ; déjà installé ici
+
<br>
  
apt-get install libssl-dev ; ~ 10Mo consommés
+
==Technique==
 +
* Top language : python (python est open-source)
  
apt-get install git ; déjà installé ici
+
* le whitepaper n'emploie nulle part le mot <i>blockchain</i>. Pour la bonne raison qu'il n'y en a pas (au sens bitcoin). Il n'y a pas de production de blocs toutes les n minutes, pas de scellement de blocs, etc. Chaque noeud maintient simplement un fichier SQL propre (crypté), qui contient tous les messages datés de moins de 48 heures. Il n'y a pas lieu d'y avoir d'identicité de tous ces fichiers SQL, étant donné qu'il est envisagé (pour des raisons de scalabilité) que les fichiers de messages puissent différer entre noeuds de branches (streams) différentes.
  
apt-get install python-msgpack ; 228 Ko
+
* la propagation est par flooding. Chaque noeud reçoit tout (enfin du moins de son stream),
  
apt-get install python-qt4 ; 59.4 Mo
+
* et de plus, un noeud essaie systématiquement de décoder tout ce qu'il reçoit (du fait que les identités de l'expéditeur et du/des destinataire(s) sont cryptées)
</code>
+
** (... tel quel, ça pose(rait) un gros problème de scalabilité, mais des améliorations sont envisagées sur ce point -> streams).
  
On note l'intérêt d'avoir des paquets déjà présents dans les distros de base.
+
* l'envoi d'un message passe par une PoW (pour éviter spam et attaques sybil)
  
 +
* l'envoi d'un message est précédé d'une demande de clé au destinataire (vérifier les détails)
  
Docs (si vous voulez savoir ce que font ces paquets) :
+
* les messages ont une durée de vie de 48h, donc pas de blockchain qui s'allonge à l'infini
* https://packages.debian.org/stretch/python par défaut sur Debian
 
* https://packages.debian.org/stretch/openssl
 
* https://packages.debian.org/stretch/libssl-dev
 
* https://packages.debian.org/stretch/git
 
* https://packages.debian.org/stretch/python-msgpack
 
* https://packages.debian.org/stretch/python-qt4 sauf erreur, c'est une couche graphique
 
  
 +
* plusieurs personnes ont écrit leur propre code, dans des langages autres que python, eg go, pour leur noeud
  
download du code source : <br>
+
* il y a des noeuds qui tournent sur VPS ( https://bitmessage.org/forum/index.php?topic=5219.0 )
<code>
 
git clone https://github.com/Bitmessage/PyBitmessage $HOME/PyBitmessage
 
</code>
 
  
360 fichiers, 14.1Mo. <br>
+
* a priori, serait aussi utilisable directement depuis une clé USB
NB : a priori, rien n'oblige à procéder via <code>git clone</code> <br>
 
un download classique fonctionne a priori tout aussi bien.
 
  
Mais bon, avec git on peut évidemment faire éventuellement plus de choses.
+
* Points communs avec bisq bitsquare https://bisq.network/blog/new-p2p-network/ <i>Additionally to the publicly readable data like the offers there are data stored which need to remain private. There are trade process messages which are stored in a kind of mailbox in case the peer is offline. Those data are encrypted and signed and also sent to every node for storage. Only the receiver (who has the private key) can decrypt the data. A similar approach is used in Bitmessage.</i>
 
 
<br>
 
 
 
==Contenu==
 
 
 
* 153 fichiers *.py , 1 fichier *.cpp
 
 
 
<br>
 
 
 
 
 
==Soucis possibles==
 
 
 
* il y a des IPs en clair dans le code source. a priori il s'agirait des noeuds de bootstrap. Un attaquant du réseau Bitmessage pourrait cibler ces IPs (attaque DoS ou autre).
 
* NB : Les IPs 2017 ne sont pas les mêmes qu'en 2013.
 
* on ne peut pas exclure que ces IPs soient des honey pots ?
 
 
 
* comment pourrait-on contourner ce souci ?
 
  
 
<br>
 
<br>
Ligne 96 : Ligne 84 :
 
==Concurrents==
 
==Concurrents==
  
 +
crypviser
 
* https://crypviser.network/ pour le 20 août 2018 ... site souvent inaccessible ? semble payant, au moins en partie.
 
* https://crypviser.network/ pour le 20 août 2018 ... site souvent inaccessible ? semble payant, au moins en partie.
** https://www.coingecko.com/en/coins/cvcoin
+
* https://www.canardcoincoin.com/fin-communications-centralisees-blockchain-rescousse/
** https://www.coingecko.com/en/price_charts/cvcoin/usd#panel chart date du 30/10/2017
+
* https://www.coingecko.com/en/coins/cvcoin
 +
* https://www.coingecko.com/en/price_charts/cvcoin/usd#panel chart date du 30/10/2017
  
 
* scayl ? BTsync ?
 
* scayl ? BTsync ?
  
<br>
+
* https://crypto.cat/ plutôt chat
 
 
==Liens==
 
 
 
* http://blog.spyou.org/wordpress-mu/2013/06/17/bitmessage-le-bitcoin-de-lemail/
 
 
 
* http://cryptojunky.com/2013/03/09/setting-up-and-using-bitmessage-an-encrypted-communications-platform-based-on-bitcoin/
 
 
 
* http://linuxfr.org/users/julmx/journaux/bitmessage-envoi-de-messages-chiffres-en-p2p article de 2013
 
 
 
* https://bitmsg.me/ send and receive Bitmessages directly from a web browser
 
 
 
* http://www.bortzmeyer.org/bitmessage.html
 
 
 
* https://bitmessage.org/forum/index.php?topic=1666.0 critique détaillée des faiblesses de bitmessage
 
 
 
* Bitmessage : lorsque le protocole de Bitcoin protège vos conversations https://www.nextinpact.com/news/80282-bitmessage-lorsque-protocole-bitcoin-protege-vos-conversations.htm
 
  
 
<br>
 
<br>
  
 
==Misc==
 
==Misc==
(à rebalancer où il faut)
 
  
* http://wiki.p2pfr.com/p2p/bitcoin général
+
* TLS = https://en.wikipedia.org/wiki/Transport_Layer_Security
 +
** a priori, en 2017 BM utilise la dernière version disponible TLSv1.2
  
* https://t.co/ZAkUPpFBjX https://liberapay.com
+
<br>
 
 
* http://changaco.oy.lc/ins/ INS Internet Name Server (P2P). Normalement le bénéficiaire d'un nom doit aussi contribuer à maintenir la base de noms/IPs en ligne
 
 
 
* twister reposerait sur une blockchain
 
** https://fr.wikipedia.org/wiki/Twister_(logiciel)
 
** http://linuxfr.org/news/twister-un-microblog-opensource-p2p
 
  
* https://okturtles.com/
+
==Pages connexes==
  
 +
* [[Git]] , [[GitHub]]
 +
* [[Raspberry]]
 +
* [[Twister]]
  
 
<br>
 
<br>

Version actuelle datée du 5 novembre 2024 à 09:18

13/02/2018 :
A remote code execution vulnerability has been spotted in use against some users running PyBitmessage v0.6.2.
The cause was identified and a fix has been added and released as 0.6.3.2. If you run PyBitmessage via code, we highly recommend that you upgrade to 0.6.3.2.
Alternatively you may downgrade to 0.6.1 which is unaffected. We will release binary files for Windows and macOS tomorrow (2018-02-14).
In the mean time, users who use binaries should downgrade to 0.6.1 using the links below.
Bitmessage developer Peter Šurda's Bitmessage addresses are to be considered compromised.
We greatly apologize for the issue and we hope to release more information as it becomes available.

NDLR : J'ai suivi le projet bitmessage pendant un certain temps. Ce projet m'a semblé présenter plusieurs soucis ... mais quel projet n'en a pas.
Puis il y a eu l'attaque du 13/02/2018 qui a pour le coup, concrètement, hélas validé certaines inquiétudes.

Il faut quand même noter que cette attaque ne s'est pas juste limitée à des soucis sur le logiciel et ses données. Le logiciel lui-même a carrément servi de vecteur / porte d'entrée d'attaque sur les machines noeuds. Récupération de clés, récupération de clés de cryptos-monnaies diverses et variées, etc. Tout ce qui est faisable sur une machine ouverte.
C'est non seulement l'utilité du logiciel qui est questionnée ... mais là, non content de dysfonctionner, il s'avère en plus dangereux pour toute la machine support.

Et puis, à la suite de cette attaque, il y a eu la réaction, dans les jours qui ont suivi, du responsable principal du projet.

Cette réaction n'est à mon avis pas du tout à la hauteur de l'attaque qui vient de se dérouler. Et cela sur plusieurs plans.

  • Déjà, il est certainement totalement illusoire de s'imaginer que la faille ayant permis l'attaque est fermée. La faille est en effet bien enkystée dans le code (novembre 2016) et témoigne de pas mal de légèreté de la part des responsables du projet. Revenir à une version n-1 ou passer à la version n+1 "corrigée" (soi-disant) en toute hâte me semble léger et tout à fait scabreux.
  • La rapidité à vouloir remettre les choses en route, à se repréoccuper de détails ultra-secondaires, comme si de rien n'était, mais sans témoigner de prise en compte de la gravité de la faille, ne m'inspire aucune confiance pour la suite. C'est comme s'il y avait eu une première moisson de pigeons ... et qu'on préparait benoîtement la suivante.

Il y aurait encore plusieurs autres points à souligner, mais je m'arrête là.

Le projet bitmessage a démarré en 2012. En 2018, l'équipe officielle de ce projet (dédié à la sécurité), compte une personne responsable. (Les canaux de discussion (wiki etc) sont verrouillés). Aucune grosse association dont la sécurité est le thème n'est sponsor ou soutien de ce projet.

Bref, pour ce qui me concerne, ma courte expérience avec ce projet aura été très instructive, mais j'ai les plus grands doutes quant à la suite. Et j'arrête là le suivi.



Messagerie P2P, décentralisée, chiffrée.


Technique

  • Top language : python (python est open-source)
  • le whitepaper n'emploie nulle part le mot blockchain. Pour la bonne raison qu'il n'y en a pas (au sens bitcoin). Il n'y a pas de production de blocs toutes les n minutes, pas de scellement de blocs, etc. Chaque noeud maintient simplement un fichier SQL propre (crypté), qui contient tous les messages datés de moins de 48 heures. Il n'y a pas lieu d'y avoir d'identicité de tous ces fichiers SQL, étant donné qu'il est envisagé (pour des raisons de scalabilité) que les fichiers de messages puissent différer entre noeuds de branches (streams) différentes.
  • la propagation est par flooding. Chaque noeud reçoit tout (enfin du moins de son stream),
  • et de plus, un noeud essaie systématiquement de décoder tout ce qu'il reçoit (du fait que les identités de l'expéditeur et du/des destinataire(s) sont cryptées)
    • (... tel quel, ça pose(rait) un gros problème de scalabilité, mais des améliorations sont envisagées sur ce point -> streams).
  • l'envoi d'un message passe par une PoW (pour éviter spam et attaques sybil)
  • l'envoi d'un message est précédé d'une demande de clé au destinataire (vérifier les détails)
  • les messages ont une durée de vie de 48h, donc pas de blockchain qui s'allonge à l'infini
  • plusieurs personnes ont écrit leur propre code, dans des langages autres que python, eg go, pour leur noeud
  • a priori, serait aussi utilisable directement depuis une clé USB
  • Points communs avec bisq bitsquare https://bisq.network/blog/new-p2p-network/ Additionally to the publicly readable data like the offers there are data stored which need to remain private. There are trade process messages which are stored in a kind of mailbox in case the peer is offline. Those data are encrypted and signed and also sent to every node for storage. Only the receiver (who has the private key) can decrypt the data. A similar approach is used in Bitmessage.


Concurrents

crypviser

  • scayl ? BTsync ?


Misc


Pages connexes