Re: [HACKERS] SSL patch - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] SSL patch
Date
Msg-id m118iHO-0003kvC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to RE: [HACKERS] SSL patch  ("Ansley, Michael" <Michael.Ansley@intec.co.za>)
List pgsql-hackers
>
> 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) #

pgsql-hackers by date:

Previous
From: "D'Arcy" "J.M." Cain
Date:
Subject: Re: [SQL] database design SQL prob.
Next
From: "Ansley, Michael"
Date:
Subject: Max query string length