Allow to override issues with payment-requests (failed download/expired or wrong certificate) #268
Comments
|
Did you try scanning it various times with Mycelium, too? The code contains:
Mycelium does understand the r= parameter and according to the BIP ignores the address part. If the BIP72 payment request fails though, the BIP sais:
It would be helpful to know what exactly was served. |
|
I did try the same checkout procedure about three or four times, and got the same error each time. Finally I used Coinomi and it worked. Some time later, after I filed this issue, I scanned the QR code with a bar code reader, and went to the r= URL with Google Chrome, and got the error message "Invalid Accept header". I just got the same response again. Assuming that Coinbase.com was presenting invalid instructions at the r= URL, we still have the issue that Mycelium didn't work but Coinomi did. So from the user's point of view something must be wrong with Mycelium. There should be some work-around. For example there could be a manual override letting the user ignore the URL and use the provided payment address. |
|
I did a little detective work as follows. Did the same checkout, and got the same error messages from Mycelium. Scanned the QR code with a bar code app, and extracted the r= URL. Visited that URL with wget. The command-line was: This resulted in wget downloading a binary file named '5741140c7d666c01270002b4'. According to 'strings -a', this binary file contains numerous references to SSL certificates, and some payment information. I'm uploading this file in case the Mycelium developers wish to analyze it. I did not enter any private information when performing the previous steps, so there should be no private information in this uploaded file. |
|
I just realized that you might need the headers too. This time I used the command: Headers are below. The downloaded file was identical to the previous one. |
|
Thank you for your detailed report. Last thing I would be interested in is if the other wallet actually did a use the r= portion or if it fell back to using the address and amount from the QR (upon error or immediately.) Anyway, we will have to investigate this further. |
|
The other wallet, which I used to successfully make the payment, was Coinomi. It did not report any error or warning; but immediately gave me a confirmation screen with the recipient's bitcoin address, the payment amount, and a miner's fee, already filled in, ready for me to push Send. Their website (at https://coinomi.com/) does not seem to mention BIP72 anywhere and neither does the github source repository (at https://github.com/Coinomi/coinomi-android). So I would guess that Coinomi used the payment information directly and did not query the r= URL. Edit: Bitpay has a table (at https://bitpay.com/docs/wallets) that says that Coinomi does not provide Payment Protocol Support, by which they mean BIP70, BIP71, BIP72 and BIP73. |
|
so it working with Coinomi doesn't even hint at the url working. We have to dig into the stored response, although it's not sure that response is what the wallet failed with. Thanks for the information anyway. We definitely need to improve the error reporting. Maybe some optional "if you think it was fine, you can send us the issue" button. |
|
I went to the same URL (https://www.humblebundle.com/books/open-road-mystery-novels) and tested the checkout process again. Mycelium again gave me the same error message. But the Copay wallet, which does implement BIP72, interpreted the QR code correctly and offered to let me send a payment as expected. Depending on your degree of motivation, you can do the test yourself. Simply enter any test email address (e.g., testemail@example.com) and click on the Bitcoin button. That will give you the page with the QR code. No login is required, and no transaction will occur unless you actually send a payment. |
|
If i try to parse your uploaded PR (5741140c7d666c01270002b4.zip) i get following result from androids own verification method:
Also the same happens if i fetch a new payment request from coinbase (via humblebundle) Ill contact coinbase and try to find out more, if its a problem in our cert parsing or they simply missed to update their certs. Update: just tried it with Schildbach, same result. Their cert is expired. But that makes one wonder that they did not get any bug reports for the last 10 days.... Update2: https://community.coinbase.com/t/certificate-for-bip77-payment-request-is-expired/11060 |
|
BitcoinCore parses the payment request and allows the user to pay to it. It only marks it with a yellow background instead a green one. And only the tool-tip says "This is an unauthenticated payment request." |
|
I just tried buying Reddit Gold with Bitcoin. It gave me a QR code to scan. I used Mycelium to scan the code and got the same error. Here's the coinbase request for payment:
and here's the result in Mycelium:
The QR code decodes to Can it really be that Coinbase have been using an expired certificate for nearly a month without fixing it? |
|
It almost seems like it. Sad that they haven't even responded to the guy's thread on their forum either. I had to move some coins over to a different wallet that seems to work on android. Coinomi. I dont like it nearly as much as mycelium but I was running out of time on a subscription |
|
I worked around it by scanning the QR code, emailing the URL to myself from the phone to my laptop, removing the Kind of annoying, but I couldn't think of a better way to do it. I didn't want to be manually typing the address or the amount on the phone. |
|
Maybe Mycelium could offer to use the payment request anyway, even if the certificate has expired. Or offer to use the amount and address from the URL and ignore any bad payment requests. |
I just noticed they replied to my tweet at them yesterday: "@dooglus sorry about that :( We're working to fix it asap" -- https://twitter.com/dooglus/status/739734929723031552
|
|
So according to twitter, the certificate is updated. Better safe than sorry. Closing. |
|
Sorry, I forgot to update this issue. The CoinBase cert. does appear to be working now according to my tests. |
|
Didn't close it lightly, as users will hate us for being the only wallet that doesn't let them pay, with even Core being being "less paranoid" but I guess it's the right thing to do. At first the error message was not ok but with that fixed, it's fair to not just default to the next best thing. |
|
It would still be preferable to allow the user to ignore the payment request part completely and just use the address and amount directly from the URL. That's what they're going to do anyway, but it's a pain in the ass to have to copy the address character by character from the computer to the Android device when the information is already in the QR code they scanned. |
|
well, it's not that dramatic if you know how. Just use any qr-code scanner, copy the value, paste it to the browser, edit the url, open the url. It will offer Mycelium.
Yes, being more strict than BitcoinCore in complying with a BIP was annoying in this case but it really was Coinbase's fault. |
|
Isn't the issue that without the certificate a MITM attacker can just change the address in the URL? |
To be fair, a MITM attacker could just remove the Bitcoin Core's approach is not totally wrong but it defeats the purpose of checking the certificate if the user doesn't get clearly warned about things looking fishy. |
|
These things go in cycles. We always begin with aspirations for a secure universe. Then we realize we need compromises, because security is never absolute, website owners are not always clueful, and users are sometimes impatient to get something done even if there is some risk. In the mid nineties, after SSL began to become popular, visiting a website with an invalid (usually expired) SSL certificate was an exercise in frustration. Early web browsers (Netscape Navigator to begin with, then Microsoft's IE, then Opera, then others) refused to let the user easily override a website's broken SSL. Web browser makers eventually realized that an easy manual override was essential to allow normal use of websites administered by sloppy web designers. And they made it quite a bit easier for even naive users to get past the warnings. Today, we are going through a similar cycle with the increasing use of HSTS, which essentially tells the web browser to disallow any manual override no matter how careless the web designer and no matter how frustrated the user. So, as we see increasing use of Let's Encrypt SSL certificates (with a 3-month lifetime), and more and more poorly-administered websites that use both HSTS and an expired Let's Encrypt SSL certificate, there will be more and more frustrated users who can't visit a website even though there's nothing there that is so valuable that anybody would bother to mount a man-in-the-middle attack. The same will happen with $15 payments that cannot be made because the bitcoin wallet is too strict and the website administrator can't be bothered to update the SSL certificate. After an initial period of user frustration, we will all come to some compromise, where the user can press a "proceed anyway, I know the SSL has been broken for a month, what do you expect, it's Coinbase after all" button. |
That's the button I was hoping for. But maybe the period of user frustration hasn't been long enough yet. |
Giszmo
changed the title
|
I've never seen an expired certificate from PayPal, Bank of America, Discover, or any other serious finance business. |
|
OK, so we can maybe conclude that CoinBase isn't a serious finance business. That probably won't come as much of a shock to anyone. The question is what we should be doing in the event that someone sends you a payment request with an expired certificate. I would argue that we should do the same thing a web browser does when an SSL site sends you an invalid certificate: show a big warning explaining what went wrong, and allow the user to continue despite the warning. |
|
Who is liable if the transaction is sent to a wrong address? |
|
Liability could be minimized by making it very hard or impossible to override an invalid SSL certificate above some payment threshold. The threshold could be hard-coded by the Mycelium developers, or it might be user-settable. Aside: Talking about payment thresholds, these should also exist to protect against user error. The Internet is full of complaints from people who accidentally sent too many bitcoins or made the miner's fee too big. In conventional banking, no payment is instantaneous, so there is time to catch errors. Or they can be reversed easily. The bitcoin world should compensate for its quicker and more final payments by including better heuristics to detect errors before they become final. |
|
@fortran77 : The Mycelium Wallet is open source software and provided as is. Implementing a threshold that any specific distributor would be happy to cover in case of malicious certificates would set a dangerous precedent. The other suggestion is covered by #188. Please keep the issues separated. |
|
@fortran "Talking about payment thresholds, these should also exist to protect against user error" << I wouldn't be in favour of limits on how much can be sent. I've made many payments of 500 BTC and more from Mycelium. Crippling it to disallow large payments would make it significantly less useful to me. Maybe a setting would be useful so users could set their own threshold above which a warning would be issued, but having a limit which the user cannot override would make things worse. @Rassah the user is liable for all the transactions he makes. Mycelium should issue a clear warning when a payment request is invalid, and make it clear that the user proceeds at their own risk. |
…mydfs #955 Unpublish Apex and MyDFS on specific dates
I went to the URL https://www.humblebundle.com/books/open-road-mystery-novels with the Google Chrome web browser and opted to pay using bitcoins. I saw a screen (see attached example screenshot) generated by Coinbase.com. When I scanned the QR code with the Mycelium wallet (version 2.7.4 on a Nexus 9 running Android 6.0.1), it gave me error messages: under "Merchant" I saw the error message "invalid certificate", and under "Signature" I saw the error message "invalid signature". There was no choice on the screen other than Cancel.
When I scanned the same QR code with the Coinomi wallet (version 1.6.2), it correctly interpreted it and derived from it the payment amount and the bitcoin address to send it to.
The text was updated successfully, but these errors were encountered: