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:
CREDIT: USD
rather than
CREDIT: USD
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:
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.