tlsnotary - cryptographic proof of fiat transfer for p2p exchanges

[waxwing]

I have a new suggestion, melding together several of the ideas already mentioned:

Adam is going to pay Betty USD in return for Bitcoins.

1. Betty puts Bitcoins into escrow
2. The software starts a proxy server on Betty's machine for Adam
3. Adam connects to his internet banking via the proxy.

The proxy acts purely as a forwarding mechanism.
I am basing this on the description:

If you want to connect to an HTTPS website via an HTTP proxy, you need to use the CONNECT HTTP verb (because that's how a proxy works for HTTPS). In this case, the proxy server simply connects to the target server and relays whatever is sent by the server back to the client's socket (and vice versa). There's no caching involved in this case (but you might be able to log the hosts you're connecting to).

here: http://stackoverflow.com/questions/3118602/convert-http-proxy-to-https-proxy-in-twisted/3186044#3186044
(the first answer)
I would *really* appreciate input from someone with good technical knowledge of SSLs and proxys to comment on feasibility of this.

4. Betty's proxy server logs the entire banking session in ENCRYPTED form. Also, Adam's software logs the whole session too, in unencrypted form.
5. If the wire transfer is successful, everyone is happy, no need to do more. If Betty disputes that the wire is received, then:
6. Escrow agent is called in. Escrow agent requests Adam to identify from his logs which pages he would like to provide to agent as proof that he did carry out the wire transfer.
7. Escrow agent requests those specific pages (which remember are still encrypted) from Betty.
8. Escrow agent requests master secret key from Adam
9. Escrow agent can decrypt the specific intended pages and verify that the wire was sent.

Plus points about this approach:
*As long as both sides have the necessary software installed, then if the transaction goes through normally, no one has to do actually *do* anything to ensure trust.
*Adam (the USD sender) has control over which HTML pages he sends to escrow in case of an audit. Normally it will be the last one or two pages of the banking session, and it may well be possible that he doesn't have to reveal any other transaction, or his balance.
*By using the counterparty as the "gateway", we remove the incentive for collusion. This is a brilliant idea and full credit to dansmith for it.

[1714988600]

1714988600

[1714988600]

1714988600

[1714988600]

1714988600

[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).

Thanks Tim, interesting example.

The fact they do it in that way suggests the OP's way wont work, but maybe he is a better designer.

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

Maybe we all need to get on localbitcoins. It is a lot easier to shut down an exchange or processor taking $1M a month than to shut down a 1000 randoms doing a $1000 a month.

[oakpacific]

Hmmm, maybe we can form a Tor-like network with multiple non-colluding escrowers participated, each of them only keeps some of the packages transmitted, so none of them can recover your password and identity information, yet when required, can put all pieces together to verify if the proof of transfer from the buyer is real?

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

The fact they do it in that way suggests the OP's way wont work, but maybe he is a better designer.

Not sure I understand you there.

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

Maybe we all need to get on localbitcoins. It is a lot easier to shut down an exchange or processor taking $1M a month than to shut down a 1000 randoms doing a $1000 a month.

That's the purpose of what I'm doing in this thread - if this piece of the puzzle can be worked out, we can build an online and completely decentralized version of localbitcoins. See https://bitcointalk.org/index.php?topic=210903.msg2210078#msg2210078 for details.

[waxwing]

Hmmm, maybe we can form a Tor-like network with multiple non-colluding escrowers participated, each of them only keeps some of the packages transmitted, so none of them can recover your password and identity information, yet when required, can put all pieces together to verify if the proof of transfer from the buyer is real?

Tor had crossed my mind too, but I rejected it as (a) users will be put off by it and (b) it will make the networking side even more difficult to figure out. Certainly, the anonymity is important, and we should use as much encryption as possible, but there will still be occasions (not often) when someone else on the network sees your bank account number.

As for splitting the banking session records amongst many users, it seems very complicated.
First, to emphasise, we don't need to expose login details at all. (e.g. in the last version of the design I posted a few posts back).
But more importantly, I actually think we do need human intervention for the escrow action, in order to correctly parse the banking session record. So that would need one person to make the decision. The trick is that the USD seller would only show those pages he wanted to show.

My thought was always that the escrow would be chosen randomly from a large network thus making collusion between escrow and bitcoin seller either impractical or impossible.

[waxwing]

Following up on the proxy architecture, I found this re: HTTP CONNECT at http://muffin.doit.org/docs/rfc/tunneling_ssl.html

CONNECT is really a lower-level function than the rest of the HTTP methods, kind of an escape mechanism for saying that the proxy should not interfere with the transaction, but merely forward the data. This is because the proxy should not need to know the entire URI that is being accessed (privacy, security), only the information that it explicitly needs (hostname and port number). Due to this fact, the proxy cannot verify that the protocol being spoken is really SSL, and so the proxy configuration should explicitly limit allowed connections to well-known SSL ports (such as 443 for HTTPS, 563 for SNEWS, as assigned by the Internet Assigned Numbers Authority).

If that's right, the only caveat is that I'm not sure whether the proxy can easily record all the encrypted traffic going back and forth. Presumably we can just sniff the network traffic, although that would be a bit ugly. Much easier if the proxy server just logs it to file.

Or maybe I'm totally misinterpreting it.
For someone who actually knows networking this is probably all child's play
 

[oakpacific]

Hmmm, maybe we can form a Tor-like network with multiple non-colluding escrowers participated, each of them only keeps some of the packages transmitted, so none of them can recover your password and identity information, yet when required, can put all pieces together to verify if the proof of transfer from the buyer is real?

Tor had crossed my mind too, but I rejected it as (a) users will be put off by it and (b) it will make the networking side even more difficult to figure out. Certainly, the anonymity is important, and we should use as much encryption as possible, but there will still be occasions (not often) when someone else on the network sees your bank account number.

As for splitting the banking session records amongst many users, it seems very complicated.
First, to emphasise, we don't need to expose login details at all. (e.g. in the last version of the design I posted a few posts back).
But more importantly, I actually think we do need human intervention for the escrow action, in order to correctly parse the banking session record. So that would need one person to make the decision. The trick is that the USD seller would only show those pages he wanted to show.

My thought was always that the escrow would be chosen randomly from a large network thus making collusion between escrow and bitcoin seller either impractical or impossible.

Another problem is the Sybil attack, if the escrower is an informant, he can gather a lot of buyers' information this way.

[waxwing]

Another problem is the Sybil attack, if the escrower is an informant, he can gather a lot of buyers' information this way.

Really good point. Thanks.

First I would say that buyer information will only be exposed at the level of account number, bank and possibly name (all this info is already semi-public as we've discussed). This will only arise in the case of dispute. And for a lot of people (I can't say most, I just don't know), even in that rare dispute case, they will not even have to display their account balance, let alone other sensitive info.

(Other comments are for P2P exchange generally, I am thinking here more of my own plan as in https://bitcointalk.org/index.php?topic=210903.msg2210078#msg2210078):
But the general point of the Sybil attack applies to the role of escrow here. It's another good reason not to overemphasize reputation. Identities will be cheap to acquire here because they will be linked to bitcoin addresses. I wouldn't want to somehow make them artificially expensive. Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.(EDIT: Ignore that last sentence, doesn't make sense (see below)).

Off the cuff thought: we could retain the ability to create cheap addresses, and thus use the network to buy bitcoins for the first time, but limit escrow agency to members with non-zero bitcoin addresses (balance above X). This would prevent swamping the network. Then the escrow agent for any transaction would be chosen randomly from those slightly-higher-status users. And also, we could keep the option of a "second opinion" if an arbitration goes against you (but that's really off the top of my head, so if you don't like it, ignore it).

[nomailing]

(Other comments are for P2P exchange generally, I am thinking here more of my own plan as in https://bitcointalk.org/index.php?topic=210903.msg2210078#msg2210078):
But the general point of the Sybil attack applies to the role of escrow here. It's another good reason not to overemphasize reputation. Identities will be cheap to acquire here because they will be linked to bitcoin addresses. I wouldn't want to somehow make them artificially expensive. Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.

Off the cuff thought: we could retain the ability to create cheap addresses, and thus use the network to buy bitcoins for the first time, but limit escrow agency to members with non-zero bitcoin addresses (balance above X). This would prevent swamping the network. Then the escrow agent for any transaction would be chosen randomly from those slightly-higher-status users. And also, we could keep the option of a "second opinion" if an arbitration goes against you (but that's really off the top of my head, so if you don't like it, ignore it).

Indeed reputation should be in the system too. something like the OTC rating system. this would help to minimize disputes.
Why not link the p2p accounts (and the corresponding reputations) to the supplied real-world bank accounts? It would further minimize the number of disputes because nobody wants to risk that he can never use his bank account anymore in the p2p exchange. Is it possible to link p2p-account-reputations to real-world-bank-accounts without disclosing the bank-account-number to everyone? Maybe one could create a hash of the account-number, which then serves as the user-id in the p2p exchange?

Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.

Could you elaborate why this wouldn't help? I think if a user always trades using his paypal account, then he could build a good reputation by always using this exact paypal account. Consider he has a good reputation after some time, then he wouldn't want to fraud with this account? If you go further, a user might be able to link his paypal and bank-account and p2p-account all together to even get a higher reputation. And when he once linked them, then it's not possible to delink them anymore because everyone knows that these accounts belong to the same real-world person...

[oakpacific]

Another problem is the Sybil attack, if the escrower is an informant, he can gather a lot of buyers' information this way.

Really good point. Thanks.

First I would say that buyer information will only be exposed at the level of account number, bank and possibly name (all this info is already semi-public as we've discussed). This will only arise in the case of dispute. And for a lot of people (I can't say most, I just don't know), even in that rare dispute case, they will not even have to display their account balance, let alone other sensitive info.

(Other comments are for P2P exchange generally, I am thinking here more of my own plan as in https://bitcointalk.org/index.php?topic=210903.msg2210078#msg2210078):
But the general point of the Sybil attack applies to the role of escrow here. It's another good reason not to overemphasize reputation. Identities will be cheap to acquire here because they will be linked to bitcoin addresses. I wouldn't want to somehow make them artificially expensive. Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.

Off the cuff thought: we could retain the ability to create cheap addresses, and thus use the network to buy bitcoins for the first time, but limit escrow agency to members with non-zero bitcoin addresses (balance above X). This would prevent swamping the network. Then the escrow agent for any transaction would be chosen randomly from those slightly-higher-status users. And also, we could keep the option of a "second opinion" if an arbitration goes against you (but that's really off the top of my head, so if you don't like it, ignore it).

Something else that can be done is to require anyone who wants to be an escrower putting a specific amount of bitcoins in custody within an address that's multisigned by a number of randomly chosen escrowers(which rational people would be inclined to do for escrowing fees income), so as long as the majority of the escrowers are not informants, each government action against a bitcoin buyer will cost them a fortune. This should be combined with some rating system to use.

False reporting of government crackdown from buyers/sellers can also be suppressed by requirng them to work with randomly chosen escrowers.

[waxwing]

Indeed reputation should be in the system too. something like the OTC rating system. this would help to minimize disputes.

Whilst I'm not denying that reputation is a useful idea, I think it's dangerous to rely on it, because it can easily lead to quasi-centralization, e.g. everyone uses the Bitcoin seller with rating 1000. I know that can be offset with a price mechanism, but still. Better to have the system so that you don't really need to trust the counterparty. Centralization is death for this system.
At a higher level, it's something like: democratise decisions that need to be made (reputation is a kind of democracy), but even better is not to make a decision (i.e. instead of letting trusted parties do X, redesign X so that whoever does it, it's not really dangerous).

Why not link the p2p accounts (and the corresponding reputations) to the supplied real-world bank accounts? It would further minimize the number of disputes because nobody wants to risk that he can never use his bank account anymore in the p2p exchange. Is it possible to link p2p-account-reputations to real-world-bank-accounts without disclosing the bank-account-number to everyone? Maybe one could create a hash of the account-number, which then serves as the user-id in the p2p exchange?

Yes I originally wrote in my project description that the user is defined by a bitcoin address AND a bank account number. I agree.

Users will have to enter bank account numbers too (encrypted I guess by default), but they don't necessarily have to use them so that doesn't help.

Could you elaborate why this wouldn't help?

No, I can't elaborate. It seems to be nonsense. I think I just got confused about something

[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).

Thanks Tim, interesting example.

The fact they do it in that way suggests the OP's way wont work, but maybe he is a better designer.

Not sure I understand you there.

This is a specific example of the rule that says if other people have tried hard to solve a problem and failed, then it probably isn't easy to solve. People (Polipay) with real money to spend on programmers etc have already attacked one of the OP's sub-problems (proving that a bank transfer has been made) and the solution they came up with (letting their java app control your internet banking) sucks.

However, they want to do it in real time, whereas your proposal (if I understand correctly), doesn't. The escrow still waits for Betty to confirm that the bank transfer has been received before releasing the BTC. That would typically take a day or more. In this use case POLi sort of forcibly does the transfer for Adam, then sends a message to Betty (presumably via Polipay's servers) that the transfer has been initiated, and Betty is expected to trust that and supply the goods immediately. It is assumed that Betty is trustworthy because she is a business (and pays Polipay's fees).

Good luck with your idea, but I don't think it solves a problem that is holding Bitcoin back much.

[waxwing]

This is a specific example of the rule that says if other people have tried hard to solve a problem and failed, then it probably isn't easy to solve. People (Polipay) with real money to spend on programmers etc have already attacked one of the OP's sub-problems (proving that a bank transfer has been made) and the solution they came up with (letting their java app control your internet banking) sucks.

However, they want to do it in real time, whereas your proposal (if I understand correctly), doesn't. The escrow still waits for Betty to confirm that the bank transfer has been received before releasing the BTC. That would typically take a day or more. In this use case POLi sort of forcibly does the transfer for Adam, then sends a message to Betty (presumably via Polipay's servers) that the transfer has been initiated, and Betty is expected to trust that and supply the goods immediately. It is assumed that Betty is trustworthy because she is a business (and pays Polipay's fees).

Good luck with your idea, but I don't think it solves a problem that is holding Bitcoin back much.

OK, so now I understand what you mean - but it's an apples and oranges comparison.

We are only trying to create a way to "record" the internet banking session, but we are trying to do it in a technically transparent way so that the bank doesn't even know about it. (To my mind there is nothing morally wrong with it because the SSL session remains intact - nobody can eavesdrop on Adam's banking activities. Only when Adam *voluntarily* gives the session key to the escrow in case of a dispute would anybody see any part of his internet banking, and only the parts that he specifically chooses them to see.)

Poli on the other hand are actually doing your internet banking for you underneath their app (I won't comment on the technicals because I don't know what they're doing under the hood - could be calling bank APIs in the same style as OFX or could be actually generating normal internet banking sessions - the latter more likely but also a lot more work for them in terms of coding). That's a much harder thing to do than just passive recording of encrypted data. And of course no surprise, they are only doing it for a specific set of banks.

As to your last point, thanks for the good wishes and I'll politely disagree but that would definitely be better for another thread

[nomailing]

I have a new suggestion, melding together several of the ideas already mentioned:

Adam is going to pay Betty USD in return for Bitcoins.

1. Betty puts Bitcoins into escrow
2. The software starts a proxy server on Betty's machine for Adam
3. Adam connects to his internet banking via the proxy.

The proxy acts purely as a forwarding mechanism.
I am basing this on the description:

If you want to connect to an HTTPS website via an HTTP proxy, you need to use the CONNECT HTTP verb (because that's how a proxy works for HTTPS). In this case, the proxy server simply connects to the target server and relays whatever is sent by the server back to the client's socket (and vice versa). There's no caching involved in this case (but you might be able to log the hosts you're connecting to).

here: http://stackoverflow.com/questions/3118602/convert-http-proxy-to-https-proxy-in-twisted/3186044#3186044
(the first answer)
I would *really* appreciate input from someone with good technical knowledge of SSLs and proxys to comment on feasibility of this.

4. Betty's proxy server logs the entire banking session in ENCRYPTED form. Also, Adam's software logs the whole session too, in unencrypted form.
5. If the wire transfer is successful, everyone is happy, no need to do more. If Betty disputes that the wire is received, then:
6. Escrow agent is called in. Escrow agent requests Adam to identify from his logs which pages he would like to provide to agent as proof that he did carry out the wire transfer.
7. Escrow agent requests those specific pages (which remember are still encrypted) from Betty.
8. Escrow agent requests master secret key from Adam
9. Escrow agent can decrypt the specific intended pages and verify that the wire was sent.

Plus points about this approach:
*As long as both sides have the necessary software installed, then if the transaction goes through normally, no one has to do actually *do* anything to ensure trust.
*Adam (the USD sender) has control over which HTML pages he sends to escrow in case of an audit. Normally it will be the last one or two pages of the banking session, and it may well be possible that he doesn't have to reveal any other transaction, or his balance.
*By using the counterparty as the "gateway", we remove the incentive for collusion. This is a brilliant idea and full credit to dansmith for it.

A problem with the approach to always have the proxy on the machine of the BTC-seller is that they might not be online at the same time. How could they agree to a specific online time? Should they specify this in their trade? In principle the BTC-buyer could just say that he couldn't do the transfer because the BTC-seller was always offline when he wanted to do it.

[nomailing]

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

I would add SSL-renegotiation (as optional for the payer) to increase security. How could you really be 100% sure that the gateway and the escrow do not exchange more of your session-dump or your session-key? This doesn't look 100% secure, maybe just 99% secure without SSL-renegotiation.  So it's better for the payer to use SSL-renegotiation if his bank supports it. And many important websites seem to support renegotiation (e.g. paypal and large banks).

Probably the only reason why renegotiation is disabled on some websites is the security vulnerability (CVE-2009-3555). That many banks have it disabled is overkill, because there is a patch for OpenSSL to close this vulnerability. Maybe over time many websites will anyway update to the newer openSSL version and will enable SSL-renegotiation again.

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.

The problem which you describe in #2 applies also to the selection of the escrow agent. How would you make sure that the escrow agent is really a third party and not in cahoots with either the seller or buyer? Probably by some mechanism to randomly choose the escrow. So if it works there, why not use the same mechanism for the gateway? So I would say your point #3 doesn't make sense, especially if you think about the problem that they both have to be online at the same time it is better to select a random user from the pool?

To make sure that all 4 parties (seller,buyer,escrow,gateway) are really different persons, it would even make more sense to link p2p-accounts to real-world-bank-accounts. This would reduce the risk that someone could flood the p2p pool, because nobody has arbitrary many bank accounts.

[waxwing]

I have a new suggestion, melding together several of the ideas already mentioned:
...snip...

A problem with the approach to always have the proxy on the machine of the BTC-seller is that they might not be online at the same time. How could they agree to a specific online time? Should they specify this in their trade? In principle the BTC-buyer could just say that he couldn't do the transfer because the BTC-seller was always offline when he wanted to do it.

Although it's clearly not ideal to have this synchronization, this seems to be a less important issue. Counterparties displayed would be restricted to those who are active on the network at the time you are looking to trade. Both sides have to agree to a price as well as certain other settings possibly, and then the proxy-ed session to the bank can take place. Importantly, the BTC seller (acting as proxy) doesn't actually have to DO anything during the proxy session (doesn't have to sit at their computer), just has to be online. I think realistically they would want to stay around though and get a confirmation message that the encrypted data from the session was stored correctly.

If the BTC seller fails to store that encrypted data, they have forfeited the right to their (escrowed) BTC in case of a dispute. That works both ways; if the BTC buyer (the one who used internet banking to make a transfer) loses the SSL session key which decrypts the data, they also would forfeit their right to the BTC in case of a dispute.

[waxwing]

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.

The problem which you describe in #2 applies also to the selection of the escrow agent. How would you make sure that the escrow agent is really a third party and not in cahoots with either the seller or buyer? Probably by some mechanism to randomly choose the escrow. So if it works there, why not use the same mechanism for the gateway? So I would say your point #3 doesn't make sense, especially if you think about the problem that they both have to be online at the same time it is better to select a random user from the pool?

I agree that the 4th party is an extra level of architectural complexity that is worth avoiding if it doesn't really bring a benefit.

To make sure that all 4 parties (seller,buyer,escrow,gateway) are really different persons, it would even make more sense to link p2p-accounts to real-world-bank-accounts. This would reduce the risk that someone could flood the p2p pool, because nobody has arbitrary many bank accounts.

The only risk left once we move to the model I describe in post 61 is the collusion between the escrow and either the buyer or the seller. This is mitigated by (a)random choice, possibly more than once and (b) prevention of Sybil attack by cost of identity creation.
Would you not agree that this has all been covered in posts 65 and 67-71?

[nomailing]

I have a new suggestion, melding together several of the ideas already mentioned:
...snip...

A problem with the approach to always have the proxy on the machine of the BTC-seller is that they might not be online at the same time. How could they agree to a specific online time? Should they specify this in their trade? In principle the BTC-buyer could just say that he couldn't do the transfer because the BTC-seller was always offline when he wanted to do it.

Although it's clearly not ideal to have this synchronization, this seems to be a less important issue. Counterparties displayed would be restricted to those who are active on the network at the time you are looking to trade. Both sides have to agree to a price as well as certain other settings possibly, and then the proxy-ed session to the bank can take place. Importantly, the BTC seller (acting as proxy) doesn't actually have to DO anything during the proxy session (doesn't have to sit at their computer), just has to be online. I think realistically they would want to stay around though and get a confirmation message that the encrypted data from the session was stored correctly.

If the BTC seller fails to store that encrypted data, they have forfeited the right to their (escrowed) BTC in case of a dispute. That works both ways; if the BTC buyer (the one who used internet banking to make a transfer) loses the SSL session key which decrypts the data, they also would forfeit their right to the BTC in case of a dispute.

I am just comparing the two possibilities which you presented:
#1 The BTC seller is the gateway
#2 A fourth party is the gateway

I see only negative points with #1 and only positive points with #2. Let me elaborate:

I think many users would like to trade without recording their online-banking session if there is no dispute. You already proposed earlier that the method could be used after a dispute only. I personally would like that much more. But then you would have to wait maybe 1-3 days until the wire-transfer cleared and only then you would have to eventually enter the dispute process and use the proxy. It's not quite clear that the BTC seller is online at that time.

I, personally, would try to minimize the use of the proxy, because proxying an online-banking connection increases the risks (i.e. man-in-the-middle attacks as described in CVE-2009-3555). Your risks increase even more if you cannot use SSL-renegotiation during this banking session (i.e. your full recorded SSL-session is exposed to one party and could be decrypted using your master key, which you have to expose at least to another party). I personally would like to minimize both these risks and I also don't like to change my online-banking password so often.

Maybe you could persuade me to always expose my online-banking-session and the corresponding session-master-key if you could elaborate more on your proposal to use

(a)random choice, possibly more than once and (b) prevention of Sybil attack by cost of identity creation.

if you find 100% secure way to do this, then maybe I will trust this. Otherwise, I would prefer to trade without recording my SSL-session.

So in summary:
if we use option #1 the BTC seller is the gateway
--> BTC-seller and BTC-buyer have to be online at the same time
--> Only instant trades are possible (not possible to first wait for the clearing of the money-wire before a dispute)
--> Every trade has to use recording of SSL-sessions.
--> Much higher risks

in contrast, with option #2 where a fourth party is the gateway
--> asynchronous trades are possible
--> recording of SSL-session only in case of disputes
--> reduced risks

So why not allow p2p-trades with a lot of different contracts, depending on what risks someone is willing to take? I think the worst option is to only implement the solution with the highest risks, isn't it?

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.

The problem which you describe in #2 applies also to the selection of the escrow agent. How would you make sure that the escrow agent is really a third party and not in cahoots with either the seller or buyer? Probably by some mechanism to randomly choose the escrow. So if it works there, why not use the same mechanism for the gateway? So I would say your point #3 doesn't make sense, especially if you think about the problem that they both have to be online at the same time it is better to select a random user from the pool?

I agree that the 4th party is an extra level of architectural complexity that is worth avoiding if it doesn't really bring a benefit.

I don't see the extra level of complexity, because you have to implement some form of randomly choosing the escrow anyway. So you can also use the exact same algorithm to select an independent gateway.

To make sure that all 4 parties (seller,buyer,escrow,gateway) are really different persons, it would even make more sense to link p2p-accounts to real-world-bank-accounts. This would reduce the risk that someone could flood the p2p pool, because nobody has arbitrary many bank accounts.

The only risk left once we move to the model I describe in post 61 is the collusion between the escrow and either the buyer or the seller. This is mitigated by (a)random choice, possibly more than once and (b) prevention of Sybil attack by cost of identity creation.
Would you not agree that this has all been covered in posts 65 and 67-71?

I think your proposed solutions are really very good and I hope this will work. I am just comparing the options which you (and dansmith) already suggested earlier and at the moment I would conclude that it is much better to only record my banking session in the case of a dispute. And I see this only if the gateway is another user, because then nobody has to be online at the same time. Otherwise it would get really hard for some parties to proof that the gateway was online or was offline and if the connection was possible or was not possible because of some network failure or whatever. If the gateway is a party which is involved in the trade, it could get very hard to proof anything. If the gateway is choosen randomly at the time when it is needed, then you can proof something at all times independent from the other party.

[waxwing]

First, an update.

We have successfully tested the model:
client -> proxy(transparent) -> bank.
That is to say, we can decrypt the session on the client side, have the proxy store/log the session in ONLY encrypted form, and then later pass across the session key and decrypt the log on the proxy (or any other machine).

To emphasise, we are NOT using mitm on the proxy. The proxy never sees decrypted data unless someone gives him the session key.

This was a proof of concept of the basic architecture. It's not a surprise that it basically works, there was no fundamental reason for it not to.
All based on open source: firefox, wireshark/tshark,squid.

Where we go from here is up for debate.

But let me address some of nomailing's questions from earlier (sorry for the delay in getting back to you..)
------------------------------------------------------------------------------

I, personally, would try to minimize the use of the proxy, because proxying an online-banking connection increases the risks (i.e. man-in-the-middle attacks as described in CVE-2009-3555). Your risks increase even more if you cannot use SSL-renegotiation during this banking session (i.e. your full recorded SSL-session is exposed to one party and could be decrypted using your master key, which you have to expose at least to another party). I personally would like to minimize both these risks and I also don't like to change my online-banking password so often.

First, renegotiation is actually disabled by a large proportion of banks anyway, so we don't rely on it in our architecture. Second, the disadvantage of seeing the whole session without renegotiation has already been addressed in #61: if an audit takes place, the BTC buyer reviews the html pages from the recorded session (on his machine it's all unencrypted of course) and CHOOSES the pages he wants to expose to the escrow. The system then passes the ENCRYPTED SSL application data FOR THOSE SPECIFIC PAGES from the BTC seller to the escrow, so that the escrow only ever sees those html pages that the BTC buyer wants him to see. No one will ever see the entire internet banking session if you don't want them to (and you don't). You will allow them only to see the "send wire" page and the "confirmation" page, in most cases.
Of course collusion between the escrow and the BTC seller breaks this. But anything with escrow is broken by collusion. We can discuss this more later, but I want to get on to something else:

Maybe you could persuade me to always expose my online-banking-session and the corresponding session-master-key if you could elaborate more on your proposal to use

(a)random choice, possibly more than once and (b) prevention of Sybil attack by cost of identity creation.

if you find 100% secure way to do this, then maybe I will trust this. Otherwise, I would prefer to trade without recording my SSL-session.

I think I need to explain better why I switched from proposing recording the banking session only in case of audit to always recording the fiat-sender's banking session.

It's a result of the way banks operate. They do not consider it essential to display all relevant information to the user. For example, an online bank statement might have a record like this:
<date> <internal transaction id> CREDIT:<amount> USD <new balance>

rather than
<date> <type: wire> <sending account number> <sending bank> CREDIT: <amount> USD <new balance>

See the difference?
From the user's point of view, since the amount is the same in both cases, the first version is "good enough" to confirm the receipt of a wire. If that user needs more details they might have to use the phone or an email to get that information.

Now perhaps in YOUR internet banking software, these details are exposed, but they aren't in mine (and I checked very carefully).

So I thought about this and I realised that at the moment of actually SENDING the wire, these details HAVE TO BE DISPLAYED.
Because if they weren't displayed, the user could have no confidence that they were actually sending the right amount of money to the right recipient. Every internet banking that has wires enabled at all will have to display:
<receiving account number> <receiving bank> <amount>

So basically: the process of sending has to transparent to the user at the time of sending. The process of receiving is going to be recorded in various opaque ways. And even for the sender, if reviewing the transaction later, it may not be displayed in detail.

That's why I reverted back to the model "record the sending, but keep it encrypted and unreadable unless there's an audit."

I know that it's a huge advantage to not record the sessions by default, but you would have to tell me how to deal with the case of my own bank, where I can clearly see that the account numbers of wires I've received (or sent, believe it or not) are not being displayed.

OK there's a lot more to answer and to say but that's enough for now.

[marcus_of_augustus]

We have successfully tested the model:
client -> proxy(transparent) -> bank.
That is to say, we can decrypt the session on the client side, have the proxy store/log the session in ONLY encrypted form, and then later pass across the session key and decrypt the log on the proxy (or any other machine).

To emphasise, we are NOT using mitm on the proxy. The proxy never sees decrypted data unless someone gives him the session key.

This was a proof of concept of the basic architecture. It's not a surprise that it basically works, there was no fundamental reason for it not to.
All based on open source: firefox, wireshark/tshark,squid.

Good work. This is the coal-face of the interface with legacy banking and they must use internet technologies ....