Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2] (may be forged)) by hub.org (8.9.3/8.9.3) with ESMTP id MAA10766 for ; Fri, 23 Jul 1999 12:25:11 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA14828; Fri, 23 Jul 1999 12:23:45 -0400 (EDT) To: Magnus Hagander cc: pgsql-interfaces@hub.org, pgsql-hackers@postgreSQL.org Subject: Re: SSL patch In-reply-to: Your message of Fri, 23 Jul 1999 10:55:49 -0400 (EDT) <199907231455.KAA96979@hub.org> Date: Fri, 23 Jul 1999 12:23:44 -0400 Message-ID: <14826.932747024@sss.pgh.pa.us> From: Tom Lane Magnus Hagander 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