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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wants to make sure that he is connected to [EMAIL PROTECTED] then I would probably need some public key infrastructure, or shared password. However, if a hacker found the password to [EMAIL PROTECTED] account we can only hope he used a different password for his pfk :P. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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?
