SSL/TLS - am I doing it right?

[Frank Millman]

Sybren Stuvel wrote:
> Frank Millman enlightened us with:
> > If I understand correctly, a 'man-in-the-middle' attack would
> > involve someone setting up a 'pseudo server', which gives the
> > correct responses to the client's attempt to log in
>
> That's right. Usually it's done by proxying the data between the
> client and the real server.
>
> > and would also involve someone manipulating the client parameter so
> > that it points to the pseudo server instead of the real server.
>
> Yup. This can be done in various ways, like ARP poisoning of the
> network. Then the IP address will not change, but the network card
> that the traffic is sent to will. The fraudulent server, having the
> correct ARP table, can then forward the captured data to the real
> server.
>
> > What I have not understood is how to prevent this. How can the
> > client distinguish between a valid server and a fraudulent one?
>
> By checking the certificates. The CA mustn't sign server certificates
> except for the real server. The fraudulent server thus has no valid
> server certificate.
>

I don't know how to check the certificates. None of the documentation I
have read spells out in detail how to do this.

What about this idea? I am not looking for a state-of-the-art solution.
I am looking for something that is 'good enough' for a typical SME with
its own internal network.

Assume that the server is reasonably protected, i.e. can only be
accessed by administrators with valid permissions.

Assume that the client is reasonably protected - i.e. a fraudster
cannot access/change the file system. If this cannot be assumed, all
bets are off, as the fraudster can replace the pointer to the client
software with one to a modified version that bypasses the
authentication procedure, and we are back to square one.

Using openssl, generate a key for the server, generate a self-signed
certificate, and extract the sha1 fingerprint of the certificate. The
key must be kept secure but the fingerprint can be published.

When a client wishes to connect to the server, it must read a parameter
which includes the ip address, the port number, and the fingerprint.

After establishing an SSL connection, the client compares the session
fingerprint (TLSLite has a getFingerprint() function) with the
parameter. If different, client assumes it is talking to an imposter
and disconnects.

Are there any gaping holes in this approach?

Thanks

Frank