[cryptography] trustwave admits issuing corporate mitm certs

Marsh Ray marsh at extendedsubset.com
Sun Feb 26 16:45:34 EST 2012


On 02/26/2012 09:34 AM, Andy Steingruebl wrote:
> On Sat, Feb 25, 2012 at 4:54 PM, Marsh Ray <marsh at extendedsubset.com
> <mailto:marsh at 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



More information about the cryptography mailing list