Ian G wrote, On 2009-03-22 16:01 PDT: > Man in the Browser. It is a term that seems to have caught on to > describe what happens when the browser is taken over by malware, and it > owns the interface. To solve the security problems that arises in > online banking is more challenging, which is where the Europeans moved to.
Thanks. I don't know why that abbreviation didn't come to mind before. > This is one of those cases where dire predictions of doom & gloom did > not come to pass, *but* the European banks (generally, not all) put in > place enough to mitigate it. What have they done? How do they stop, or detect, MITB? > As the problem didn't surface to any great extent in the USA, there is > dispute as to whether it doesn't really exist, or whether there are just > easier pickings elsewhere, and it's coming sometime. MITBs certainly exist. There's a company that bills itself as being the "Nielsen ratings of the Internet" (more than one, I'm sure). They get volunteers to install their software, and thereafter their software gets a copy of every bit received by the volunteers' browsers. They formerly used an MITM proxy (which, to their credit, even proclaimed itself as the MITM proxy when you connected to it :) and installed their own root CA cert in your browser, but that drew too much attention from certain quarters (ahem) so they switched to MITB. This MITB only works in IE, or did so the last time I checked, so it gets less attention around here. :) > So (in a sense you will be familiar) SSL is often "blamed" for all sorts > of problems in online banking. This is somewhat fair because SSL was > originally pushed for the purpose of protecting transactions. (or protecting anything else that went through the secure pipe against certain threats defined in that threat model.) > This simplistic view is extremely difficult to push past because those > that support SSL won't ever say "don't use SSL for that" Certainly SSL (the protocol) is not mutually exclusive with other technologies that have different scope than protecting transport connections. For example, I use S/MIME over TLS daily. I wouldn't say "Don't use TLS for secure email", but I would readily say (and have said) "Don't use TLS *exclusively* (and nothing else) for secure email". > and meanwhile, SSL is still pushed as the way to do security for online > transactions. Secure online transactions need secure pipes. They may also need other things. I would say that secure pipes are necessary, but may not be sufficient for all needs. > So its existence has an effect of blocking any accurate discussions. > Which is sort of rationalised at different levels. I'll grant that the industry has just so much manpower to devote to all these issues, and has prioritized secure transport ahead of other things, to the delay of those other things. I wish I could say that secure transport is finally becoming ubiquitous and trouble free, (as, say, TCP has become) so that the industry could get on to other matters, but alas there are still too many products that don't get it right. You may know and/or recall that, back in the mid 90's when https and SSL took off (in the browser market) largely because the number one browser of that time backed it, there was another competing proposal for securing web communications. It was based on securing the data, not the connection, and its design had the property that its evidence of authenticity survived the transport connection's termination. It was called shttp (which had an unfortunate pronunciation) and was championed by Eric K Rescorla, who is today the co-chair of the TLS working group (IINM). So, it can truly be said that the success of TLS did reduce the effort being expended on alternative approaches. Maybe it's time for a resurrection of shttp? > (By SSL, here, I do not mean the protocol, I mean the whole secure > browsing experience. For the protocol I prefer the term TLS. But > that's just me.) Please do find another term for "the secure browsing experience". SSL and TLS are both names for versions of the same protocol. >> The problem has been that people who wanted a different model kept >> wishing SSL had the model they wanted, and hating SSL for not having >> the model they wanted, rather than inventing the thing they wanted. >> TLS does not hold them back, except perhaps psychologically. > > Exactly, like that! That's what we want to hear. So when any other > model is presented, the people who support the SSL model will hopefully > refrain from trashing the alternates :) Once people state clearly that they're trying to solve a different problem than transport level security (secure pipes), they'll probably get HELP from some of the TLS folks who are bored with TLS now. The people who get resistance are those who keep trying to turn TLS into something other than secure pipes. I wonder if EKR is still interested in shttp. I think TLS folks do not push TLS as the solution where it doesn't fit. TLS folks will be the first to tell you that TLS is not the solution to secure email, for example. They will be quick to point people who are trying to secure their email in the direction of S/MIME. Of course, S/MIME and TLS are not mutually exclusive. I use them together every day. When the NSS team was pressed into service for a time as the secure AIM team, back in ~2001, we devised a hybrid in which S/MIME was used to secure the instant messages, and TLS was used for file transfer. The entire solution featured end-to-end security. Even TLS was end-to-end, with no decryption and re-encryption in the middle. The user's same cert served as both his S/MIME cert and his TLS server and client cert. The important identity element was not his DNS name but rather his "screen name", but an email address would also suffice. Each technology was used where it fit the problem. But the need for secure pipes in the Web isn't going away soon. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
