Re: SSL patch

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

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

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

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, Pennsylvania 19026

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 connection
Client sends SSL negotiation packet
6.5 server (or SSL-less 6.6 server) sends back error msg
and closes connection
Client 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 Saturday, July 24, 1999 5:37 PM, Tom Lane [SMTP:tgl@sss.pgh.pa.us] wrote:

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.

That sounds like a good thing to do.

As it is right now, it should work in all combinations except a 6.6 client
compiled with SSL support connecting to a pre-6.6 server. It already
falls-back if the server is 6.6 (without SSL support). And the 6.6 client
compiled without SSL works.

There is not yet a way in the client to specify that SSL connection is
required (it can be specified on the server). I'm planning to put that in,
but I thought it would be good to get the "base code" approved first - which
proved to be a good thing :-)

I'll see if I can wrap something up before I leave on vacation (leaving
pretty soon, be gone about a week). Not sure I'll make it, though. Should I
do this as a patch against what I have now, or keep sending in "the one big
patch"?

//Magnus

Magnus Hagander <mha@sollentuna.net> writes:

As it is right now, it should work in all combinations except a 6.6 client
compiled with SSL support connecting to a pre-6.6 server. It already
falls-back if the server is 6.6 (without SSL support). And the 6.6 client
compiled without SSL works.

Actually, it shouldn't matter whether the server is 6.6-without-SSL
or pre-6.6. At least in the way I envisioned it, they'd act the same.

There is not yet a way in the client to specify that SSL connection is
required (it can be specified on the server). I'm planning to put that in,
but I thought it would be good to get the "base code" approved first - which
proved to be a good thing :-)
I'll see if I can wrap something up before I leave on vacation (leaving
pretty soon, be gone about a week). Not sure I'll make it, though. Should I
do this as a patch against what I have now, or keep sending in "the one big
patch"?

I don't think anyone has applied your patch yet, so why don't you just
resubmit the whole thing after cleaning up the loose ends.

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

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

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, Pennsylvania 19026

As it is right now, it should work in all combinations except a 6.6

client

compiled with SSL support connecting to a pre-6.6 server. It already
falls-back if the server is 6.6 (without SSL support). And the 6.6

client

compiled without SSL works.

Actually, it shouldn't matter whether the server is 6.6-without-SSL
or pre-6.6. At least in the way I envisioned it, they'd act the same.

Not quite.
The 6.6-without-SSL still knows about the NEGOTIATE_SSL_CODE packet that is
sent, and can respond "No, I can't do SSL". The pre-6.6 does not know about
the existance of this packet, and will thus respond with "Unsupported
Frontend Protocol" (since it's a normal StartupPacket with the version
number set to something very large (like the cancel request was
implemented)).

//Magnus

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

Magnus Hagander <mha@sollentuna.net> writes:

Actually, it shouldn't matter whether the server is 6.6-without-SSL
or pre-6.6. At least in the way I envisioned it, they'd act the same.

The 6.6-without-SSL still knows about the NEGOTIATE_SSL_CODE packet that is
sent, and can respond "No, I can't do SSL". The pre-6.6 does not know about
the existance of this packet, and will thus respond with "Unsupported
Frontend Protocol" (since it's a normal StartupPacket with the version
number set to something very large (like the cancel request was
implemented)).

OK, the point being that then the client can either break the connection
(if it doesn't want to do an insecure connection) or send a
StartupPacket to continue with an insecure connection. I agree this
will be a little quicker than tearing down the connection and starting
a new one, which is what must happen in the case of an old server.

But you could save some code on both sides if you just made the
teardown/new connection behavior the only path for falling back to
non-SSL. I'm not sure that SSL-enabled-client-talking-to-6.6-but-
not-SSL-enabled-server will be a sufficiently common scenario to
justify a lot of extra code to make it a tad faster. You'd expect
that most installations will have SSL at the server if they have
it anywhere.

If it's only a small amount of extra code then it doesn't matter,
of course. I'm just dubious that it's worth taking extra care
for that case when you are going to have the other case anyway.

regards, tom lane

Actually, it shouldn't matter whether the server is 6.6-without-SSL
or pre-6.6. At least in the way I envisioned it, they'd act the same.

The 6.6-without-SSL still knows about the NEGOTIATE_SSL_CODE packet that

is

sent, and can respond "No, I can't do SSL". The pre-6.6 does not know

about

the existance of this packet, and will thus respond with "Unsupported
Frontend Protocol" (since it's a normal StartupPacket with the version
number set to something very large (like the cancel request was
implemented)).

OK, the point being that then the client can either break the connection
(if it doesn't want to do an insecure connection) or send a
StartupPacket to continue with an insecure connection. I agree this
will be a little quicker than tearing down the connection and starting
a new one, which is what must happen in the case of an old server.

But you could save some code on both sides if you just made the
teardown/new connection behavior the only path for falling back to
non-SSL. I'm not sure that SSL-enabled-client-talking-to-6.6-but-
not-SSL-enabled-server will be a sufficiently common scenario to
justify a lot of extra code to make it a tad faster. You'd expect
that most installations will have SSL at the server if they have
it anywhere.

If it's only a small amount of extra code then it doesn't matter,
of course. I'm just dubious that it's worth taking extra care
for that case when you are going to have the other case anyway.

Well. There is almost no extra code. The code has to be in place anyway, to
deal with those clients that do support SSL. It's just a matter of the
server sending a single character (a 'N' to say normal, non-SSL connection)
to the client after receiving the special packet that it knows about. It's
just:
#ifdef USE_SSL
SSLok = 'S';
#else
SSLok = 'N';
#endif

SSLok is then sent to the client. This code is only executed if the client
first asked for SSL - if it's a non-SSL client, this whole phase is skipped.
All the rest of the code is shared between the SSL and the non-SSL case.

I'll post a patch to the patches-list that makes the client work with a
pre-6.6 server in a minute. The noticable thing being that each time this
client tries to connect, the server logs an "Unsupported frontent protocol"
message. The client will then tear down it, and the connectDB() function
will call itself while being instructed to run with the pre-6.6 protocol. It
works fine for me to connect to a 6.4.2 server.

//Magnus

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, Pennsylvania 19026

Why does anything need to be broken if a different port is used? Same way
as web browsers use 80 for clear http, and 443 (by default) for SSL. But a
server cannot dish up http and https on the same port. Then the whole
compatibility issue falls away. Think of it as using 'pgsql' for clear
connections, and 'pgsqls' for SSL connections. This way, a post-6.6 client
can still connecct to a pre-6.6 server, using 'pgsql', a pre-6.6 client can
connect to a post-6.6 server using 'pgsql', and a post-6.6 client can
connect to a post-6.6 server using 'pgsql', or 'pgsqls'.

Or is there an issue using different ports?

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

"Ansley, Michael" wrote:

Why does anything need to be broken if a different port is used? Same way
as web browsers use 80 for clear http, and 443 (by default) for SSL. But a
server cannot dish up http and https on the same port.

Actually you are free to use HTTPS on 80 and HTTP on 443 if you wish.

There is nothing at the protocol level that makes it impossible.
At least on Apache-mod_ssl you have to explicitly disable non-SSL
connections on 443 if you don't want them

Then the whole
compatibility issue falls away. Think of it as using 'pgsql' for clear
connections, and 'pgsqls' for SSL connections. This way, a post-6.6 client
can still connecct to a pre-6.6 server, using 'pgsql', a pre-6.6 client can
connect to a post-6.6 server using 'pgsql', and a post-6.6 client can
connect to a post-6.6 server using 'pgsql', or 'pgsqls'.

Or is there an issue using different ports?

Not to scare anyone away (I like crypto !;), but isn't it illegal to
have SSL
in an exportable product in US.

I guess this should be kept in a separate patch distributed from an
non-US site
until US government wisens up.

I'd really hate to have to fill some 'us-citizen verificatiohn form' to
download
the latest snapshot.

-----
Hannu

Hannu wrote:

Actually you are free to use HTTPS on 80 and HTTP on 443 if you wish.

I understand this; the point that I was trying to make was that they run on
different ports. I don't think that it's possible to run both http and
https on the same port at the same time on the same server, and I think that
we should take the cue.

It's a concept that people already understand.

MikeA

"Ansley, Michael" wrote:

Hannu wrote:

Actually you are free to use HTTPS on 80 and HTTP on 443 if you wish.

I understand this; the point that I was trying to make was that they run on
different ports. I don't think that it's possible to run both http and
https on the same port at the same time on the same server, and I think that
we should take the cue.

It is possible unless you mean that the very same connection is both
http and https ;)

The decision to use either http or https is done et _each_ connection
setup (at each http(s) request).
So http://samehost.com:443/ and https://samehost.com/ will connect to
samehost.com port 443, only the latter user SSL.

It's a concept that people already understand.

Agreed, but there is nothing at the protocol level that forces them to
be
separate.

-------------
Hannu

Thus spake Hannu Krosing

Not to scare anyone away (I like crypto !;), but isn't it illegal to
have SSL
in an exportable product in US.

I guess this should be kept in a separate patch distributed from an
non-US site
until US government wisens up.

The PostgreSQL server is in Canada. There may still be some issues but
last time I checked we weren't a US state yet.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

At 06:24 26/07/99 -0400, D'Arcy" "J.M." Cain wrote:

Thus spake Hannu Krosing

Not to scare anyone away (I like crypto !;), but isn't it illegal to
have SSL
in an exportable product in US.

I guess this should be kept in a separate patch distributed from an
non-US site
until US government wisens up.

The PostgreSQL server is in Canada. There may still be some issues but
last time I checked we weren't a US state yet.

Even if there are problems, I believe it's OK to export PostgreSQL with
options for SSL support, so long as you don't export SSL.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

Hannu wrote:

Actually you are free to use HTTPS on 80 and HTTP on 443 if you wish.

I understand this; the point that I was trying to make was that they run on
different ports. I don't think that it's possible to run both http and
https on the same port at the same time on the same server, and I think that
we should take the cue.

It's a concept that people already understand.

I would prefer to have the SSL connections on a different
port. Doing the mentioned try and error from a 6.6 client to
connect to a 6.5 server would cause a log message for every
connect. It's hard to find really important log messages
then.

Better have a new PGPORT_V7 variable that contains some more
information for a past 6.5 client. It could look like this:

ssl=5433,raw=5432 Try SSL connect on 5433 and if fails, try
insecure connection on 5432.

ssl=5432 Try SSL connect on 5432 only and bail out
if it fails.

raw=5432 Use insecure connection allways on 5432.

This way, the semantic of the PGPORT variable doesn't change,
so using old and new clients from within the same login
doesn't cause problems.

Beeing able to configure a particular login explicitly to use
an insecure connection is IMHO important. Have the database
and a WEB server doing much CGI on the same server. Why
crypting local connections, even if they go through TCP (as
PHP allways does)? The cryptography overhead isn't that
small.

Well - root could listen on the lo device, but since root
could easily patch passwd(1) to send him mail if anyone
changes his password, that's not a real drawback for me.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:

Why does anything need to be broken if a different port is used?

That was the quick-and-dirty answer that I suggested to begin with, but
Magnus objected on the grounds that it would be a nontransparent change
for *users* of Postgres; anyplace that knows what port it is supposed
to connect to would have a problem. I think he has a good point.
Pushing the conversion headaches out of our bailiwick does not mean that
there are no conversion headaches.

The solution that we arrived at does not break compatibility nor require
an additional port --- it will just mean a slightly slower connection
process when an SSL-using client tries to connect to a non-SSL-capable
server. I think that's OK, since that scenario is probably the least
common of the four possible combinations. (And if you're really worried
about a few extra millisec of startup time, the client-side library will
accept a connect option that tells it not to try the SSL connection...)

regards, tom lane

Philip Warner wrote:

At 06:24 26/07/99 -0400, D'Arcy" "J.M." Cain wrote:

Thus spake Hannu Krosing

Not to scare anyone away (I like crypto !;), but isn't it illegal to
have SSL
in an exportable product in US.

I guess this should be kept in a separate patch distributed from an
non-US site
until US government wisens up.

The PostgreSQL server is in Canada. There may still be some issues but
last time I checked we weren't a US state yet.

Good to hear, I was afraid of them being more or less the same
crypto-wise.

Even if there are problems, I believe it's OK to export PostgreSQL with
options for SSL support, so long as you don't export SSL.

Let's hope so. In US that would be a 'crypto hook' and legally as bad as
real crypto.

---------
Hannu

At 01:37 27/07/99 +0300, Hannu Krosing wrote:

Philip Warner wrote:

At 06:24 26/07/99 -0400, D'Arcy" "J.M." Cain wrote:

Thus spake Hannu Krosing

Not to scare anyone away (I like crypto !;), but isn't it illegal to
have SSL
in an exportable product in US.

I guess this should be kept in a separate patch distributed from an
non-US site
until US government wisens up.

The PostgreSQL server is in Canada. There may still be some issues but
last time I checked we weren't a US state yet.

Good to hear, I was afraid of them being more or less the same
crypto-wise.

Even if there are problems, I believe it's OK to export PostgreSQL with
options for SSL support, so long as you don't export SSL.

Let's hope so. In US that would be a 'crypto hook' and legally as bad as
real crypto.

That's a worry - maybe it would be worth looking at the approach of Apache.
They have a general 'module' concept, and one of the available modules adds
SSL. Both mod_ssl, and opensll are available overseas.

Perhaps the same idea could be used in PosgreSQL?

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

On Tue, 27 Jul 1999, Philip Warner wrote:

At 01:37 27/07/99 +0300, Hannu Krosing wrote:

Philip Warner wrote:

At 06:24 26/07/99 -0400, D'Arcy" "J.M." Cain wrote:

Thus spake Hannu Krosing

Not to scare anyone away (I like crypto !;), but isn't it illegal to
have SSL
in an exportable product in US.

I guess this should be kept in a separate patch distributed from an
non-US site
until US government wisens up.

The PostgreSQL server is in Canada. There may still be some issues but
last time I checked we weren't a US state yet.

Good to hear, I was afraid of them being more or less the same
crypto-wise.

Even if there are problems, I believe it's OK to export PostgreSQL with
options for SSL support, so long as you don't export SSL.

Let's hope so. In US that would be a 'crypto hook' and legally as bad as
real crypto.

That's a worry - maybe it would be worth looking at the approach of Apache.
They have a general 'module' concept, and one of the available modules adds
SSL. Both mod_ssl, and opensll are available overseas.

Perhaps the same idea could be used in PosgreSQL?

I like this idea, does Postgresql (I'm new around here) have a compression
option for slow links? If not the same interfaces that support SSL could
also support a compressed stream, if someone were to invent one. That way
you have a more generalized interface that can't really be considered a
"crypto hook"

This is a big issue for us (we use Sybase at work) going over 56k frame
relay. We have pretty powerful machines at the clients but the network is
a bottleneck. A compressed stream would be very cool.

Brian