📅 Original date posted:2017-09-29
📝 Original message:Everybody knows that https is broken and insecure, and everybody knows
that it's still better than nothing
Just reacting here because there is worse: you are quoting Kraken, did
not check for Coinbase but Kraken is proxying all of its https traffic
via Cloudflare, including the API traffic
This is crazy but that's how things are, that's what everybody is doing,
that's what we have
The https principles are obsolete, the concept of certificates tied to a
domain is a complete stupidity, because there are no concept of domains
in bitcoin for example (and webrtc, Tor, bittorrent, p2p systems, etc)
and should evolve to something like certificates tied to an entityID
managed by something like a blockchain system, and not a stupid domain or CA
Therefore specifying things for bitcoin à la web is not a good idea,
browsers can do far better than standard/usual web, and the "like
everybody is doing" argument is not a valid one
Le 29/09/2017 à 15:14, Tomas via bitcoin-dev a écrit :
> On Fri, Sep 29, 2017, at 04:55, Peter Todd via bitcoin-dev wrote:
>> The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment
>> qr
>> codes don't cryptographically commit to the identity of the merchant,
>> which
>> means a MITM attacker can redirect the payment if they can obtain a SSL
>> cert
>> that the wallet accepts.
> By that reasoning, we also shouldn't go to https://coinbase.com or
> https://kraken.com to buy any bitcoins? As a MITM can redirect the site
> _if_ they obtain the coinbase or kraken certificate.
>
> Obviously, HTTPS is secured under the assumption that certificates are
> secure.
>
> Using the payment protocol simply means paying to a secure endpoint (eg
> https://tomasvdw.nl/pay) instead of an address.
>
>> That wallet is also likely using an off-the-shelf SSL library,
>> with
>> nothing other than an infrequently updated set of root certificates to
>> use to
>> verify the certificate; your browser has access to a whole host of better
>> technologies, such as HSTS pinning, certificate transparency, and
>> frequently
>> updated root certificate lists with proper revocation (see Symantec).
> So we should not use HTTPS for secure transfer because the
> implementation may not be good enough? This incorrectly conflates
> implementation with specification. There is nothing stopping a developer
> from using a proper implementation.
>
>> As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at
>> least
>> supports a h= parameter with a hash commitment to what the payment
>> request
>> should be, and will reject the MITM attacker if that hash doesn't match.
>> But
>> that's not actually in the standard itself, and as far as I can tell has
>> never
>> been made into a BIP.
> Currently it is widely used by merchants, but not yet for light clients
> _receiving_ money. If it becomes more wide spread, it offers a range
> of advantages as the bitcoin-address of the URI can and should be
> deprecated (made impossible with "h="). A payment address just becomes a
> secure endpoint.
>
> This means no more address reuse is possible. Also, it drops the need
> for mempool synchronization among non-miners, solely as a "notification"
> mechanism. In addition it means light clients know exactly when a
> transaction is coming in, so they can efficiently rely on client-side
> filtering a small set of blocks, improving their privacy.
>
> In my opinion, the payment protocol is key to scaling.
>
>> As-is BIP-72 is very dangerous and should be depreciated, with a new BIP
>> made
>> to replace it.
> Sorry, but maybe you could explain better how secure communication over
> HTTPS is "very dangerous"? I think some websites would like to know :)
>
> Tomas van der Wansem
> bitcrust
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Aymeric Vitte [ARCHIVE] /
npub15f…g5grz
2023-06-07 18:06:29
in reply to nevent1q…34vl
Author Public Key
npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grzSeen on
wss://relay.noswhere.comPublished at
2023-06-07 18:06:29Event JSON
{
"id": "419898147aa5d0b8f8c9d7f49237dd13ba8ca2d339b43501cb946a8cea0cafaa",
"pubkey": "a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df",
"created_at": 1686161189,
"kind": 1,
"tags": [
[
"e",
"9ba68f900d90904e29f5efd02284effec6533d5cd78431d2ab1c777688de104c",
"",
"root"
],
[
"e",
"b39290d7739717b78e624dc570a1dfc492ad6dd9d5292708b10737561a07a494",
"",
"reply"
],
[
"p",
"1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd"
]
],
"content": "📅 Original date posted:2017-09-29\n📝 Original message:Everybody knows that https is broken and insecure, and everybody knows\nthat it's still better than nothing\n\nJust reacting here because there is worse: you are quoting Kraken, did\nnot check for Coinbase but Kraken is proxying all of its https traffic\nvia Cloudflare, including the API traffic\n\nThis is crazy but that's how things are, that's what everybody is doing,\nthat's what we have\n\nThe https principles are obsolete, the concept of certificates tied to a\ndomain is a complete stupidity, because there are no concept of domains\nin bitcoin for example (and webrtc, Tor, bittorrent, p2p systems, etc)\nand should evolve to something like certificates tied to an entityID\nmanaged by something like a blockchain system, and not a stupid domain or CA\n\nTherefore specifying things for bitcoin à la web is not a good idea,\nbrowsers can do far better than standard/usual web, and the \"like\neverybody is doing\" argument is not a valid one\n\n\nLe 29/09/2017 à 15:14, Tomas via bitcoin-dev a écrit :\n\u003e On Fri, Sep 29, 2017, at 04:55, Peter Todd via bitcoin-dev wrote:\n\u003e\u003e The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment\n\u003e\u003e qr\n\u003e\u003e codes don't cryptographically commit to the identity of the merchant,\n\u003e\u003e which\n\u003e\u003e means a MITM attacker can redirect the payment if they can obtain a SSL\n\u003e\u003e cert\n\u003e\u003e that the wallet accepts.\n\u003e By that reasoning, we also shouldn't go to https://coinbase.com or\n\u003e https://kraken.com to buy any bitcoins? As a MITM can redirect the site\n\u003e _if_ they obtain the coinbase or kraken certificate.\n\u003e\n\u003e Obviously, HTTPS is secured under the assumption that certificates are\n\u003e secure. \n\u003e\n\u003e Using the payment protocol simply means paying to a secure endpoint (eg\n\u003e https://tomasvdw.nl/pay) instead of an address.\n\u003e\n\u003e\u003e That wallet is also likely using an off-the-shelf SSL library,\n\u003e\u003e with\n\u003e\u003e nothing other than an infrequently updated set of root certificates to\n\u003e\u003e use to\n\u003e\u003e verify the certificate; your browser has access to a whole host of better\n\u003e\u003e technologies, such as HSTS pinning, certificate transparency, and\n\u003e\u003e frequently\n\u003e\u003e updated root certificate lists with proper revocation (see Symantec).\n\u003e So we should not use HTTPS for secure transfer because the\n\u003e implementation may not be good enough? This incorrectly conflates\n\u003e implementation with specification. There is nothing stopping a developer\n\u003e from using a proper implementation.\n\u003e\n\u003e\u003e As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at\n\u003e\u003e least\n\u003e\u003e supports a h= parameter with a hash commitment to what the payment\n\u003e\u003e request\n\u003e\u003e should be, and will reject the MITM attacker if that hash doesn't match.\n\u003e\u003e But\n\u003e\u003e that's not actually in the standard itself, and as far as I can tell has\n\u003e\u003e never\n\u003e\u003e been made into a BIP.\n\u003e Currently it is widely used by merchants, but not yet for light clients\n\u003e _receiving_ money. If it becomes more wide spread, it offers a range\n\u003e of advantages as the bitcoin-address of the URI can and should be\n\u003e deprecated (made impossible with \"h=\"). A payment address just becomes a\n\u003e secure endpoint.\n\u003e\n\u003e This means no more address reuse is possible. Also, it drops the need\n\u003e for mempool synchronization among non-miners, solely as a \"notification\"\n\u003e mechanism. In addition it means light clients know exactly when a\n\u003e transaction is coming in, so they can efficiently rely on client-side\n\u003e filtering a small set of blocks, improving their privacy.\n\u003e\n\u003e In my opinion, the payment protocol is key to scaling.\n\u003e\n\u003e\u003e As-is BIP-72 is very dangerous and should be depreciated, with a new BIP\n\u003e\u003e made\n\u003e\u003e to replace it.\n\u003e Sorry, but maybe you could explain better how secure communication over\n\u003e HTTPS is \"very dangerous\"? I think some websites would like to know :)\n\u003e\n\u003e Tomas van der Wansem\n\u003e bitcrust\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \nZcash wallets made simple: https://github.com/Ayms/zcash-wallets\nBitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets\nGet the torrent dynamic blocklist: http://peersm.com/getblocklist\nCheck the 10 M passwords list: http://peersm.com/findmyass\nAnti-spies and private torrents, dynamic blocklist: http://torrent-live.org\nPeersm : http://www.peersm.com\ntorrent-live: https://github.com/Ayms/torrent-live\nnode-Tor : https://www.github.com/Ayms/node-Tor\nGitHub : https://www.github.com/Ayms",
"sig": "d5a0fa2c742dfd971335363737dbd50a626cb6b70866b678cf062ca735aeb96818894fa26c3d88405b26d4932385232de3907f4f5764d8c7e7857aefb8cba442"
}