On 23/3/09 20:36, Nelson B Bolyard wrote:
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?
I haven't followed it in depth, but the primary way that the E.B.s have
responded is to move their existing TAN system to a cellphone SMS (which
the europeans call "handys", brits call them mobiles). A TAN is a
transaction authentication number which is distributed on a paper sheet
to users. When the transaction is finalised, the user types in a TAN
taken from a supplied index like row,col, and crosses it out on the paper.
For the SMS interface, I think what happens is that the entire
transaction is then sent to the handy of the user, which the user then
presumably agrees with, and enters the TAN that is indicated in the SMS
message.
The further fix is to relate the transaction directly with the TAN so as
to link them together. There are experiments with this, but I'm unsure
of progress.
This is sometimes known as two-channel authentication, to distinguish it
from two-factor authentication which is subject to MITM, etc.
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. :)
Ha!
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.)
Right. The message was "a secure pipe protects" ... wrap a lot of other
words around, and often the message migrates to:
SSL + firewalls = security.
(long debate in other circles...)
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".
Ah. So, I see this is migrating to "use popular Internet RFC standards
for security." The problem with this is that some of them -- like
S/MIME -- are practically worthless whereas some of the non-RFC standard
products like Skype are very secure.
So when we consider a statement about such things, we have moved away
from a strict security discussion and across to a wider Internet / open
source / new economics discussion.
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.
Nope. Secure transactions need systems that protect transactions, not
pipes. Indeed, putting them in a secure pipe is likely a way to make
them insecure, because at the beginning and end of the pipe, they lose
their clothing, and the pipe itself is generally designed to the wrong
security model. C.f. SSL is the canonical textbook example of why
secure pipes do not result in transaction protection, and likely reduced
overall protection by distracting from the real issues.
A secure transaction needs to integrate from the asset owner to the
asset facilitiator and then across to the asset receiver. This
generally involves dozens of steps over many time points, so the secure
pipe paradigm is simply too unreliable to work, aside from any questions
of whether the crypto covers the threat area (it doesn't).
Back in the 1990s, the American Banking Association commissioned a
complete redesign of the american payments infrastructure for just this
purpose. It's called X9.59, you may know it as "Lynn Wheeler's frequent
rants". Its design does not rely on pipes, and is secure even across
the open network.
(As it happens, I did the same thing before them, but without the
backing of the ABA, and more oriented to a 3-party model not a 4-party
model. Regardless of the wallet size, neither of us were able to budge
the incumbents. For fairly good business reasons; they make more money
running the old stuff.)
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).
Funnily enough, I had this same conversation with Eric. After he
understood what I was saying about transactions, he commented to effect
of "gosh, so I was right all along with shttp," which was the first time
I ever really heard of it.
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?
Well, if I have learnt anything in my time at Mozilla over the last 5
years, on and off, it is that there is no possibility of changing the
dominant paradigm by going through the front door. The barriers are
stacked up to the skys.
There are only two possibilities that I have seen. Complete whole-cloth
reworks from the ground up, *coupled to new applications*. This is the
Skype / SSH route. I'd love to do that, and make that money, but maybe
I'm not that smart :)
Or, we look at the existing successful code base and work out how to
unlock the chains and get it to users.
(Hence, today's subject line. What can we do to make client certs
actually reach out and deliver to users? Today's task: solve the
session problem.)
(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.
I'm willing to use any term, but I would like people to agree on it, and
not use the terms to distract people up and down the stack :) The
reason I use SSL is because the term has been so abused in the past that
it is fairly well recognisable. E.g., give up the lost fight.
And, "secure browsing" is so vague, it always sends people to sleep, or
causes them to say, oh, that's not my department, you need to talk to
the GUI/PKIX/CA/... people.
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 bet he'll say "use DTLS, you would be mad to use anything else." :-)
Which just so happens to be a variant of TLS written for UDP transport
... by Eric!
Although this is fine, the problem we face right here is: we are trying
to get security to users. Users have browsers. Browsers connect to
servers. The security that users want is authentication, primarily, and
some shonky encryption is fine.
So, fundamentally, we are talking about HTTP, and that is more or less
constructed as HTTP over cached sessions over TCP. So, the SSL model is
more or less pre-ordained here, as whatever you are doing, it always
ends up being a transaction layered over a connection.
Unless you want to redesign HTTP over UDP, which would be a very smart
thing to do. Then things would improve, because it is request-response
model, not a serial data model. But, this is totally out of the
question in the real world, because Mozilla only follows standards, it
doesn't do architecture beyond following pre-cut blueprints, and there
isn't a HTTP over UDP that I know of.
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.
That reminds me of the old joke about communist economists. They used
to say, there are communist economists who were good, ones who were
honest, and but there were no good honest communist economists.
Something like "There are no good honest security practitioners
suggesting that a user lose her day over getting S/MIME going."
(I use S/MIME every day too, and over TLS. I also suggest that the
other security people use it and be abused by it, maybe because I am a
sadist :) Although not scientific, here are some results: within this
one highly-motivated security community of around 20-40 people, I see
about a 60% success rate in install + certificates, and something less
than 10% success rate in delivered secure messages. E.g., worthless.)
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.
Ha. Sounds like fun! Real security is end-to-end, indeed.
But the need for secure pipes in the Web isn't going away soon.
Right. But it shouldn't interfere with the need for secure
transactions, which practically speaking cannot be helped with secure
pipes. And it should deliver its model up to the user's eyeballs,
something that the GUI people are told they should not do.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
