Re: SSL/TLS - am I doing it right?


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

.

Relevant Pages

  • Re: Secure VPN access
    ... with it's security option for the client. ... After getting the VPN connection I check the Ip settings and found the ... point to the head ISP's DNS server. ... > Computer certificates for L2TP/IPSec VPN connections ...
    (microsoft.public.windows.server.sbs)
  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • This is going straight to the pool room
    ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
    (comp.os.vms)
  • [Full-Disclosure] R: Full-Disclosure Digest, Vol 3, Issue 42
    ... Full-Disclosure Digest, Vol 3, Issue 42 ... SD Server 4.0.70 Directory Traversal Bug ... Arkeia Network Backup Client Remote Access ...
    (Full-Disclosure)
  • Re: IIS website - only allow users with client cert from our CA. P
    ... Rootyou wish to permit certificates issued from for access to your site. ... our CA's client cert? ... I only have a server certificate from our CA ...
    (microsoft.public.inetserver.iis.security)