SSL/TLS passive sniffing

[Ian Grigg]

Hi Ben,

> I'm a bumbling crypto enthusiast as a sideline to my other, real, areas of
> security expertise.

That's what most of us really are, to be fair.  Crypto is
such a small part of security that most all crypto people
move across to general security once they realise there
isn't much work around for a pure crypto person.  Which is
good, because only in the general security field can one
really make a difference, IMHO, because that's when starts
to understand what is needed, as opposed to what's cool.

> Recently a discussion came up on firewall-wizards about
> passively sniffing SSL traffic by a third party, using a copy of the server
> cert (for, eg, IDS purposes).

OK.  A nice challenge to assumptions!

> There was some question about whether this is possible for connections that
> use client-certs, since it looks to me from the spec that those connections
> should be using one of the Diffie Hellman cipher suites, which is obviously
> not vulnerable to a passive sniffing 'attack'. Active 'attacks' will
> obviously still work. Bear in mind that we're talking about deliberate
> undermining of the SSL connection by organisations, usually against their
> website users (without talking about the goodness, badness or legality of
> that), so "how do they get the private keys" isn't relevant.

I note that disctinction well!  Certificate based systems
are totally vulnerable to a passive sniffing attack if the
attacker can get the key.  Whereas Diffie Hellman is not,
on the face of it.  Very curious...

( I had at first thought this would be related to the many
and various ways to acquire a "forged cert" but it is not.
You have to have access to the actual key in use at the
time, to conduct a passive attack.  Mind you, if you had
access to a forged cert then you could conduct an active
MITM.  But that then equates it to an active attack against
Diffie Hellman. )

> However, I was wondering why the implementors chose the construction used
> with the RSA suites, where the client PMS is encrypted with the server's
> public key and sent along - it seems to make this kind of escrowed passive
> sniffing very easy. I can't think why they didn't use something based on DH
> - sure you only authenticate one side of the connection, but who cares? Was
> it simply to save one setup packet?
>
> Anyone know?

Well.  I would say that "knowing" is rather difficult in
precise terms, even for the people who were involved in
the essential design of the first version of the PKI.  But,
for what it is worth, here are my impressions, derived from
a couple of years of (amateur) research into why SSL/PKI
is so ... obscure?  Well, pick your own term.



In the design of the SSL protocol and its associated PKI
using x.509 certs, there are a lot of decisions that are
questionable on security grounds.

There are a lot of ideas that simply don't make a lot of
sense if one is thinking from a pure security sense.  By
way of quick example, they were nominally trying to protect
credit cards from being sniffed, which would be a low value
attack.  But, they decided to downgrade things like Diffie
Hellman, which would easily have defeated a credit card
sniffing attack, by forcing in place an MITM, which would
have left easy tracks to follow.  And they downgraded the
self-signed cert, which properly employed defeats phishing
(they weren't to know that then, but clearly their view
of attacks was incomplete).  There is more and if you are
interested I'd invite you to spend an afternoon on the
rants at http://iang.org/ssl/ .

So, eventually, in searching for the driving forces behind
the protocol, one is directed away from "defeating the
threat" that was nominally on paper to other areas.  And the
goal that seems to come up most is "using CA-signed certs."

If one thinks in terms of a protocol designed to use lots of
certs, then SSL would fit that bill;  it explains in some
sense why the user cannot just create their own cert and
use that to talk to their bank.  Instead, the bank must
demand a cert, and thus demand a particular cert, one
which presumably came with specific requirements as okayed
by the bank.  It explains why email using the certs is a
dead duck;  because there is no button on people's mailers
to create a user cert.

Now, I always assumed that what was happening here was that
the original advisers to the SSL team were trying to set up
a franchise to sell certs.  There is quite a lot of evidence
to this effect.  The whole pre-crash history of Verisign is
basically that;  RSADSI had a *lot* to do with it, and they
had a financial interest in Verisign.  In the commentary of
the times, you will see repeated reference to "the search for
the revenue model."  If you recall, Netscape was caught
between a wildly successful IPO and a big barrel of cash,
and no way to return any investment to the shareholders ...

(a bit like google is now ;)

So my personal theory is that the emphasis was placed on
"the cert secures all" because "the cert will make us lots
of money."  (History proved them wrong in one sense, in that
cert sales are only 100k per annum which is not enough to
justify all the fuss.  But, in another sense, the original
shareholders of Verisign, well, they would disagree and say
that it made them a bucket of money.  But that's all after
the fact, and irrelevant to why they did what they did.)

Either way, that's my theory.  If you view SSL / PKI as a
protocol designed to sell certs, a lot of it makes a lot
more sense.  It's just a theory!

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com