Thread: 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

> 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. 

So your concern is that the client will send hashed password as
cleartext before finding out it has to do SSL?  Doesn't the client do
SSL and then send the SSL request to the server?  Why do we have to have
clients who use SSL sending non-SSL requests to the server?  Let them
fail if they do that.  If you want to force SSL from certain hosts, put
that in hba_conf, and only accept SSL from those?  I am really lost on
the problem here.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Magnus Hagander <mha@sollentuna.net> writes:
> 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.

Actually, the StartupPacket does *not* contain a password.  But it does
contain a valid database name and user name, which might be useful
information to an attacker, so I agree it would be good to protect it.

> Just to 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. 

Right.  My feeling is that we must make it possible for a 6.6 server to
accept connections from 6.5 (and earlier) clients, or the upgrade will
be too painful at large sites.

> 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.

Not if the 6.6 client is smart about recovering from a connection
failure.  It could work like this:
Client opens connectionClient sends SSL negotiation packet6.5 server (or SSL-less 6.6 server) sends back error msg
andcloses connectionClient says "oh well", opens a new connection, and    proceeds with non-secure connection protocol
 

(Of course, if the client only wanted a secure connection, it'd give up
instead of making the second connection attempt.)  This'd be a little
bit inefficient for new clients talking to old servers, but that doesn't
seem like it is a fatal objection --- in the other three cases there
is no extra overhead.

In the case where the server does have SSL capability, it accepts the
SSL packet, then the SSL negotiation is completed, and finally the
usual sort of StartupPacket is sent and the connection proceeds.

Of course, if the client does not want to use a secure connection, it
just opens the connection and sends a StartupPacket to begin with.

The only dubious assumption I can see in this is that the server has to
be able to distinguish an initial SSL negotiation packet from a
StartupPacket (and from a CancelRequestPacket).  We should ensure that
that is true by prefixing an identifying word to the normal contents of
an SSL packet.  Or, if it seems easiest, we could simply have that
initial client message consist *only* of a packet that means
"BeginSSLProtocol", and then the server side is the one that actually
starts the SSL negotiation.  That is almost like your current patch ---
the critical differences are that the initial client message for an SSL
connection has to be set up so that an old server will reject it
cleanly, and the client has to be prepared to retry if that happens.

I think I prefer having the client's first message include the first
step of SSL negotiation if possible, since that would save one
packet transfer during the setup process.  But if it's too hard to
make the SSL libraries play that way, we don't have to.

In any case, the initial client message for a non-SSL connection should
be a plain StartupPacket, and for an SSL connection it must be something
that an old server will refuse.  That means we want the first 8 bytes to
be a packet length count and then a word that does not look like any
acceptable protocol version number.  (Compare the way that
CancelRequestPackets are recognized.)  The data payload of the packet
would either be the initial SSL negotiation data, or empty if you decide
that the server must send the initial SSL message.

> 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).

You'll still have an API addition, no?  Something to set the SSL
connection option as "do not use SSL", "must use SSL or fail", or "use
SSL if server supports it".  The last is a reasonable default if the
client doesn't specify, but the client must be able to specify.  I guess
this would only be possible via a conninfo string...
        regards, tom lane

I wrote:
> [ a bunch of stuff ]

After looking into this morning's patches digest, I see that half of
this already occurred to you :-).

I'd still suggest extending the client to fall back to non-SSL if the
server rejects the connection (unless it is told by the application
that it must make an SSL connection).  Then there's no compatibility
problem at all, even for mix-and-match SSL-enabled and not-SSL-enabled
clients and servers.
        regards, tom lane

On Sat, 24 Jul 1999, Tom Lane wrote:

> Magnus Hagander <mha@sollentuna.net> writes:

> > Just to 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. 
> 
> Right.  My feeling is that we must make it possible for a 6.6 server to
> accept connections from 6.5 (and earlier) clients, or the upgrade will
> be too painful at large sites.

But, we've had protocol changes before that breaks backward
compatibility...why is this all of a sudden a problem?  As long as this is
a "known" issue for an upgrade (something for the 'migrating to...'
section of the HISTORY file), I personally see no reason why the protocol
can't mature/change...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

> > Right.  My feeling is that we must make it possible for a 6.6 server to
> > accept connections from 6.5 (and earlier) clients, or the upgrade will
> > be too painful at large sites.
> 
> But, we've had protocol changes before that breaks backward
> compatibility...why is this all of a sudden a problem?  As long as this is
> a "known" issue for an upgrade (something for the 'migrating to...'
> section of the HISTORY file), I personally see no reason why the protocol
> can't mature/change...

No reason to change the protocol when we don't need to.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> But, we've had protocol changes before that breaks backward
>> compatibility...why is this all of a sudden a problem?

> No reason to change the protocol when we don't need to.

The point is that we *do not have to* break backwards compatibility to
add this feature, and indeed hardly anything would be gained by breaking
compatibility.  See subsequent messages from myself and Magnus.
        regards, tom lane

> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> But, we've had protocol changes before that breaks backward
> >> compatibility...why is this all of a sudden a problem?
> 
> > No reason to change the protocol when we don't need to.

What I meant is that there is reason to break compatibility when we
don't need to.  Magnus seems like he has addressed this already.

> 
> The point is that we *do not have to* break backwards compatibility to
> add this feature, and indeed hardly anything would be gained by breaking
> compatibility.  See subsequent messages from myself and Magnus.
> 
>             regards, tom lane
> 


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026