SSL/TLS - am I doing it right?

[Michael Ekstrand]

Disclaimer: I am not an expert. Take this with a grain of salt... but
I'll throw it out for what it's worth.

On 14 Mar 2006 04:12:38 -0800
"Frank Millman" <frank at chagford.com> wrote:
> > > 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.
> >
> > Then install a copy of the certificate on the client, that the
> > client can authenticate against.
> 
> I wanted to keep the legwork required to set up a new client down to a
> minimum. I was hoping that setting a pointer to the client software,
> and a pointer to a connection parameter, would be sufficient. If the
> fingerprint is an an adequate substitute for the full certificate, I
> would prefer it, as it is much smaller, and can easily form part of
> the connection parameter.

Your client probably installs data files, right? Then just install the
server's public key (or a fingerprint thereof) as one of your data
files, put a checksum system in place to make sure it isn't tampered
with. Or just embed the checksum in your program or a DLL - the server
won't be changing its certificate very often.

If the user wants to go change the fingerprint to let the program
connect to a fradulent server, well, you've got a lot worse problems
than SSL will ever help you fix. I suppose a virus could change it, but
that'd be a weird (and highly targeted) virus.

> >  You also want to generate a client
> > certificate to install on the server.  If there are multiple clients
> > you should make a CA rather than trying to keep track of self-signed
> > certificates.  If you're paranoid, you can scrounge some $20
> > obsolete laptop from ebay and dedicate it to use as a CA, never
> > letting it touch the internet (transfer files to and from it on
> > floppy disc).
> >
> 
> Both you and Sybren are insistent that this is a necessary step, but I
> confess I cannot see the need for it. The client is lightweight, and
> authenticates itself to the server using a user id and password. What
> is the worst that could go wrong?

For what it's worth, the Web does not authenticate clients (for the
most part anyway). The server is authenticated - its certificate is
checked against the root CA list. But clients aren't expected to have
their own certificates. I think that the only time you really need the
clients to have certificates is when the certificate *is* your
authentication (e.g., in OpenVPN). Likewise, SSH does not verify client
certificates (unless you're using PKA, but that's different).

Since the password is your authentication, I don't see any reason why
the client verifying the server's certificate against its "known good"
fingerprint, and then providing username/password as its credentials,
is any less secure than SSH with password/keyboard-interactive. Sure,
maybe not quite as secure as SSH w/ public key auth, but it's good
enough for a lot of stuff.

- Michael

-- 
mouse, n: a device for pointing at the xterm in which you want to type.
                -- Fortune