Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks
Generally agreed. This is why I nack'ed BIP72 years ago when we discussed about standardization. However, there are many ways to use BIP70 without BIP72. BIP72 is just a kludge to biggy-pack the payment protocol onto BIP21. And also, as you note, BIP72 can be easily fixed using a hash parameter. On 09/29/2017 04:55 AM, Peter Todd via bitcoin-dev wrote: > On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev > wrote: >> Andreas Schildbach wrote: >>> This feels redundant to me; the payment protocol already has an >>> expiration time. >> >> The BIP-70 payment protocol has significant overhead and most importantly >> requires back and forth. Emailing a bitcoin address or printing it on an >> invoice is much easier, so I would expect people to keep doing that. > > 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. > > For example, if I have a wallet on my phone and go to pay a > merchant, a BIP-72 URI will look like the following(1): > > > bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe > > A wallet following the BIP-72 standard will "ignore the bitcoin > address/amount/label/message in the URI and instead fetch a PaymentRequest > message and then follow the payment protocol, as described in BIP 70." > > So my phone will make a second connection - likely on a second network with a > totally different set of MITM attackers - to https://merchant.com > > In short, while my browser may have gotten the correct URL with the correct > Bitcoin address, by using the payment protocol my wallet is discarding that > information and giving MITM attackers a second chance at redirecting my > payment > to them. 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). > > 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. > > As-is BIP-72 is very dangerous and should be depreciated, with a new BIP made > to replace it. > > 1) As an aside, it's absolutely hilarious that this URL taken straight from >BIP-72 has the merchant using PHP, given its truly terrible track record > for >security. > > > > ___ > 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
Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks
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@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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks
Thank you for sharing, this is indefinitely valuable. I think that risk could be mitigated if instead of ignoring the bitcoin address/amount/..., the wallet use this address for integrity checks. Furthermore, I think this BIP could be improved by actually applying the homomorphic property and deriving the bitcoin address from merchant pub key and the hash itself. that would allow both the customer and merchant to be able generate address independently. On Fri, Sep 29, 2017 at 5:55 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev > wrote: > > Andreas Schildbach wrote: > > > This feels redundant to me; the payment protocol already has an > > > expiration time. > > > > The BIP-70 payment protocol has significant overhead and most > importantly requires back and forth. Emailing a bitcoin address or printing > it on an invoice is much easier, so I would expect people to keep doing > that. > > 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. > > For example, if I have a wallet on my phone and go to pay a > merchant, a BIP-72 URI will look like the following(1): > > bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https:// > merchant.com/pay.php?h%3D2a8628fc2fbe > > A wallet following the BIP-72 standard will "ignore the bitcoin > address/amount/label/message in the URI and instead fetch a PaymentRequest > message and then follow the payment protocol, as described in BIP 70." > > So my phone will make a second connection - likely on a second network > with a > totally different set of MITM attackers - to https://merchant.com > > In short, while my browser may have gotten the correct URL with the correct > Bitcoin address, by using the payment protocol my wallet is discarding that > information and giving MITM attackers a second chance at redirecting my > payment > to them. 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). > > 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. > > As-is BIP-72 is very dangerous and should be depreciated, with a new BIP > made > to replace it. > > 1) As an aside, it's absolutely hilarious that this URL taken straight from >BIP-72 has the merchant using PHP, given its truly terrible track > record for >security. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > > ___ > 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
[bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks
On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wrote: > Andreas Schildbach wrote: > > This feels redundant to me; the payment protocol already has an > > expiration time. > > The BIP-70 payment protocol has significant overhead and most importantly > requires back and forth. Emailing a bitcoin address or printing it on an > invoice is much easier, so I would expect people to keep doing that. 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. For example, if I have a wallet on my phone and go to pay a merchant, a BIP-72 URI will look like the following(1): bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe A wallet following the BIP-72 standard will "ignore the bitcoin address/amount/label/message in the URI and instead fetch a PaymentRequest message and then follow the payment protocol, as described in BIP 70." So my phone will make a second connection - likely on a second network with a totally different set of MITM attackers - to https://merchant.com In short, while my browser may have gotten the correct URL with the correct Bitcoin address, by using the payment protocol my wallet is discarding that information and giving MITM attackers a second chance at redirecting my payment to them. 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). 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. As-is BIP-72 is very dangerous and should be depreciated, with a new BIP made to replace it. 1) As an aside, it's absolutely hilarious that this URL taken straight from BIP-72 has the merchant using PHP, given its truly terrible track record for security. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
