Thread: RE: [HACKERS] RE: [INTERFACES] Re: SSL patch
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 >> > compatibility. See subsequent messages from myself and Magnus. >> > >> > regards, tom lane >> >
"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
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 |/
"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