httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Hudson <...@cryptsoft.com>
Subject Re: Discussions about SSL/TLS possibly concerning Apache
Date Wed, 12 Feb 1997 11:34:10 GMT
According to Jason Clary:
> Since almost every server in existence can handle an additional
> negotiation before getting started, we were trying to get them
> to regularize on shttp instead of https in the hopes that a
> version will be available that runs on port 80 that can negotiate
> multiple protocols..
> Something along the lines of sending a crypt command prior to the GET.

    I proposed this originally (back before Apache existed even) and basically
the argument from Netscape at the time was that it introduces a potential
weakness in that the user may end up thinking that the session is encrypted
when it is negotiated down to not being encrypted by the server.
    I responded by saying that all you have to do is make the client check
to make sure it is encrypted if that is what the user wants and then you have
exactly the same situation in terms of knowing that encryption is operational.
    This was rejected and basically the statement was that a new port for
each protocol was the official Netscape position and they would ask for ports
and get them as they implemented each protocol into a product. 
    I asked for allocation of a whole pile of ports to force the issue to 
be discussed in a sane manner ... either all the ports that need encryption
should be allocated or the existing ones left at just https and everything
else should be done dynamically. (I explained this in private email to the
people proposing a few extra ports and the larger list of ports got added).
    Introducing a TCP option to denote encryption is a nice engineering 
option but totally impractical. 
    Adding in a SOCKS like proxy to do negotiation with before connecting
is one approach but not to my liking ... 

    Extending each protocol's existing negotiation to add SSL (or TLS or
whatever) support is the better (and more pragmatic) approach IMHO. However
we need the major players to commit to this approach. The process of getting
a draft-ietf document together and through the system into an RFC is painful
(we had fun getting the FTP one together and the IETF task force is still
no happy with what was written in a number of areas).

    One of the issues with http/https in terms of extending the http protocol
to negotiate encryption is you have to do this *before* sending any additional
data to preserve the existing privacy of what the client is fetching. I
proposed using a WWW-Authenticate option to trigger SSL negotation and it
was shot down for this reason. I still think that approach has a lot of
merit myself for certain things ... but I do value the privacy benefits 
of encrypted http.
	
Tim.


Mime
View raw message