From: | "Jason M(dot) Felice" <jfelice(at)cronosys(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [INTERFACES] First draft of new FE/BE protocol spec posted for comments |
Date: | 2003-04-16 13:12:50 |
Message-ID: | 20030416131250.GB5273@argo.eraserhead.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-interfaces |
Kudos on the spec! Some feedback:
46.2.3 - Is bind required when the portal has no parameters? It would be
useful to be able to avoid the bind message in this case.
46.2.9 - SSL - Is there any way to detect the start of an SSL session sooner?
This is not for security purposes, but I currently have this scenario:
Win/ODBC client <------> fw machine <=========> database server
Both fw machine and database server have stunnel running on them, since
the protocol start up requirements of PostgreSQL prevent me from just having
stunnel connect to the database service.
I'm not saying don't support the old method as well. A quick look at rfc2246
shows that the client sends the TLS/SSL hello message first, meaning that we
could detect it. Since the client is also responsible for sending the first
message anyway, we just need to check if the first bytes indicate a TLS
hello or a PostgreSQL startup message. If we got a TLS hello, start
cryptographic negotiations by stuffing bytes back into a buffer. IIRC,
OpenSSL stream abstraction will allow us to do this easily. Otherwise,
continue as before. If we receive an SSLRequest while SSL encrypted,
respond N. (I'm no cryptographer, but I've seen a couple of instances where
double-encryption is less secure than single-encryption.)
This would allow me to get rid of the stoopid stunnel on the database server,
and provide an excellent general case for encrypting connections from
non-SSL-aware clients.
-Jay 'Eraserhead' Felice
On Wed, Apr 16, 2003 at 12:44:52PM +0100, Patrick Welche wrote:
> On Tue, Apr 15, 2003 at 07:08:30PM -0400, Tom Lane wrote:
> > I have committed a first-draft revision of the FE/BE protocol document;
> > you can read it at
> > http://candle.pha.pa.us/main/writings/pgsql/sgml/protocol.html
> > or in a few hours at
> > http://developer.postgresql.org/docs/postgres/protocol.html
> > I'd appreciate it if people would look it over for both presentation
> > and content.
>
> Just showing my ignorance: I read 46.2.3 Extended Query, and wondered "What
> is a portal?" (portal == cursor?)
> also noted that SQL EXECUTE (prepared statement) != Execute (portal)
>
> and in 46.3. Message Data Types, reading "There is no predefined limit on
> the length of a string that can be returned by the backend." one might say
> Oh no! but of course you know what it's maximum size is by then, as you know
> the length of the response which contains the string..
>
> Cheers,
>
> Patrick
>
From | Date | Subject | |
---|---|---|---|
Next Message | Shridhar Daithankar | 2003-04-16 13:13:33 | One more question regarding dblink |
Previous Message | Shridhar Daithankar | 2003-04-16 13:00:33 | DBLink cursors |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-04-16 13:46:36 | Re: [GENERAL] Problem about pgsql's column alias |
Previous Message | Patrick Welche | 2003-04-16 11:44:52 | Re: [INTERFACES] First draft of new FE/BE protocol spec posted for comments |