tlsnotary - cryptographic proof of fiat transfer for p2p exchanges

[dansmith]

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.

[1714037877]

1714037877

[1714037877]

1714037877

[waxwing]

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.

[waxwing]

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/.

[dansmith]

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]

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.

[waxwing]

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.

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?

[caveden]

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.

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

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.

[waxwing]

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.

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

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

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.

[dansmith]

@waxwing

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.

[caveden]

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 -, 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.

[waxwing]

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 -, 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.

[waxwing]

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.

[dansmith]

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.

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.

[dansmith]

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.

[waxwing]

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.

[caveden]

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? Only the handshake is properly signed? Each single message is not signed by the server?

Tough.

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.

[waxwing]

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.

Only the handshake is properly signed?

Exactly. That's the only bit of signing the bank server does.
The rest of the data is encrypted with the symmetric key which the two counterparties have agreed on for the session, after the SSL handshake protocol is carried out at the beginning.

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.

[waxwing]

Just did a little experiment. Looked at a wire transfer that I made some time ago, last August, on my statement, and saw that it only shows some kind of transaction ID, not the actual information (the receiving account number or name or bank), so that would actually be quite useless. I would have to rely on the internal messaging thing as I mentioned above, but this message is deleted by the bank after 30 days.

There will be lots and lots of little quirks like this.

[TimJBenham]

Goal: a payer needs to prove that he made a money transfer into the account of the seller (of BTC). This proof is only needed to be presented to an escrow agent in case a dispute arises. This proof aka SSL dump should not disclose payer's online bank login credential

POLi does something similar. It uses a java applet that drives your internet banking interface for you (you just get to type your password and click Confirm), so they could steal your password (but promise not to).

[waxwing]

Goal: a payer needs to prove that he made a money transfer into the account of the seller (of BTC). This proof is only needed to be presented to an escrow agent in case a dispute arises. This proof aka SSL dump should not disclose payer's online bank login credential

POLi does something similar. It uses a java applet that drives your internet banking interface for you (you just get to type your password and click Confirm), so they could steal your password (but promise not to).

Thanks Tim, interesting example.

Meanwhile comment: today's news on OKPay is yet another example of the urgent need for decentralizing the fiat-in part of cryptocurrencies..