[Security] TLS Certificates Verification

Jonathan Dickinson jonathanD at k2.com
Tue Aug 19 14:04:44 CDT 2008

The reason I am saying MITM attacks won't work is because:

You are connected to j.o via SSL/TLS. J.o presents a certificate that leaves no doubt as to whether or not J.o is indeed j.o.
J.o is connected to t.g.c (talk.google.com) via SSL/TLS. T.g.c presents a certificate to j.o, so that j.o knows it is connected to t.g.c.
T.g.c is connected to joe at t.g.c. When joe connected to t.g.c he was presented with a certificate to confirm that he is joe.

Thus, at no point can a MTIM hacker create his dummy entity. Or do I have the whole set up wrong?

Sorry always get RSP in the wrong order :). Not sure what acronym my brain is confusing it with :P.

Indeed, if me at j.o wants to make sure that he is connected to joe at t.g.c then I would probably need some public key infrastructure, or shared password. However, if a hacker found the password to joe at t.g.c account we can only hope he used a different password for his pfk :P.

-----Original Message-----
From: security-bounces at xmpp.org [mailto:security-bounces at xmpp.org] On Behalf Of Eric Rescorla
Sent: Tuesday, August 19, 2008 8:51 PM
To: XMPP Security
Subject: Re: [Security] TLS Certificates Verification

On Tue, Aug 19, 2008 at 11:13 AM, Jonathan Dickinson <jonathanD at k2.com> wrote:
> Diffie Hellman only allows a common passphrase to be generated by exchanging information that doesn't allow the eavesdropper to determine the passphrase. This passphrase is fed into a symmetric encryption algorithm.
> Diffie hellman is quite unique and could be called 'zero-knowledge passphrase generation'.
> Diffie Hellman keys are one-time, that is, they are used only once per session.
> The only problem is the man-in-the-middle attack. Diffie hellman can be done over a secure channel, however, which eliminates man-in-the-middle attacks.
> Thus:
> Each party exchanges their 'keys'.
>  - These keys may be stored in memory/logs on servers on the internet etc. but are useless because diffie hellman can only be cracked using a man-in-the-middle attack (reading logs is eavesdropping).
>  - Man-in-the-middle attacks are not possible because each endpoint is connected to the other via TLS.
> The parties ecnrypt messages from then on using the shared key.
>  - It is seen as difficult (breaking diffie hellman would also result in breaking TLS) to break diffie hellman. The eavesdropper can't determine the key and hence can't decrypt the messages (e.g. if encrypted using decent cyphers like AES).
> The parties destroy their keys once the session is complete.
>  - The diffie-hellman key has a one-time-key loving properties which makes it incredibly difficult to determine even under cryptanalysis of many similar messages.

I'm sorry, I'm pretty familiar with DH, but I don't understand what
you're proposing.

You seem to be assuming that TLS is providing you with a secure channel, but
TLS is only secure against MITM attacks if you authenticate at least one side of
the channel, but that'xs exactly what we're trying to achieve here, so if we
could assume that we would be done.

> Once again, RSP resolves the problem of the man-in-the-middle attack, but means a lot needs to be set up beforehand: such as shared passwords etc.

You mean SRP, right?

More information about the Security mailing list