Pages:

Author

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

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: caveden on May 27, 2013, 07:11:56 AM

Quote from: waxwing on May 27, 2013, 04:06:38 AM

2. The other problem is the technical problem of "recording" only *part* of the SSL session, so as not to expose the most sensitive data. I don't think the user could first login to internet banking, and then switch on a proxy to start rerouting traffic via the escrow's machine (who would then dump all decrypted SSL output). That's what we want, but it sounds somewhere between tricky and impossible. There needs to be a solution to this.
Dan's fallback of changing your password after the audit is a great idea for a last resort (or for the sensibly paranoid), but it can't be the main idea there.

Hum, I thought the recording was being done on localhost, but only now I realized that if the escrow doesn't ~~perform the SSL-handshake himself~~ record everything himself on real-time, he can't really be sure the recorded data wasn't forged. That's correct, right?

Yes. *Someone* (not necessarily the escrow agent themselves, see the last few posts) will have to record the data (in encrypted or decrypted form) in real time, otherwise the user could be faking it.

Quote from: waxwing on May 27, 2013, 05:57:01 AM

On a slight tangent, I personally don't mind if others see my name and account number. As far as I'm concerned, that's semi-public knowledge.
...
so really the worst that happens from giving someone your statement is that they see your bank balance.

Of course, it's not the name+account nb that's sensitive (at least not IMO), it's the balance and transaction history.

Hmm. For me, I don't think that's a deal breaker, if I only have to release it to a certain party, and only in a rare case. But I can certainly understand reluctance on that.
But if most users take that position, that showing balance and transactions at any point is unacceptable, I am finding it more and more difficult to know what we can do. I get your point that the confirmation page *might* be enough; it would usually contain the details of the transaction. But sometimes it just says, effectively "sent", and it's the page before (which might contain other info.) that actually has the amount and the receiving account details (which we of course do need). Perhaps the last two pages would be OK (the page with the "send" button and the "sent" message).

For the "audit only" model, the solution might be to use a confirmation of wire transfer record. I know that when I send wires I get an automated message in the messaging system *inside* my internet banking application. That single page, I believe, shows *only* the details of the wire (date, receiving account, amount) and doesn't expose my other info. That might be the way.

caveden

legendary

Activity: 1106

Merit: 1004

Quote from: waxwing on May 27, 2013, 04:06:38 AM

Quote from: waxwing on May 27, 2013, 05:57:01 AM

Of course, it's not the name+account nb that's sensitive (at least not IMO), it's the balance and transaction history.

waxwing

sr. member

Activity: 469

Merit: 253

Very interesting, are you describing what happens during the initial payment there? I think you probably have the right idea with that extra level of indirection. Let me cogitate a bit more

Side note: I had a wackier idea. How about another layer of cryptography? What we need is that the pages delivered to the user are (a) not tampered with = need to be digitally signed and (b) secret and not readable by the escrow agent UNLESS the user specifically allows it = need to be encrypted, (EDIT: delete reference to 2 of 3,makes no sense!)

Not even sure if it makes sense, let alone feasible, but if it were it might serve the same function: the user gets to say to the e. agent "only read the last delivered page" and passes the key for that , and that allows him to read the statement of transactions but not the login page or whatever.

On a slight tangent, I personally don't mind if others see my name and account number. As far as I'm concerned, that's semi-public knowledge.
Note that a) such a network can't work unless people give their bank account numbers, but these numbers are NOT centrally stored anyway (and can be passed over the P2P network encrypted)

b)People have to give this info. currently to exchanges, so at the very least we're not worse off (actually much better off).

c)Giving account number is the same as name+account number - from the point of view of a government agency it's trivial to get the former if you know the latter (they strong arm banks all the time over this)

so really the worst that happens from giving someone your statement is that they see your bank balance.

dansmith

full member

Activity: 202

Merit: 100

Enters the scheme where the user doesn't have to expose his bank credentials and doesn't have to use SSL re-negotiation.
(But what I'm proposing below adds an extra level of complexity).

A randomly selected gateway user comes into play. The payer who has possesion of the SSL key does his banking session by channeling traffic to the bank through/from the gateway user. When the payer in finished, what happens is:
1. The gateway user submits to the e.agent only those packets which the payer has designated. (Packets which don't contain sensitive info)
2. The payer submits to the e.agent his SSL key, so that the e.agent could decrypt packets which gateway user gave him

Weaknesses:
1. the bank may frown upon the payer logging into his bank from random IPs. But we discussed this earlier and it seems not to be a serious weakness.
2. The payer can flood the p2p pool from which the gateway users get selected by his accomplices. If the payer and gateway user are in cahoots, they can spoof the whole SSL session.
3. To mitigate #2, the gateway user should be the beneficiary of the payment. (The beneficiary has no interest to defraud himself), which leads to ...
4. If the beneficiary is the gateway user and over time has a lot of those who pay him, the bank will flag the beneficiary's IP because there will be many users of that bank logging into their accounts from the same IP.

dansmith

full member

Activity: 202

Merit: 100

Quote

There is an un-practical solution to recording only part of SSL session.
It can be done only if the bank supports SSL re-negotitation.
The user navigates his banking website to a certain page and then re-negotiates the SSL connection so that the e.agent is now in charge of the SSL key and sees only that particular page and not any previous pages, which includes not seeing the login page.
I examined SSL certificates of the largest western-world banks and the tally is that only 50% of banks support SSL re-negotiation. But what kind of user under normal circumstances does SSL re-negotiation? And so it will be very easy for banks to flag users who use this scheme.

waxwing

sr. member

Activity: 469

Merit: 253

Just moving up a level for a minute:
I think users of such a system have to accept that part of the deal is that they make their banking transaction record available to at least one third party. Note that when we use bitcoin we are doing something similar with the blockchain.
This is, to some extent, the payoff for abandoning a centralized counterparty (bank, stock exchange etc.). Trust from openness if you will.

Still I totally agree that the ideal is to only expose THIS transaction - not to expose your name, your bank balance, your other transactions .. and all the other stuff.
But let's be clear - this exposure is only to one other party, who may be living on the other side of the country, and has never met you, and more importantly: this will in most cases never happen - it will only happen if one side is lying about their transaction, and they will be STRONGLY disincentivized to do this exactly because there is a strong audit process in place.

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: caveden on May 27, 2013, 03:53:32 AM

Quote from: waxwing on May 27, 2013, 03:05:42 AM

To answer the question "why should my escrow see that" - the difficulty here is we are trying to prove whether the BTC seller has received the promised USD in his account or not. That can only be resolved by seeing a list of transactions for the given date.

You could show only the details of the relevant transaction. At least every internet banking I've used so far do display a "confirmation page" after a transaction is finished, and this confirmation page contains all relevant data for the escrow (source and target accounts, amount, date, description).
The only "inconvenience" is that the plugin wouldn't be able to automatically recognize the confirmation page - well, it could learn if it's a really fancy software with AI and all, but let's keep it simple please Wink

-, meaning that the user should manually indicate that "this is the good page to save". That's why I mentioned a printscreen-like button. And as long as the internet banking displays the details of past transactions, the escrow could always instruct his clients on how to obtain proof of transfer in case of a dispute, meaning that in 'everything goes well' use cases, people wouldn't even need to bother with installing the plugin.

Yes I think you understand the basic situation. The problems are technical, and I see two:
1. If we want a "proof of sending", we have to record all sessions, whether there's a dispute or not. Then we have to know how to parse the output in every case. Ideally this would be automatic, and we would have to build parsers for every possible bank, which would be an unfeasible amount of work imo.
By only running the "recording" process for audit cases (cases of dispute), we can fall back on "manual parsing" (i.e. the escrow agent or other expert just reading the decrypted output and interpreting it). This is not as bad as it sounds, because tools like Fiddler which I've been using today will allow you to view the decrypted output in text, hex or html (obviously easiest!). In theory you get to see the web pages exactly as the user saw them.
Now the reason this is a problem is that the auditing version means looking at the *output* of the wire transfer, not the input, which means looking at a record of the BTC seller (and USD buyer's) transactions. I guess we could (and perhaps should) look at the USD seller/BTC buyer's transaction record too. But anyway in this model (audit only) just looking at the "wire transfer sent confirmation page" can't happen.

2. The other problem is the technical problem of "recording" only *part* of the SSL session, so as not to expose the most sensitive data. I don't think the user could first login to internet banking, and then switch on a proxy to start rerouting traffic via the escrow's machine (who would then dump all decrypted SSL output). That's what we want, but it sounds somewhere between tricky and impossible. There needs to be a solution to this.
Dan's fallback of changing your password after the audit is a great idea for a last resort (or for the sensibly paranoid), but it can't be the main idea there.

caveden

legendary

Activity: 1106

Merit: 1004

Quote from: waxwing on May 27, 2013, 03:05:42 AM

dansmith

full member

Activity: 202

Merit: 100

@waxwing

Quote

Yes, if only the e.agent knows the key. I hadn't realised you were planning to make it work like that. Will it still be possible to prevent the e.agent from seeing the user's login details in this case?

I wasn't actually planning for it to work like that. But after you suggested the post-session audit, this scheme kind of became the natural path.
The scheme itself will discourage any would-be fraudsters. And the actual audit will be a very seldom occurence. So there is no big risk for the seller to expose his login credentials. At the end of the day, the seller can change his banking password after the audit.

@caveden
Sorry, we are all over the place here with the proposed schemes.
The latest solution as proposed by waxwing is to expose your online bank's balances only in rare cases a dispute arises.
This is in contrast to the initial proposal, where I suggested that all banking session is exposed from the get-to even before there is an actual dispute.

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: caveden on May 27, 2013, 02:26:30 AM

Sorry for not reading the entire topic, I'm just answering the OP. If what I'm saying has already been said, just ignore me. Wink

Don't worry, this stuff is kind of overwhelming for all of us!

Quote from: dansmith on April 11, 2013, 05:32:11 AM

4. After that all further traffic between user<<-->>bank gets redirected by the plugin through the escrow agent's proxy

All traffic? As soon as I log into my internet banking my balance is displayed, together with latest transactions. Why should my escrow see that?

Can't the plugin have a sort of "print-screen" button, and only send the content of the current page when this button is pressed (together with the SSL session information, of course)? The user could then send only the receipt page for the transfer, which should be enough.

We're working on that. Of course, we absolutely understand that the user cannot be expected to show their login details at any stage. For the limited version we are currently considering, it would be, we hope, more like what you describe: if the transaction goes through normally, you never have to expose any part of your bank account. If there is a challenge and an audit is needed, then your banking session is recorded, and yes that would mean exposing your bank account number (which you already had to do to join the network), possibly also your name (not ideal, I understand - there might be a way to avoid it, and your bank balance (also not ideal, I understand), but definitely not your login details. Giving the user, as you say, a button to press to start the recording would be the ideal situation.

It's tricky by any interpretation; verification means seeing two things: the bank account number (for the given bank) and statement covering the specified dates. It has to involve human intervention to look at this and parse it intelligently imo.

To answer the question "why should my escrow see that" - the difficulty here is we are trying to prove whether the BTC seller has received the promised USD in his account or not. That can only be resolved by seeing a list of transactions for the given date.

To dan_smith - mitmproxy looks like a very good tool. I also found Fiddler (fiddler2.com), which was very easy for me to install and use on my own Windows 7 box. Pretty much immediately, I was able to record and decrypt the SSL traffic coming from my own internet banking session. It claims to work with all browsers, I tried it in Chrome.

This page explains how to set it up as a proxy:
http://fiddler2.com/documentation/Configure-Fiddler/Tasks/MonitorRemoteMachine
(Obviously the user will need to trust the certificate).

At first glance, it doesn't seem to be open source which could obviously be a deal breaker in terms of using it in a serious way.

One funny thing is that my bank (in Hong Kong) will only display statements in pdf form! But the pdf was dumped out just like everything else.

caveden

legendary

Activity: 1106

Merit: 1004

Sorry for not reading the entire topic, I'm just answering the OP. If what I'm saying has already been said, just ignore me. Wink

It's a powerful idea, but there's only one thing that bothers me:

Quote from: dansmith on April 11, 2013, 05:32:11 AM

4. After that all further traffic between user<<-->>bank gets redirected by the plugin through the escrow agent's proxy

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: dansmith on May 26, 2013, 10:54:32 AM

Quote

Putting aside the user impersonates bank attack for now.

This quote of yours prompted me to re-emphasize, that:
the user cannot impersonate the bank in the case when only the e.agent knows the encryption key.
If the user was to impersonate the bank, the user had to submit to the e.agent SSL packets from the bank encrypted with the key. But the user does not know the key, and so he cannot impersonate the bank.

dansmith

full member

Activity: 202

Merit: 100

After asking Firefox folks on IRC, I realized that FF doesn't expose raw SSL packets.
The other solution from within FF is to write an add-on which would be a handler for https:// protocol - a task that probably only FF devs could pull off.

The remaining solution is from outside of FF. Assign an SSL proxy in FF settings. mitmproxy can be that proxy.
Some small changes to mitmproxy's code need to be made, so that mitmproxy channel the traffic first to e.agent (who has the key) and after that to/from user/bank.

dansmith

full member

Activity: 202

Merit: 100

Quote

Putting aside the user impersonates bank attack for now.

waxwing

sr. member

Activity: 469

Merit: 253

A bit more digging led me to Mozilla's NSS:
https://developer.mozilla.org/en-US/docs/Overview_of_NSS
In particular:
https://developer.mozilla.org/en-US/docs/NSS_Key_Log_Format
and ssltap at https://developer.mozilla.org/en-US/docs/NSS/Tools

This stuff is open source and recent. Maybe Firefox specific.

Possibly Wireshark may be another element: http://www.wireshark.org/.

waxwing

sr. member

Activity: 469

Merit: 253

Yes, that might be simpler as a first iteration.
Putting aside the user impersonates bank attack for now.

Right now I'm looking at http://www.rtfm.com/ssldump/Ssldump.html. Could be what the doctor ordered.

dansmith

full member

Activity: 202

Merit: 100

waxwing, if you were to implement it, take the simplest path.
Put aside random selection of a gateway user from a p2p pool. Also put aside the proxying of SSL traffic through the escrow agents server. The simpler scheme is when the e.agent is in possession of the symmetric key for the SSL session.

The user (of online banking) first submits all the traffic (he wants to send to the bank) to the e.agent.
The e.agent encrypts the traffic with the key and sends the encrypted data back to user.
The user then forward that encrypted data to the bank.

I haven't done any research. What you need is:
Browser plugin needs to intercept the traffic coming to/from the bank and redirect it to the e.agent for encryption/decryption.
The plugin then receives from the e.agent the encrypted/decrypted traffic and displays to the user.

I bet OpenSSL has user-friendly tools to construct, deconstruct a packet. Or at the very worst, you can borrow their source code.

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: Zangelbert Bingledack on May 26, 2013, 03:26:41 AM

Provided the data from the bank has the right characteristics, why couldn't an oracle be used as the escrow "agent"?

I only have a vague understanding of what is meant by oracle here (I read https://en.bitcoin.it/wiki/Contracts) but certainly such a mechanism could help for normal operation (kind of automated escrow?), but I think to try to automate the "audit" process I'm suggesting above would not be wise.

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: oakpacific on May 26, 2013, 03:48:09 AM

Quote from: Zangelbert Bingledack on May 26, 2013, 03:26:41 AM

Provided the data from the bank has the right characteristics, why couldn't an oracle be used as the escrow "agent"?

I think the data from the bank can always be faked, however for SSL connection, they will somehow be signed by the bank, and thus can be potentially used as proof of transfer.

As was pointed out earlier in the thread, the bank only signs at the beginning, after that the bank and the user share the master secret that's used for encryption of the data during the session. This means that the user can imitate the bank, but if the proxy stands between them, that's not a problem.

If the bank actually did cryptographically sign its outputs and send that in a decrypted form on request (e.g. a bank statement), we wouldn't need any of these shenanigans, but .. they don't.

waxwing

sr. member

Activity: 469

Merit: 253

So I'm left wondering about next steps. I'm thinking about avoiding wheel reinvention. This SSL thing could latch itself onto another system, like the opentransactions/bitmessage thing that fellowtraveller is working on. In my thread ( https://bitcointalksearch.org/topic/m.2210078 ) I was trying to build an architecture from the ground up, but I'm not sure how much of that proposal is really adding value.

For actually building the SSL dump / proxy etc. part - I'm far from the ideal candidate to kick it off, having only a few years experience as a software engineer, and that some time ago. If I wanted to do that myself, I'd need to spend a lot of time reading and experimenting with the basics. Someone who already has experience working with SSL and networking software generally might get a prototype up and running far quicker.

In any case, I will make a start of my own on it. Does anyone have any suggestions? Will OpenSSL help me?