Thread: Re: SSL patch
Magnus Hagander <mha@sollentuna.net> writes:
> I've now finished "polishing off" my old SSL code, and rewritten it to work
> with 6.6 (current snapshot). Included is the patch against the cvs tree from
> Jul 22nd.
Cool. Secure connections are good.
> 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? 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.
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.
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...
regards, tom lane
On Fri, 23 Jul 1999, Tom Lane wrote:
> Magnus Hagander <mha@sollentuna.net> writes:
> > I've now finished "polishing off" my old SSL code, and rewritten it to work
> > with 6.6 (current snapshot). Included is the patch against the cvs tree from
> > Jul 22nd.
>
> Cool. Secure connections are good.
>
> > 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? 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.
>
> 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.
>
> 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...
I may be lost here, so forgive me ahead of time...but, if I'm reading
Magnus' email correctly, this just breaks backward compatibility...with
the change, pre-6.6 clients would not be able to talk to a 6.6 server, but
6.7 and 6.6 would be compatible?
If this is correct, I've lost what the problem is here, except that, if
this is the case, such a change shoudl signal a new major number release,
vs just minor...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> I may be lost here, so forgive me ahead of time...but, if I'm reading
> Magnus' email correctly, this just breaks backward compatibility...with
> the change, pre-6.6 clients would not be able to talk to a 6.6 server, but
> 6.7 and 6.6 would be compatible?
As long as we don't change it again for 6.7, yeah ... but that doesn't
seem like the point.
What I'm concerned about is that we'd have neither compatibility between
existing clients and new servers nor existing servers and new clients.
When we changed the protocol for 6.4, we got quite a bit of flak about
6.4 clients not talking to old servers. But that was just a one-way
whammy: a 6.4 server would still talk to old clients. This change is
gonna be a double whammy.
I think we at least need to find a way to have new servers be able to
talk to old clients. Otherwise, it'll be *very* difficult to upgrade
to 6.6 at large installations; you'd have to change all the clients
simultaneously with the server. Those clients aren't necessarily all
on the same machine, and some may not even be under the db admin's
direct control. It looks like a recipe for major headaches to me.
regards, tom lane
Seems like a trigger for a 7.0 release ... last I understood, major
releases generally signified major protocol changes, as well as API...
On Fri, 23 Jul 1999, Tom Lane wrote:
> The Hermit Hacker <scrappy@hub.org> writes:
> > I may be lost here, so forgive me ahead of time...but, if I'm reading
> > Magnus' email correctly, this just breaks backward compatibility...with
> > the change, pre-6.6 clients would not be able to talk to a 6.6 server, but
> > 6.7 and 6.6 would be compatible?
>
> As long as we don't change it again for 6.7, yeah ... but that doesn't
> seem like the point.
>
> What I'm concerned about is that we'd have neither compatibility between
> existing clients and new servers nor existing servers and new clients.
> When we changed the protocol for 6.4, we got quite a bit of flak about
> 6.4 clients not talking to old servers. But that was just a one-way
> whammy: a 6.4 server would still talk to old clients. This change is
> gonna be a double whammy.
>
> I think we at least need to find a way to have new servers be able to
> talk to old clients. Otherwise, it'll be *very* difficult to upgrade
> to 6.6 at large installations; you'd have to change all the clients
> simultaneously with the server. Those clients aren't necessarily all
> on the same machine, and some may not even be under the db admin's
> direct control. It looks like a recipe for major headaches to me.
>
> regards, tom lane
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org