RE: [INTERFACES] Re: SSL patch

> > Unfortunatly, in order to allow for negotiated SSL, this
> patch breaks the
> > current protocol (meaning old clients will not work with
> the new server, and
> > the other way around). I felt it was better to break this
> here, than to
> > break the frontend API (which would otherwise have been required).
>
> This is *not* cool. Breaking both clients and servers, whether they
> actually support SSL or not, is a bit much, don't you think?
Well. Yeah, I do.

> Especially
> when the way you propose to do it makes it impossible for a server to
> support both old and new clients: by the time the server finds out the
> client's protocol version, it's already done something incompatible
> with old clients.
>
> I think there must be some way of signaling SSL support capability
> without making a backwards-incompatible change in the startup
> protocol.
> At a minimum an SSL-enabled server must be able to accept connections
> from pre-SSL clients.
Well. The problem is that the client sends the StartupPacket without reading
anything at all from the server, which means it is too late to do SSL
negotiation after the StartupPacket. It contains the password (possibly in
clear-text), which would be one of the most important things to protect. So
I'm pretty sure that the negotiation has to take place _before_ the
StartupPacket. And since the StartupPacket is the very first thing that is
sent, it might be hard.
Just co clearify: the SSL-enabled server still accepts 6.6 clients that are
compiled without SSL support, but it will not accept from 6.5 clients, as it
is now.

One possibility would be that the client sent a negotiation packet _before_
it sent the startuppacket. It would be a little bit weird to have this
negotiation initiated from the client, but perhaps possible. OTOH, this will
break compatibility in the way that a 6.6 client will not be able to talk to
a 6.5 server. So I dunno if it's worth it.

Then it could be something like:

Client->Server 'S' if SSL support, 'N' otherwise.
Server->Client picks 'S' or 'N' based on what both can do.
If it receives anything other than 'S' or
'N', assums <6.6 client,
and sees it as a StartupPacket.
<if SSL, then negotiate SSL>
Client->Server StartupPacket

Is this perhaps better? It's pretty hard to get it into the server to accept
a packet _or_ a single byte as first input on the connection - as it is now,
it goes directly into the special packet handling routines, which only
handles packets. But it might be possible.

Question is - is it worth it? Are there perhaps any other changes planned
that will break this compatibility anyway?

> If nothing better comes to mind, we could have SSL-capable servers
> listen at two port addresses, say 5432 for insecure connections and
> 5433 for secure ones. But there's probably a better way.
I had it set for that from the beginning, but didn't like it. The way I had
it done then broke the client API, which I considered even worse (AKA the
client had to specify to libpq if it was to use SSL or not, which meant that
the interface to PQsetdb was changed - not just a simple upgrade to the new
libpq was possible).

It could be possible to have it listen on two ports, one that does not
negotiate and one that does, purely for backwards compatibility. But that
does not look like a very good solution either, since it would require
continued support for two different protocols, with all that comes with
that.

> BTW, it should be possible for the dbadmin to configure a server to
> accept *only* secured connections, perhaps from a subset of
> users/hosts;
> that would take a new column in pg_hba.conf. Didn't look at
> your patch
> closely enough to see if you already did that...
It is. If you start it up with "-is", it will allow only secure connections.
You can also use the class "hostssl" in pg_hba.conf to configure it based on
hosts. So you can have e.g.
Once the main code is in there, it should also be possible to add
client-certificate-based authentication.

//Magnus