Client-server system with traffic encryption

[Oleg]

Good day.

We have client-server. Each client use password for authentication,
server has hashes of passwords. After successfull authentication
client and server transmits some data.

We need to encrypt transmitting data. As I understand, reading this
list, we need to generate session key and encrypt data, using this
key. I found that DH - one of algorithms for session key generation.
But it unsecure for the man-in-the-middle attack. Could we somehow use
password hash to rise the security?

I would be very much obliged to you if you will give me some
directions to google.

[Parch]

If what you want to know is how to prevent man-in-the-middle attacks,
then I think this article might be helpful:

http://www-128.ibm.com/developerworks/linux/library/l-openssl2.html?ca=dgr-lnxw06SecureHandshake

The essential point to remember is you have to be able to prove you
are communicating with a particular person/server (otherwise they
could be anyone). In general this requires there to be someone else
you trust -- which may or may not suit your application.

[Parch]

Sorry, I guess I overlooked something - if you've got a limited set of
servers, then you don't need a trusted third party to verify the
identities of 'new servers' that your application wishes to talk to;
you can build the certification into the client application instead.

On Aug 17, 5:35 pm, Parch <Parchan...@gmail.com> wrote:
> If what you want to know is how to prevent man-in-the-middle attacks,
> then I think this article might be helpful:
>

> http://www-128.ibm.com/developerworks/linux/library/l-openssl2.html?c...

[Oleg]

Thank you for your answers. Could you verify the following scenario:

We generate pair of keys: private and public, for example using RSA.
After that we incorporate public key to client application and private
to server. If client wants to login, it calculate hash of password and
send it to server. Server verify this hash with one that he has in
database. If hashes are equal, authentication successfull. After that
client send to server random generated text. Server sign this text
using his private key and send it back to client. Client verify
signature using public key. If everything is right, client "knows"
that he talks with "right" server. After that server and client begin
DH for generating session key. Server and client will use generated
session key for encryption and decryption of transmitted data.

Is everything OK in this scenarion or not?

> > > directions to google.- Hide quoted text -
>
> - Show quoted text -

[Andy Finkenstadt]

I *highly* recommend that you read Bruce Schneier's book "PRACTICAL CRYPTOGRAPHY" for reasons of how and why to set up a secure channel, etc., and why you don't want to roll your own.

--andy

[Parch]

Well, I can't see anything to prevent a man-in-the-middle attack. OK,
your client knows that the "right" server is in the communication
somewhere, but he does not know that to be the only party he is
communicating with. I respectfully suggest this sort of question is
better suited to a general cryptography discussion group than Crypto+
+. Let me pose another way of looking at the problem. There will be
middlemen to your communication anyway (e.g. an ethernet switch, your
client's network hardware, your OS's TCP/IP library). Forget about
trust, and wonder what is the difference from a middleman "attacking"
to just passing on your communications like a good middleman? It's
about whether the middleman "understands" what is going on, and can
use that information somehow.

What stops your ethernet switch from understanding, capturing, and
replaying the password hash?