On 02/26/2012 09:34 AM, Andy Steingruebl wrote:
On Sat, Feb 25, 2012 at 4:54 PM, Marsh Ray <ma...@extendedsubset.com
<mailto:ma...@extendedsubset.com>> wrote:
Still it might be worth pointing that if Wells Fargo really wanted
to forbid a Trustwave network-level MitM, SSL/TLS provides the
capability to enforce that policy at the protocol level. They could
configure their web app to require a client cert (either installed
in the browser or from a smart card).
Maybe though you meant this specific type of "non-malicious" MiTM
and the problem is we don't have a name for that right now.
If you meant all MiTM though,
I think I meant to say "Trustwave-like", but yes I did mean all MitM
because I was thinking about the network protocol level at which there's
no distinction between "malicious" and "non-malicious" impersonation.
your solution only only stops attackers who wants to make it look
like you're interacting with the real site, not one who merely
wishes to steal your data. In that case they don't have to talk to
the real wells-fargo website :)
So there are several issues here, and they all have to be right for
everybody to obtain that elusive "security". I believe you're referring
to a phishing attack, where the bad guy impersonates the site to the
user generally in order to trick the user into disclosing their login
credentials.
A. The site must authenticate the user.
This nearly always revolves around a password (with sometimes a few
other factors thrown in for good measure). The password is something the
user is expected to keep totally secret, except when he is required, on
demand. to transmit it securely to the legitmate site.
Which means in order for this authentication to be secure ...
B. The user must reliably authenticate the site. This is quite a
challenge for anyone, let alone the non-expert user.
The identity the user has in mind is something like "The Wells Fargo
website where I access my online banking", if the user hovers the mouse
in Firefox, what they see in the absence of an attacker is:
You are connected to wellsfargo.com which is run by (unknown)
Verified by: VeriSign Trust Network [lock icon] Your connection to
this website is encrypted to prevent eavesdropping. [More
information...] Website Identity Website: www.wellsfargo.com Owner:
This website does not supply ownership information. Verified by
VeriSign Trust Network [blah blah] Technical Details Connection
Encrypted: High-grade Encryption (RC4, 128 bit keys) [blah blah] It
is therefore very unlikely that anyone read this page as it traveled
across the network.
What they see in the presence of an attacker is:
You are connected to wel1sfargo.com which is run by (unknown)
Verified by: IntegriTrust Trust Network [lock icon] Your connection to
this website is encrypted to prevent eavesdropping. [More
information...] Website Identity Website: www.wel1sfargo.com Owner:
This website does not supply ownership information. Verified by
IntegriTrust Trust Network [blah blah] Technical Details Connection
Encrypted: High-grade Encryption (RC4, 128 bit keys) [blah blah] It
is therefore very unlikely that anyone read this page as it traveled
across the network.
Obviously this is going to be a challenge. (Hint: look closely at the
ells in 'wells').
At first glance, this issue would appear to be a problem at a higher
level than TLS can help with, because TLS just authenticates short
strings (like hostnames) against x509 certificates.
Assuming the username/password box on their home page does what it says,
Wells Fargo is not authenticating their user to modern cryptographic
standards. Instead they are using plaintext passwords, which are
forwardable, replayable, low-entropy credentials. In fact, the security
of the system the bank deployed relies on the bank customers to perform
the cryptographic authentication! How messed up is that?
So this raises another principle:
C. The site-to-user authentication and user-to-site authentications
should be cryptographically bound to provide true mututal authentication
rather than two independent bidirectional authentications.
With mutual authentication, the legitimate site that issued the client
credentials has the ability to prove the absence of a MitM.
Bidirectional authentication tends to have failure modes that true
mutual authentication does not and phishing for passwords is probably a
good example.
So if the online banking site required TLS client authentication with
smart cards with on-chip RSA, the situation would be much different. A
MitM who succeeded in impersonating the site to the user would be unable
to replay or forward the user's credentials. In theory, the user could
not be socially engineered out of his credentials (short of physically
handing over his smart card).
Now of course client certs and smart cards don't solve every problem and
certainly more than one once-starry-eyed organization ends up wishing
they'd never heard of them (*cough* DigiNotar PKIoverheid). From what I
read, it sounds like the great majority of online banking fraud involves
a Windows PC infected by malware. Since a protocol can't secure a login
session against a pwned endpoint client certs may not even solve the
most common problem.
The only point here is that banking and other web sites aren't using
every tool in the box of supported and available cryptographic
protocols. They're securing to a level which optimizes cost/benefit.
This is exactly why some people are pushing so hard for protocols
that get "exclusion" including things like CA-Pinning in Chrome,
CAA, etc...
I think these things could be very valuable lots of situations, but for
a banking website they may amount to improving the long range accuracy
of the sniper rifles the bank gives to its customers in the expectation
that they will defend the interests of the bank.
- Marsh
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
