Thread: RE: [HACKERS] SSL patch

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.

MikeA

"Ansley, Michael" wrote:
> 
> 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 is possible unless you mean that the very same connection is both 
http and https ;)

The decision to use either http or https is done et _each_ connection 
setup (at each http(s) request). 
So http://samehost.com:443/ and https://samehost.com/ will connect to 
samehost.com port 443, only the latter user SSL.

> 
> It's a concept that people already understand.

Agreed, but there is nothing at the protocol level that forces them to
be 
separate.

-------------
Hannu

>
> 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) #