[Dshield] Eavesdropping

Stephane Grobety security at admin.fulgan.com
Tue Jun 8 16:07:52 GMT 2004


TE> man, 07.06.2004 kl. 09.32 skrev Stephane Grobety:

>> That PDF is an excellent summary of several key concept in computer
>> crypto systems: Thank you, I will be re-using it.
>> 
>> What is doesn't contains, however, is anything to back up your own
>> comment: that HTTPS sessions can, are and will be hijacked.

TE> Self-signed, badly implemented certs and clients that do not actually
TE> complain, merely ask for confirmation.

Self-signed certificate are not part of PKI since they do not rely on
a third party to verify the identity of the certificate holder. They
do have their usage (mostly for people that know what they are doing)
but they are treated as certs with invalid properties by current web
browser (which is correct)

SSL clients (including web browsers) do the proper thing: ask the user
what they should do. Of course, user education is important in that
sense: if they have a warning about security, they should follow the
recommendation of 1/ their admin and 2/ the SSL client. Fact is, you
simply can't go away without some form of education. I'll remind you
of the latest poll where a majority of sampled people would give their
computer password in exchange for chocolate. I personally feels that
this kind of behavior can't be solved by throwing software at the
problem: you need either a hardware solution (that will enforced
additional access rules, like biometrics plus password plus token) or
some form of education for users (again, you don't need much: just a
few simple rules that are easy and convenient to follow coupled with
some form of responsibility in some cases).

As it stands today, here is the behavior of several web browsers when
it come to bad certificates:

1/ IE6 displays a clear, graphical warning with a list of items that
fails the test. The default is to refuse the connection.
2/ Mozilla displays a separate text dialog for each test failed. The
default on each test is to IGNORE and go on (bad point to Mozilla
here)
3/ Opera 7.50 beta 1 displays a single dialog that only displays the
first failing test (and with a wording that is hard to understand,
even when you know what it is supposed to mean). The default is to
IGNORE the warning and go on (double bad points for opera)

Now, as strange as it seems, IE is currently the browser that seems to
handle the "bad certificate" issue the most sensibly.

Now, let's think for a moment: every client displayed here behaved
exactly as it should: It got a certificate that was, in itself,
perfectly valid (properly signed and authenticated, etc) but that
failed on the attribute verification test (I tested with expired
certs, non matching host name and self-signed certificates). The
result is what you'd expected: the certificate was rejected and the
user warned, sometimes in confused terms but warned nevertheless,
about a security failure.

Now let's exaamine what it means in terms of security: a secure
connection was attempted and the user was warned about a security
failure. let's compare that to a more common, and easier to implement,
attack that can result in a MIM snooping: DO NOT use SSL at all. The
result ? Simply: no error message is displayed. Or rather, a message
is displayed by all browser by default ("you are about to send
un encrypted data to the web site, are you sure that[...]") but it's
almost immediately disabled by every user.

The net result is that, from a security point of view, the users that
will make the wrong security choice will be easier to fool with a
simpler scheme and therefore the warning is sufficient. One could
argue that better default could have been picked for some client or
that the default should be to fail to connect without any bypass
option in displayed in the default dialog, but these measures are not
going to improve security anyway.

>> 1/ It doesn't rely on the user making the wrong choice.
>> 2/ The server key hasn't been stolen by the attacker in a way that
>> isn't directly related to the SSL protocol.

TE> You now qualify your question by stating that everyone on every network
TE> must know exactly what he/she is doing and assumes that they care.

No, I didn't say that. What I specifically said was: "It doesn't rely
on the user making the wrong choice." Granted, that's a pretty wide
assumption but given the fact that it's simpler for an attacker NOT to
set up any encryption on the spoofed page than hope that the user will
make the wrong security decision, I don't see it as a problem for SSL
at all.

TE> The answer to your question is, as you yourself surely are well
TE> aware, "no".

It's not what your post lead me to believe: For me "session hijacking"
has a very specific meaning: You let someone establish his identity
with the server and then steal it's session (wether it's a TCP session
or an HTTP(S) session) to act upon his name. I might be picky, but it's
really not the same as mounting a MiM attack. Besides, as I tried to
explain, there are easier way to fool the naive user into falling for
a MiB setup.

TE> But the problem is, as the millions of zombies everywhere prove,
TE> that not everyone knows what they are doing, nor do most of them
TE> care - unfortunately :(

Zombies are a different problem and I don't think it's wise to mix
them into this thread (though I'll be delighted to speak about what
could be done to improve the situation on that front too).

The fact is that security ultimately relies on people, not machines.
As it stands today, it seems that HTTPS session established by people
that have the slightest notion of security (simple: "if there is an
error message, say No and contact your admin") are pretty safe from
snooping.

As an extra comment, I'd like to say that all this concerns MiM
attack, not SSL session hijacking (a different class of attack) and
that the message I was responding to aid, I repeat, "HTTPS sessions
can, are and will be hijacked". Perhaps it was just a
misunderstanding, though.

Good luck,
stephane





More information about the list mailing list