Skip site navigation (1) Skip section navigation (2)

SSL Support

From: dom(at)happygiraffe(dot)net (Dominic Mitchell)
To: pgsql-hackers(at)postgresql(dot)org
Subject: SSL Support
Date: 2004-09-21 07:24:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I've just spent a while this afternoon attempting to get SSL support
working.  It appears to be lacking in a few areas, foremost
documentation.  I've got a patch filling in the missing pieces for the
server side, but I am unsure where I should document the client side
bits (~/.postgresql/root.crt and friends).  I am also unsure of the
procedures for submitting patches; is it ok to just send to hackers?

Going through the code I spotted what appear to be problems.  Although
I'm not familiar with the internals and this is only a cursory glance
through the code.

* src/backend/libpq/be-secure.c

  In initialize_SSL(), we call SSL_CTX_set_verify(), but we don't pass
  in the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag.  This means that a client
  can present no certificate and still get access to the server.

  There's nothing that gets logged to say that an SSL connection was
  made.  This would be useful for testing.  Something like logging the
  connection as ""?

* src/interfaces/libpq/fe-secure.c

  In initialize_SSL(), we call SSL_CTX_set_verify_depth(SSL_context, 1).
  This should probably be a configurable item.  I /think/ it might be
  stopping me from successfully verifying the server certificate is
  signed by the CA listed in my client's root.crt file, but I'm not

  There is no ability to indicate failure to read the client root.crt.
  This is because it's just magically turned on by the presence of that
  file.  Perhaps it should be another PQconnectdb() option?

  In open_client_SSL(), the call to SSL_get_verify_result() is commented
  out.  This means that crucial things such as the validity of the
  certificate of the server you are connecting to is not checked.  So
  the client will happily connect to an expired certificate.

  In open_client_SSL() again, the call to verify that the CN of the
  certificate is the same as the hostname you've connected to is
  commented out.  So you have no idea whether or not you've connected to
  the right server.

* [both files]

  Having hard coded file names is a bit of a pain.  Particularly so for
  the client, as it means that two users of libpq cannot use different
  certificates.  I admit this is unlikely, but still.  Of course, it
  would be slightly better if documented.

I'm happy to have a go at fixing these problems, if that's acceptable.
Unfortunately the SSL support isn't really usable for me without them.



pgsql-hackers by date

Next:From: Peter EisentrautDate: 2004-09-21 08:17:51
Subject: Re: SSL Support
Previous:From: Shachar ShemeshDate: 2004-09-21 06:55:25
Subject: Re: No parameters support in "create user"?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group