public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andreas Schildbach <andreas@schildbach.de>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks
Date: Sat, 30 Sep 2017 17:33:01 +0200	[thread overview]
Message-ID: <oqodf6$30b$1@blaine.gmane.org> (raw)
In-Reply-To: <20170929025538.GC12303@savin.petertodd.org>

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
> 




  parent reply	other threads:[~2017-09-30 15:33 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27 16:06 [bitcoin-dev] Address expiration times should be added to BIP-173 Peter Todd
2017-09-27 18:15 ` CryptAxe
2017-09-27 19:03 ` Mark Friedenbach
2017-09-27 21:20   ` Peter Todd
2017-09-27 19:35 ` Chris Priest
2017-09-27 20:11   ` CryptAxe
2017-09-27 20:23   ` Nick Pudar
2017-09-27 20:19     ` CryptAxe
2017-09-27 21:09     ` Mark Friedenbach
2017-09-27 21:15   ` Peter Todd
2017-09-28  0:22   ` Gregory Maxwell
2017-09-27 21:33 ` Peter Todd
2017-09-28  0:58 ` Gregory Maxwell
2017-09-29  1:50   ` Peter Todd
2017-09-29  2:06     ` Gregory Maxwell
2017-09-28 10:09 ` Andreas Schildbach
2017-09-28 12:43   ` Sjors Provoost
2017-09-28 14:13     ` Andreas Schildbach
2017-09-28 14:41       ` Sjors Provoost
2017-09-28 15:06         ` Andreas Schildbach
2017-09-28 15:45           ` Sjors Provoost
2017-09-28 16:59       ` Luke Dashjr
2017-09-29  2:18     ` Peter Todd
2017-09-29  7:18       ` Sjors Provoost
2017-09-29  2:55     ` [bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks Peter Todd
2017-09-29  4:21       ` Omar Shibli
2017-09-29 13:14       ` Tomas
2017-09-29 17:40         ` Aymeric Vitte
2017-09-30 15:33       ` Andreas Schildbach [this message]
2017-09-29  1:45   ` [bitcoin-dev] Address expiration times should be added to BIP-173 Peter Todd
2017-09-29  8:44     ` Andreas Schildbach
2017-09-29  9:55       ` Peter Todd
2017-09-29 12:45         ` Andreas Schildbach
2017-09-29 13:52           ` Peter Todd
2017-09-29 17:25           ` Gregory Maxwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='oqodf6$30b$1@blaine.gmane.org' \
    --to=andreas@schildbach.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox