Re: [HACKERS] SSL patch
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] SSL patch |
Дата | |
Msg-id | m118iHO-0003kvC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | RE: [HACKERS] SSL patch ("Ansley, Michael" <Michael.Ansley@intec.co.za>) |
Список | 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 по дате отправления: