Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B084A7A for ; Sat, 9 Nov 2019 19:33:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D71A45F4 for ; Sat, 9 Nov 2019 19:33:28 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id z26so9407760wmi.4 for ; Sat, 09 Nov 2019 11:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=5X8WAw/4/ntJd9R8ltMuamtIuWvHPbjyjP18NPEjpkQ=; b=m09k0Rd7GR8KLPmZRxmE7tMCQO3n5Yk1KO1Fj8m5msNMPpcA00SLpPEGKr5BLasG0U 3pX+xF1OJbrC9hbThKRnQnm0SLLGbrmsucLkXtr+hSpjvsN5WpXHrFKyosopHW2PVmIq aWFDLEWcdnwpU9/tCIXJyNhUp+XM4Jx+YB8P6a8OuNIhttPiu3l8TiY3C70o5eKn07Jq aVHGieQOS6lkY/IaqOkL7KPw1OLKimsTDzpZbjjsRaLc4vArSD1FrrVzlHL5KiVOvv0u vBIV6HQry6JDEIJsrgmPW4EE9epPlBYo8MTOXWB9lDRvL1pRii+0lw8Ekzb9OBDqPhEy nFMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=5X8WAw/4/ntJd9R8ltMuamtIuWvHPbjyjP18NPEjpkQ=; b=cOOZ/QApLXMD80N2b6qFSVUy8PjNbKW+0EY1vlkUJCLV9kQS3hXzRe9hRCPdPVVrjO 3om2Gi6hmwMmF3t4K6vfUeou1bKx+rQCmh6acR7Tgiei9BJ9/EoJNuJ6WNSCVBJ16yEP jH/EBMoKUqG7gM5SsKNcyeGHBjzYorUqgtRjcVOaT+5k2l7t4HCDdQb8CyuZARNITVn9 QFIlAOUzUvrYxCmTstD0Uw9GTGcqgVMr7T5Mop/gvGiC4i9CvopkfUOV37bpT25lzOG7 vDpK0O7xeFe9W7J2QuiuZ3zxtoRnwLto5hLayyJnyfhpiHjHzD4bZmeoAcpeq2bY/69E ZmVg== X-Gm-Message-State: APjAAAVnngFd9M58KzmVwwknOlYbYt2dFmj6mc4qco6t4Scu+vsPHFpI uV5G+r4VaINwPmx/aR0DeVo= X-Google-Smtp-Source: APXvYqyno7iotUp11qcxA9eiePW50uzHNod//5+dmuYSFeINvxaRJ9Ohdkvacm7bghR6wCTEI9uSuw== X-Received: by 2002:a1c:6683:: with SMTP id a125mr12545416wmc.74.1573328007321; Sat, 09 Nov 2019 11:33:27 -0800 (PST) Received: from ?IPv6:2a01:cb1d:44:6500:9d6d:71b2:cb71:cb17? ([2a01:cb1d:44:6500:9d6d:71b2:cb71:cb17]) by smtp.googlemail.com with ESMTPSA id i13sm9467508wrp.12.2019.11.09.11.33.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 11:33:26 -0800 (PST) To: LORD HIS EXCELLENCY JAMES HRMH , Bitcoin Protocol Discussion , Luke Dashjr References: <201911081507.40441.luke@dashjr.org> From: Aymeric Vitte Openpgp: preference=signencrypt Autocrypt: addr=vitteaymeric@gmail.com; prefer-encrypt=mutual; keydata= mQINBFdW8uABEAC7HJScbB2d/lmYoY5Cn9loEjJwfLs1LC3om030bWFGiH3Ceo5XeHUT94rw Pi+HaHU8ea94425SXIFsnqp/ouoT/8Ffn6vED0OoRmK0jE4fqDApXSpoL2mHX9PAGdUItMtD YrxBiBZNfMkctEsm4NrQ4TCvB3Yrm6Fc69inXJjUoYgPw5tHafEeI8Qwh0j99JZZDKcAqIra JF3MPc59rATz0qOJtRP9EpsPVFwjJe13zN6CHILwiVgrL8EtT5WKCVO6ATxh60LHi8+MwPxV V31zp/NNI5Hck+XocEMO98ZvUu9X8ZxmnOk/+9pBxXEwUqSGUNWdmPJLncpI23Usce3u/MOo M2C4T4rD4J0XrXiyBvbeTvwq4qVNlyggeWzlBH+YpEYgDctPq4gNh4eoTtAkf8URtBeke5bQ CGdaZt/jxv8nvmxs9V/iSyg5ldJLQktHStXOo0OZ7FEB2C6Ggtymm4hm2MHYg07Q1MGJrFLa oJZkJ3JeXnVsZMam7ypQtld6rRa96CvH+llXwux6aQ5hKdzmBBMQ10LlkZhkExgTawbeqdiG RMP2DjD5go6TPdAHS4NN34SBkrTWLqgWOjN/lnG77bbLnpMl0P+xBTuqw1oSXaDbcdHE2nGY lRno/ZZIfr+1Bq56DZLBX/WpnAT4f5WtofL4CxQM9SbG6byyewARAQABtCJBeW1lcmljIFZp dHRlIDxheW1lcmljQHBlZXJzbS5jb20+iQI/BBMBCAApBQJXVvLgAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQKh17NCYnrDm3WhAAlYmgtSmtfqjBvQMqkmtqiQJA aZkzFZWt6+zroduHH5/Tp8jh73gFqCUyRrl/kcKvs2+XQhfrOwk1R6OScF25bpnrZSeuyJnZ MZu4T0P2tGS8YdddQvWUHMtI9ZnQRuYmuZT23/hgj1JnukuGvGLeY0yDUa1xFffPN39shp5X FPMcpIVOV3bs+xjAdsyfRyO3qJAD1FGiR7ggJeoaxUbKZ6NtcVUPPRMjVTKfopkuDwKY318m BE0epfxSZ/iRhsJ0/sREUWgbgq4/QvCFwBKzgz7fTikGmf8OELWSdofmXs7gOtmMc3el8fJu W8PVa/OsIQHDmwSzvxmE8ba5M8bdwOYEraTWFArIymAAtRXKxmuYpkqKfeSlbCwae3W+pgNT 8nKYRVAFlMtIxYkmPYyMTk9kCscmSqugGWbWdnqe/dhVaa31xa1qO1tDH24D2/tjCJRQt4Jk AEWNSmjCmjfeArMEFTGlZwMTAjVXErLSPbLOsZiZhD9sjvSbfzrtJiMli2h9+Dvds+AJk1PM O8LW7cCNyFoCk4OdAxzJHobZ25G+uy4NSQEHgxLC2iuh/tugz1tOHnQczPc/3AkVVI9A5DF1 gbVRBJh6rI7sAcwuR76uoOs0Rpp7r6I66xqU/5eq8g1OsJp89tw0ppSIa0YmaxNqQZ0l3rVX o/ZwpBjtNQS5Ag0EV1by4AEQANhlz3Ywff4dY1HTdn05v0wVUxZzW2PUih+96m6EhpUrD9BT vxriKtbgxm/zl+5YAlThbrk9f0QyVTHJ95Z1/M5qjuksP9Zn3qZ/8ylANDkN2s3z8Bq/LJA+ u7+APhMqyFWK0FqNCOogClvijiKPEzkU6tmDGO6wZ5pR/u8Fdq7DGQgwgyGZZc7qstte0M7l yx7bVRlPBqvd6kyX3YubQHzkctf46nFjiYZgKawdWFsA3PCdSBupbhixL5d/t1UK9ZTiQJcf 0uhHzT06qwolFrm/ugkLDHtE4Zo3BuKch47Sms8P2hJ08gABxeJHg0ZgkIUy/Xf4nHbDCBJw T8tE8pWYWA2ECiPNo0TOCMVOueEzISUNKINfCuFHSbMQU39hgt3ofxODbAjOiO3e/iu1ptck AkuVBdtjOBP4tHRGxVrbf5EuAV5U5xtiSxMwMgojg0GIXZjnT/8uvWqcLqtJILRMmmu+WNvD oxuiJzcTJhDai9oujmxQwcpMvgrBB89KSTDyitO5XVjZqaR7Zxvvn3rM4bAms/lotv9+pTyh spazTIxb80u0ifJ6y1RxAkxQCfWwps1i3VbsM6OKX78aUyOf5V4ihXF57M37tOqPRwFvz6a+ AIIhUNMTLo2H+o6Vw9qbX8SUxPHPs6YpJ8lWQJ9OMWHE+SbaDFAi/D5hYRubABEBAAGJAiUE GAEIAA8FAldW8uACGwwFCQlmAYAACgkQKh17NCYnrDmk4Q/9Fuu0h5HvIiO3ieYA2StdE7hO vv2THuesjJDsj6aQUTgknaxKptJogNe3dDyIT+FHxXmCw0Nrbm9Q3ryl80z/G9utfFNO3Gwc q31QW3n3LJHnpqdrV3WsRzT5NwJMVtiIAGRrX8ZomtarWHT0PeEHC2xBdFzRrJtmkrwer0Wc 0nBzD7vk1XEXC9nODbmlgsesoHFgRwQBst3wClCbX1gv8aSfxQNpaf9UBC8DmyrQ621UXpBo PvcFEtWxV44vJfP0WOLCCN0Pzv2F2I66iKo7VMqbr5jlNAXJN9I1hXb7qwYJmBC9j5oeEoqv A9d44WWpxrdAr8qih4Nv89k9+9F6NoqORY3FGuVDKiW8CVhCmGT7bIvNeyicVBZFipXqPcKL VFduO2c5Ubc2npMWLUF1k9JJc9tH75l3+F/0RbYVTzGAZ+zSaudwR6h8YiCN2DBZGZkJEZbh 3X/l6jtijMN/W9sPHyyKvm/TmeEC27S3TqZPZ8PUQLxZC70V6gMbenh01JdSQsn5t8Ru0RNh Blt0g7IyZyIKCE9b+TyzbYpX6qgqEBUHia5b0vyPtQacWQlZ8uqnghAqNkLluEsy7Q/7xG6M wXUYEDsFOmB9dKOzcAOIhpxlVjSKu5mzXJ11sEtE8nyF5NJ/riCA7FGcjlki3zIpzQUNo9v7 vXl2h6Tivlk= Message-ID: <256d3775-814a-02ad-8152-f2b689219653@gmail.com> Date: Sat, 9 Nov 2019 20:33:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B642A22E6FC0E7B4B63D06DA" Content-Language: fr X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, T_REMOTE_IMAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: "security@bitcoincore.org" Subject: Re: [bitcoin-dev] CVE-2017-18350 disclosure X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2019 19:33:31 -0000 This is a multi-part message in MIME format. --------------B642A22E6FC0E7B4B63D06DA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit ??? Well, you obviously don't know what you are talking about and did not even consider reading correctly what I wrote, neither to read node-Tor What you are saying here is quite trivial, typical of people thinking that the Tor network will solve everything and is not centralized (but you seem unsure about it), that's not the case, it's completely wrong and the "normal" use of the Tor network is for browsing only, basically the Tor network is still the same since years: 1000 guards, 1000 relays, 1000 exits (so not "hundreds", happier, and there are of course intersections between them, knowing that they are the supposed working nodes as tested by node-Tor), quite small at the end with finally many misbehaving nodes among the 3000 set, not at all able or willing to handle bitcoin nodes load Using bitcoin with the Tor network is absurd, using socks proxy with bitcoin is absurd too (I don't get the comparison with a http proxy, nothing to do),  except if limited to a local use, ie you socks proxy inside your device, for example to pipe to node-Tor, but this remains as a whole dangerous if the local proxy has been hacked, as we could see recently with malware Tor sw being used by people Using the Tor protocol for bitcoin is not absurd at all (do you understand the difference?) + browsers, webRTC, etc I will not repeat what I wrote Please do some readings or consider at least what I sent, or ask questions if what I am saying is unclear for you But from my standpoint the discussion on this list is not about explaining all of this that is probably well known by everybody but what can/could be next to anonymize/help anonymizing bitcoin  when required and make it a real p2p network Unfortunately I am afraid that we get moderated here because that's not the place to give basic lessons about Tor that you don't know Le 09/11/2019 à 12:42, LORD HIS EXCELLENCY JAMES HRMH a écrit : > Socks proxies have their use in controlled gateway infrastructure and > is a relevant feature for any software required to operate behind a > secure network boundary and allows for UDP connectivity (whether it is > utilised in any particular application) which a HTTP proxy does not. > > You are obviously not well abreast of the Tor project, regardless of > whether it seems centralised, whether it is or it isn't, the Tor > project is to allow anonymity and connection privacy. For this it > works very well and there seem to be hundreds of known Tor nodes, to > be known they are not isolated and are connected. > > Even if an exit node performs all logging it is only aware of the node > one hop up but the originator is higher still. In the case where we > perform a Tor cluster and make hundreds of guard, middle and exit > nodes we still cannot with absolute certainty say that the connecting > node is the originator and, the eventual Bitcoin node is still unaware > of the originator IP which is the primary objective. Otherwise, can > you hide your IP from your ISP would be a better goal? > > You may prefer to familiarise yourself first with the history of Tor, > even a brief from [WikipediaTor_(anonymity_network) > ](https://en.wikipedia.org/wiki/Tor_(anonymity_network)) > and consider some of the possible uses, and consider how its > implementation benefits the privacy and anonymity of Bitcoin in public > where it is allowed in many countries; Tor is just as useful in > countries where Bitcoin is allowed to hide from third-parties. You may > also enjoy an example of activating Bitcoin Cores Tor implementation: > [How can I setup Bitcoin to be anonymous with > Tor?](https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070) > > > Tor (anonymity network) - Wikipedia > > Tor is free and open-source software for enabling anonymous > communication.The name is derived from an acronym for the original > software project name "The Onion Router". Tor directs Internet traffic > through a free, worldwide, volunteer overlay network consisting of > more than seven thousand relays to conceal a user's location and usage > from anyone conducting network surveillance or traffic analysis. > en.wikipedia.org > > > > > bitcoind - How can I setup Bitcoin to be anonymous with Tor? - Bitcoin > Stack Exchange > > Bitcoin is billed as many things, among them its anonymity is highly > regarded. While it is true that a transaction does not identify a user > or wallet, recent news shows that there is the potential ... > bitcoin.stackexchange.com > > > > There should be no rational consideration that gives rise to reducing > Tor connectivity, possibly v3 integration will be coming along. > > Regards, > LORD HIS EXCELLENCY JAMES HRMH > > > ------------------------------------------------------------------------ > *From:* Aymeric Vitte > *Sent:* Saturday, 9 November 2019 6:40 AM > *To:* LORD HIS EXCELLENCY JAMES HRMH ; Bitcoin > Protocol Discussion ; Luke > Dashjr > *Cc:* security@bitcoincore.org > *Subject:* Re: [bitcoin-dev] CVE-2017-18350 disclosure >   > > Sure, but what is questionable here is the use of SOCKS proxy, for Tor > I think as the main purpose, making it dangerous for the "whole > bitcoin world" while it's something like of zero interest/use (or > please let me know what it is beside Tor) > > The Tor network is very centralized and not designed at all to handle > p2p networks (which bitcoin is still not), it is designed to be used > via the Tor Browser to browse the web and to hide web servers, not > bitcoin nodes, and there are a lot of misbehaving/dangerous nodes > there, there is no encryption in bitcoin protocol, an exit node can > fake whatever it likes, this seems to be a use case as far as I can > see, but even if the initiator is configured to connect to a hidden > bitcoin node, I don't see the point > > I have advertised recentlty the open sourcing of node-Tor > (https://github.com/Ayms/node-Tor) here > > This one is designed for p2p, not over the Tor network but using the > Tor protocol, as simple as bitcoin.pipe(node-Tor), or protocol>.pipe(node-Tor), which is the finality of the project as far > as I see it since years (maybe see > http://www.peersm.com/Convergence.pdf even if I would modify some > parts now) > > Inside servers or browsers acting as servers also (WebRTC or > WebSockets), bitcoin peers (servers/browsers) relaying the bitcoin > anonymized protocol using the Tor protocol (and not the Tor network) > between each others, there is no story of exit nodes here and rdv > points would not apply for bitcoin use, this "just" adds the internal > missing encryption and anonymity layer to the bitcoin protocol > > Personally I would remove the socks proxy interface from bitcoin core, > independently of Tor this can be misused too and offers absolutely > zero security > > > Le 08/11/2019 à 18:03, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev > a écrit : >> It goes without saying in that all privately known CVE should be >> handled so professionally but, that is, well done team. >> >> Regards, >> LORD HIS EXCELLENCY JAMES HRMH >> >> >> ------------------------------------------------------------------------ >> *From:* bitcoin-dev-bounces@lists.linuxfoundation.org >> >> >> on behalf of >> Luke Dashjr via bitcoin-dev >> >> *Sent:* Saturday, 9 November 2019 2:07 AM >> *To:* bitcoin-dev@lists.linuxfoundation.org >> >> >> >> *Cc:* security@bitcoincore.org >> >> *Subject:* [bitcoin-dev] CVE-2017-18350 disclosure >>   >> CVE-2017-18350 is a buffer overflow vulnerability which allows a >> malicious >> SOCKS proxy server to overwrite the program stack on systems with a >> signed >> `char` type (including common 32-bit and 64-bit x86 PCs). >> >> The vulnerability was introduced in >> 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5 >> (SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012 >> Aug 27. >> A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372 >> ("Improve and >> document SOCKS code") released in v0.15.1, 2017 Nov 6. >> >> To be vulnerable, the node must be configured to use such a malicious >> proxy in >> the first place. Note that using *any* proxy over an insecure network >> (such >> as the Internet) is potentially a vulnerability since the connection >> could be >> intercepted for such a purpose. >> >> Upon a connection request from the node, the malicious proxy would >> respond >> with an acknowledgement of a different target domain name than the one >> requested. Normally this acknowledgement is entirely ignored, but if the >> length uses the high bit (ie, a length 128-255 inclusive), it will be >> interpreted by vulnerable versions as a negative number instead. When >> the >> negative number is passed to the recv() system call to read the >> domain name, >> it is converted back to an unsigned/positive number, but at a much >> wider size >> (typically 32-bit), resulting in an effectively infinite read into >> and beyond >> the 256-byte dummy stack buffer. >> >> To fix this vulnerability, the dummy buffer was changed to an explicitly >> unsigned data type, avoiding the conversion to/from a negative number. >> >> Credit goes to practicalswift (https://twitter.com/practicalswift) for >> discovering and providing the initial fix for the vulnerability, and >> Wladimir >> J. van der Laan for a disguised version of the fix as well as general >> cleanup >> to the at-risk code. >> >> Timeline: >> - 2012-04-01: Vulnerability introduced in PR #1141. >> - 2012-05-08: Vulnerability merged to master git repository. >> - 2012-08-27: Vulnerability published in v0.7.0rc1. >> - 2012-09-17: Vulnerability released in v0.7.0. >> ... >> - 2017-09-21: practicalswift discloses vulnerability to security team. >> - 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability. >> - 2017-09-27: Fix merged to master git repository. >> - 2017-10-18: Fix merged to 0.15 git repository. >> - 2017-11-04: Fix published in v0.15.1rc1. >> - 2017-11-09: Fix released in v0.15.1. >> ... >> - 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML. >> - 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------B642A22E6FC0E7B4B63D06DA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

???


Well, you obviously don't know what you are talking about and did not even consider reading correctly what I wrote, neither to read node-Tor


What you are saying here is quite trivial, typical of people thinking that the Tor network will solve everything and is not centralized (but you seem unsure about it), that's not the case, it's completely wrong and the "normal" use of the Tor network is for browsing only, basically the Tor network is still the same since years: 1000 guards, 1000 relays, 1000 exits (so not "hundreds", happier, and there are of course intersections between them, knowing that they are the supposed working nodes as tested by node-Tor), quite small at the end with finally many misbehaving nodes among the 3000 set, not at all able or willing to handle bitcoin nodes load


Using bitcoin with the Tor network is absurd, using socks proxy with bitcoin is absurd too (I don't get the comparison with a http proxy, nothing to do),  except if limited to a local use, ie you socks proxy inside your device, for example to pipe to node-Tor, but this remains as a whole dangerous if the local proxy has been hacked, as we could see recently with malware Tor sw being used by people


Using the Tor protocol for bitcoin is not absurd at all (do you understand the difference?) + browsers, webRTC, etc I will not repeat what I wrote


Please do some readings or consider at least what I sent, or ask questions if what I am saying is unclear for you


But from my standpoint the discussion on this list is not about explaining all of this that is probably well known by everybody but what can/could be next to anonymize/help anonymizing bitcoin

 when required and make it a real p2p network


Unfortunately I am afraid that we get moderated here because that's not the place to give basic lessons about Tor that you don't know


Le 09/11/2019 à 12:42, LORD HIS EXCELLENCY JAMES HRMH a écrit :
Socks proxies have their use in controlled gateway infrastructure and is a relevant feature for any software required to operate behind a secure network boundary and allows for UDP connectivity (whether it is utilised in any particular application) which a HTTP proxy does not.

You are obviously not well abreast of the Tor project, regardless of whether it seems centralised, whether it is or it isn't, the Tor project is to allow anonymity and connection privacy. For this it works very well and there seem to be hundreds of known Tor nodes, to be known they are not isolated and are connected.

Even if an exit node performs all logging it is only aware of the node one hop up but the originator is higher still. In the case where we perform a Tor cluster and make hundreds of guard, middle and exit nodes we still cannot with absolute certainty say that the connecting node is the originator and, the eventual Bitcoin node is still unaware of the originator IP which is the primary objective. Otherwise, can you hide your IP from your ISP would be a better goal?

You may prefer to familiarise yourself first with the history of Tor, even a brief from [WikipediaTor_(anonymity_network)](https://en.wikipedia.org/wiki/Tor_(anonymity_network)) and consider some of the possible uses, and consider how its implementation benefits the privacy and anonymity of Bitcoin in public where it is allowed in many countries; Tor is just as useful in countries where Bitcoin is allowed to hide from third-parties. You may also enjoy an example of activating Bitcoin Cores Tor implementation: [How can I setup Bitcoin to be anonymous with Tor?](https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor/70070#70070)



There should be no rational consideration that gives rise to reducing Tor connectivity, possibly v3 integration will be coming along.

Regards,
LORD HIS EXCELLENCY JAMES HRMH


From: Aymeric Vitte <vitteaymeric@gmail.com>
Sent: Saturday, 9 November 2019 6:40 AM
To: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>; Luke Dashjr <luke@dashjr.org>
Cc: security@bitcoincore.org <security@bitcoincore.org>
Subject: Re: [bitcoin-dev] CVE-2017-18350 disclosure
 

Sure, but what is questionable here is the use of SOCKS proxy, for Tor I think as the main purpose, making it dangerous for the "whole bitcoin world" while it's something like of zero interest/use (or please let me know what it is beside Tor)

The Tor network is very centralized and not designed at all to handle p2p networks (which bitcoin is still not), it is designed to be used via the Tor Browser to browse the web and to hide web servers, not bitcoin nodes, and there are a lot of misbehaving/dangerous nodes there, there is no encryption in bitcoin protocol, an exit node can fake whatever it likes, this seems to be a use case as far as I can see, but even if the initiator is configured to connect to a hidden bitcoin node, I don't see the point

I have advertised recentlty the open sourcing of node-Tor (https://github.com/Ayms/node-Tor) here

This one is designed for p2p, not over the Tor network but using the Tor protocol, as simple as bitcoin.pipe(node-Tor), or <any protocol>.pipe(node-Tor), which is the finality of the project as far as I see it since years (maybe see http://www.peersm.com/Convergence.pdf even if I would modify some parts now)

Inside servers or browsers acting as servers also (WebRTC or WebSockets), bitcoin peers (servers/browsers) relaying the bitcoin anonymized protocol using the Tor protocol (and not the Tor network) between each others, there is no story of exit nodes here and rdv points would not apply for bitcoin use, this "just" adds the internal missing encryption and anonymity layer to the bitcoin protocol

Personally I would remove the socks proxy interface from bitcoin core, independently of Tor this can be misused too and offers absolutely zero security


Le 08/11/2019 à 18:03, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev a écrit :
It goes without saying in that all privately known CVE should be handled so professionally but, that is, well done team.

Regards,
LORD HIS EXCELLENCY JAMES HRMH


CVE-2017-18350 is a buffer overflow vulnerability which allows a malicious
SOCKS proxy server to overwrite the program stack on systems with a signed
`char` type (including common 32-bit and 64-bit x86 PCs).

The vulnerability was introduced in 60a87bce873ce1f76a80b7b8546e83a0cd4e07a5
(SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012 Aug 27.
A fix was hidden in d90a00eabed0f3f1acea4834ad489484d0012372 ("Improve and
document SOCKS code") released in v0.15.1, 2017 Nov 6.

To be vulnerable, the node must be configured to use such a malicious proxy in
the first place. Note that using *any* proxy over an insecure network (such
as the Internet) is potentially a vulnerability since the connection could be
intercepted for such a purpose.

Upon a connection request from the node, the malicious proxy would respond
with an acknowledgement of a different target domain name than the one
requested. Normally this acknowledgement is entirely ignored, but if the
length uses the high bit (ie, a length 128-255 inclusive), it will be
interpreted by vulnerable versions as a negative number instead. When the
negative number is passed to the recv() system call to read the domain name,
it is converted back to an unsigned/positive number, but at a much wider size
(typically 32-bit), resulting in an effectively infinite read into and beyond
the 256-byte dummy stack buffer.

To fix this vulnerability, the dummy buffer was changed to an explicitly
unsigned data type, avoiding the conversion to/from a negative number.

Credit goes to practicalswift (https://twitter.com/practicalswift) for
discovering and providing the initial fix for the vulnerability, and Wladimir
J. van der Laan for a disguised version of the fix as well as general cleanup
to the at-risk code.

Timeline:
- 2012-04-01: Vulnerability introduced in PR #1141.
- 2012-05-08: Vulnerability merged to master git repository.
- 2012-08-27: Vulnerability published in v0.7.0rc1.
- 2012-09-17: Vulnerability released in v0.7.0.
...
- 2017-09-21: practicalswift discloses vulnerability to security team.
- 2017-09-23: Wladimir opens PR #11397 to quietly fix vulernability.
- 2017-09-27: Fix merged to master git repository.
- 2017-10-18: Fix merged to 0.15 git repository.
- 2017-11-04: Fix published in v0.15.1rc1.
- 2017-11-09: Fix released in v0.15.1.
...
- 2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
- 2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------B642A22E6FC0E7B4B63D06DA--