Thread: SSL (patch 3)

Third patch - adds client verification of server certificate.
This has some POSIX-isms that need to be expanded for Windows
and Mac clients, and identifies (but does not fix) a problem
on the backend that could be used for "denial of service"
attacks on the current backend.

Bear

Bear Giles writes:

> Third patch - adds client verification of server certificate.
> This has some POSIX-isms that need to be expanded for Windows
> and Mac clients, and identifies (but does not fix) a problem
> on the backend that could be used for "denial of service"
> attacks on the current backend.

What happens if I don't want to use this feature and/or I don't have the
certificates set up?  Why are errors from getpwuid() thrown away, isn't
that a risk?

POSIX-isms in SSL code are OK.  I don't think WIN32 handles SSL yet.
Please use MAXPGPATH to size buffers for file names.

What exactly is the "problem" you identify?  I couldn't make it out.

--
Peter Eisentraut   peter_e@gmx.net

> Bear Giles writes:
>
> > Third patch - adds client verification of server certificate.
> > This has some POSIX-isms that need to be expanded for Windows
> > and Mac clients, and identifies (but does not fix) a problem
> > on the backend that could be used for "denial of service"
> > attacks on the current backend.
>
> What happens if I don't want to use this feature

Use SSH tunnels.  The code is written with the presumption that
anyone using SSL wants a secure session, and that includes
confidentiality, message integrity and endpoint authentication.
If they just want confidentiality, SSH tunnels are a lot easier
to set up.

> and/or I don't have the certificates set up?

If they want secure sessions, they'll invest the time in setting
up the certificates.

> Why are errors from getpwuid() thrown away, isn't
> that a risk?

My code keeps going back and forth on that.  There's a lot less
risk than usual because the argument is from getuid(), not something
like a file ownership which can contain an arbitrary number.

Then again, it's possible for root to setuid() to a number that
doesn't have an /etc/passwd entry so there's a remote risk of
failure.

> Please use MAXPGPATH to size buffers for file names.

Legacy code again.

> What exactly is the "problem" you identify?  I couldn't make it out.

If the SSL negotiations don't complete for any reason, the server
hiccups.  This would tend to annoy other users who see their connections
drop, especially if some jerk is running a program that retries to
establish a connection every 10 seconds or so.

Bear

Bear Giles <bgiles@coyotesong.com> writes:
>> What happens if I don't want to use this feature

> Use SSH tunnels.  The code is written with the presumption that
> anyone using SSL wants a secure session, and that includes
> confidentiality, message integrity and endpoint authentication.
> If they just want confidentiality, SSH tunnels are a lot easier
> to set up.

Um ... I've taken that tack in the past, and every time I have, other
people have asserted that SSH tunnels are hard or impossible to set up
in their environments (eg, they're running Windows clients, don't want
to grant users shell accounts on the db server, etc).  Got to listen
to the customers.

I think it would be a mistake to make usage of SSL for simple comsec
significantly harder to set up than it is now.  People who want to have
authentication and so on can be told how to do it right, but don't force
your views of the right way to do things on everyone.

>> What exactly is the "problem" you identify?  I couldn't make it out.

> If the SSL negotiations don't complete for any reason, the server
> hiccups.  This would tend to annoy other users who see their connections
> drop, especially if some jerk is running a program that retries to
> establish a connection every 10 seconds or so.

Isn't that fixed as of 7.2?  We don't do SSL negotiations in the
postmaster anymore.

            regards, tom lane