Topic: tlsnotary - cryptographic proof of fiat transfer for p2p exchanges - page 5. (Read 42867 times)

@PeFro
Just wanted to send you a big THANK YOU for volunteering to test.

@Mike Hearn
Thank you for the words of encouragement. The mere fact of your participation in this thread helps inspire confidence in beta-testers IMO.

There are only 2 files which need to be looked at:
buyer-oracle.py (1000 lines) which I tried to comment as amply as I could
and oracle/oracle.py (700 lines) which stands by for a command from the user and only performs 3 things :
setup tunnel using stcppipe,
send encrypted trace to escrow,
send a copy of oracle's internal database.

Yeah thanks, makes sense. I guess in the end there will always be some kind of trust required, even for technical people, unless they are willing and able to inspect the whole source code but in essence that´s equally applicable to using bitcoin itself. Making explicit what kind of information at which step is stored where and visible to whom and at which point in time is going to be crucial though.

Indeed it looks like you entered a minus sign; the garbled part is an encoded form of the minus character.
Did you copy/paste the minus sign or enter it manually? I guess the latter and that's why it's failed.
However you're definitely right that we have to be careful how we deal with the user input, and we're looking into it. Your input is much appreciated.

Paysty is only verifying that what you enter into the 'accno' and 'sum' boxes actually appears somewhere in the html of the page. So of course you're right you could enter anything that appears somewhere on the page, not necessarily the true account number for example. This is just a first stage verification - the real point is as follows: if there's a dispute between buyer and seller, the escrow can (if you choose to give it) take the ssl key(s) specifically associated with that html page, and decrypt that one page and read it.
The protection of your privacy is based on doing a kind of "reset" of the ssl connection and then reloading the page. This means the escrow will never be able to see anything except that one page.
Does it make sense? Obviously a more detailed explanation will be given in the future.

I just tested it for 2 banks.

For netbank.de it works just fine.
For sparkasse.de it doesn´t...

this is the last part of the log:


the amount I entered was 29,44, so.. not sure why it´s garbled in the log while the account no is fine

Edit: Ok, my fault (kinda)... I didn´t enter 29,44 but -29,44, as that was the way it was stated. Imho this should be processed either way.
So, entering 29,44 works for sparkasse.de, too.

Now maybe a stupid question... what exactly does this prove?
Is it a problem that, e.g. I can send a transaction to one of my own bank accounts and put the actual target account number (whom I´m supposed to pay) just in the comments field of the transaction? Paysty does find the actual target account number in the html but does it recognize that this is not the account number money is send to?

Good points Mike.
In terms of people verifying the code's security, I'd suggest anyone who's interested take a look at the management of ssl keys and what data is transferred.
Since you can see that in the current prototype version, ssl keys are stored locally and not transferred, to my mind that's a 100% guarantee of safety. (not a 100% guarantee of successful operation of course, that's an entirely different matter!)

Of course we are talking about only a prototype here for initial data gathering. The fuller version will include multisig transactions and a messaging feature, and there will be contexts in which ssl keys are transferred (only those for specific html though).

Sorry Dan. I don't think the issue is lack of interest in the outcome. I did take a look at doing some testing for myself, but:

1) I've been out of time lately (that is, the time I have for Bitcoin is soaked up by other things)
2) I would be about to route an online banking session via a third party proxy, using a large pile of code not written by me

(2) implies before I'd be willing to take part in this, I'd want to verify everything for myself. The fact that this is possible is why your approach is powerful. However, that doesn't mean it's something I can squeeze into my lunch break.

What you might want to do is start a new thread, perhaps in this section or perhaps in the dev/tech section, outlining what is required. It will take a while until someone is able to fully verify that your setup does what you say it does. Once that is complete, it'll be easier to recruit beta testers. All I can suggest for now is raising the visibility of your important work, combined with patience ...

Just wanted to give this thread a little bump and add some lamentation.
It's been a week and NO-ONE has contacted me to with the intention to become a beta-tester.

It's a bit sad that we are working here to bring to the community a decentralized open-source FIAT to BTC exchange and yet we have to spend our precious time recruiting beta-testers and even offering the money instead of pressing on with the development.

Nonetheless, we managed to successfully test Paysty with our and our friends' bank accounts. 5 banks in total.
Please feel free to PM me if you want to contribute to this project by becoming a beta-tester.

I would like to invite those who follow this thread to take part in alpha testing.
Code-named "Paysty", is a set of tools which allow you to connect to your bank via an Amazon EC2 oracle and then select a statement page which you would like a third party to see.
With this alpha version of Paysty you don't give anything to any third party - the oracle sends your encrypted banking data back to you.  Paysty then acts as if it was the escrow and analyzes the encrypted data and lets you know whether it can find your HTML page in it.

Those who wish to participate, please PM me and I will give a key which serves as a passwords to get access to oracle. Otherwise you won't be able to use Paysty.

https://github.com/themighty1/ssllog/tree/alphatest
You can choose "Download ZIP" if you don't want to use git

Make sure that Firefox is installed on your system.

Windows users don't need any extra software - Paysty is bundled with Python, plink(console putty), stcppipe and wireshark tools.
Just run startPaysty.bat

Linux users will have to install Python (v2 variety), ssh, tshark, gcc.
On Ubuntu we just run Then just run "python buyer-oracle.py"

OSX: nothing yet, sorry.
------------------------------------

Copy the private key which will you receive from me into the file alphatest.txt in the root of the Paysty's installation.


Usage:

On the bottom panel of Paysty there are two input fields: Account number and Sum.
After you navigate to a specific transaction in your banking statement history, enter the Account number and sum exactly as they appear on the page.
After that Paysty will tell you whether your bank is compatible.


Once again let me re-emphasize all security related points:
1. The oracle is open source and serves as a proxy when you connect to your bank.
2. Even though the oracle is launched from my Amazon account, it is set up in such a way that I have no access to it. I can only terminate it at most. I can't see which IP address is connecting to which site via the oracle.
3. In this Alpha version, you don't share any page of your banking session with anyone, all your data is sent back to you for examination.

Whether successful, or otherwise, please let me know your testing results (PM or here), viz. your operating system, your bank's name/site.

If anyone would like to help me test the multisig (escrow of bitcoins) part of the application, please PM me.
Details:
you don't need to spend any bitcoins we'll just escrow and then redeem 1mbtc from me.
git clone or download the zip from: https://github.com/AdamISZ/multisig_lspnr
If you have python 2.7, you can run it immediately to see the instructions: python multisig.py (no arguments)
(or just read the readme on github).
This test needs two people at least acting at once, so I'm available from around 12GMT to around 9PM GMT tomorrow and most days.

Thanks if you can help, and please be ready for an announcement from dansmith coming v. soon as far as I know

Edit: just in case it needs to be said, do not attempt to use this application independently yet; it needs more testing.

murraypaul's arguments all boil down to reputation-based security, but he then surrounds them in lots of other gumpf.

Reputation-based security is last decade.

This is exactly the same setup, using a proxy in dispute (and for normal transactions you will not even do that, just your normal internet banking).

We really aren't; but it's OK, until we actually release a full alpha test with source that people can look at, you have no basis to know either way, so it's right to be cautious. I guess all I'm saying is please don't assume we haven't thought about it

It really is the same, but no need to argue further about that without code for you to look at. Either way, your point that the bank would never explicitly accept this system, is I'm sure true. They will never accept anything the customer proposes, generally..

I agree that they will choose to interpret TOS as they wish, unless you have expensive lawyers perhaps. What you might not appreciate though is that this process is completely invisible to them. From the bank's POV you have simply connected via the proxy's IP address. Banks do not restrict which IP you can connect from (assuming it's not in like Iran or something) since that would break one of the main advantages of internet banking, namely mobility.
Of course if ALL our connections came from one IP, that would be different And don't forget that this proxying (as of now) only occurs in dispute, also.

Well no, it isn't exactly the same risk, is it?
A standard secured connection is a very well known and understood setup, which large companies do all the time.
You are talking about a brand new, untested, bespoke, security setup.
The risk of security failure in the latter is much higher than the former.


If your security setup was perfect, then in practice it might be as secure in practice.
It isn't exactly the same from the bank's point of view, because showing someone the statement doesn't involve any possiblity of compromising the security of your account, because it is a static bit of data. Accessing your account through someone else's system, where the bank cannot be confident that that system is secured, is not the same thing.
Showing them your bank statement would be the equivalent of emailing someone a screenshot of your online banking.


It would depend on the working of your particular bank's TOS.
I wouldn't be confident that there isn't some clause they could find that would cover this situation.

As to a): it's exactly the same risk as passing your traffic through an ISP, a proxy, a VPS or basically normal internet traffic. Namely: passive observers can record your encrypted data. MITM is as big (or small) a risk here as it is with a normal internet connection: do you trust the certificate being presented as from bankofamerica?
Issuing to an escrow, in a dispute case, ONE ssl key that will expose ONE html page (a relationship which you can verify on your local host) is EXACTLY the same issue as whether you want to give your bank statement to that person on paper.
(Again, I responded to (b) in the last post of page 7 - or maybe that depends how your config is on this forum, it was 5 posts back).

murraypaul, did you see my post at the end of page 7? (you may have missed it because there were several posts at once). I made some points about TOS there.

It is different, because you are deliberately sharing your online banking session with someone else.
You are potentially opening yourself up to fraud.


Do you think your bank will do that? Or that they will care.
a) Have you shared your session with someone else: Yes
b) Is that against our TOS: Yes
c) Will we refuse to compensate you if you lose money due to fraud: Yes

It doesn't matter here whether technically there is or isn't risk of your credentials being stolen.
Your bank has not agreed that you can extend their security umbrella to some Amazon AWS instance they've never even heard of.

There are two distinct issues:
a) Is this actually a security risk, can you 100% guarantee the security of the setup, and that there can't be a rogue operator or man in the middle?
b) Is it against your banks TOS anyway?

The answer to b) doesn't depend on the answer to a).

a) Is it against your bank's TOS to print out a webpage showing a proof-of-payment and handing it over to another party? If not, then why should this be different? You are not sharing your login-credentials.
b) Is it stupid to print out a proof-of-payment from your bank and use it as a proof-of-payment?

Maybe you don't understand that you can audit the software running on Amazon AWS?

I have to repeat again, as emphatically as possible: you will NOT share your internet banking credentials with this system. 100% not your password. ONLY one html page containing your statement or, even better, the acknowledgement page showing the record of a wire transfer sent.

My first response to the concept was also suspicion. However this is not what it seems at first sight.
First consideration: it is common practice for people to give copies of their bank statements to various agencies as proof of income (this is even required in some cases to get visas). This is not really different in terms of privacy, the difference is that what we're doing represents actual proof, something that cannot be forged.

Secondly, make sure you understand exactly what is being exposed. The proxy only holds encrypted records, exactly as, say, your ISP does when they forward your internet traffic to your bank. When a buyer CHOOSES to expose ONE html page, by sharing ONE specific ssl session key, they are not exposing anything else to any other party, trusted or otherwise.

Lastly, as to it being against TOS. I investigated this a bit. I found clauses in some internet banking service conditions that suggested this is not allowed, while in others there was no suggestion that sharing the data is not allowed. The former are unrealistic and frankly nonsense, since as I already pointed it out any person sharing their bank statement in any way would be violating such a TOS agreement.

I've never said that sharing your credentials is against the law.
I have said that:
a) It is against your bank's TOS, and
b) It is stupid

And there is a difference between using software and, unknown to you, there being an exploit which leaks your information, and you voluntarily sharing your information.

I just say, that it cannot be against the law. If you connect to your banking website, then your connection is routed via many different software components. And in the end the Amazon AWS instance will also just be another software which is routing your traffic to the bank. So how should they prohibit this?
I would not even share my login-credentials with any other person, because it is just a software.

Do you think it is against the law to enter your bank-account password into Internet Explorer, because this will effectively share your login information with Microsoft? Because there you even cannot be sure, because it is closed source. With the Amazon AWS instance it would be open source and therefore you can be sure that you don't share your password.

So why do you think, it is more stupid to trust some open-source software running on Amazon AWS in comparison to trusting some closed-source software like Internet-Explorer or any other router software which is between you and your bank?