httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Clary <>
Subject Re: Discussions about SSL/TLS possibly concerning Apache
Date Wed, 12 Feb 1997 02:19:20 GMT
>     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.

haha.. thats incredibly stupid, actualy.. The only way you know now that
it is encrypted is by a little key and a blue line on the browser.  I
wouldn't be suprised if someone came up with a way to fake that in
java or a plugin.. ;P

But, all that needs be done add a new command that is sent prior to
the GET.  If a server doesn't support a command (say CRYPT) it
will respond with an error of unknown or unsupported method which
is perfectly acceptable.  I think that they could still basicly
say the service isn't available via that protocol as it does now
with multiple ports.  It wouldn't have to (and indeed most servers
wouldn't allow it) continue the request insecurely.

I know both FTP and HTTP have a response code to indicate success but
more information required, in which case that should be the response
to a CRYPT command that is supported by the server, then the server
sends the GET/PUT/POST/HEAD method as usual after establishing a
secure session.

The overhead added should be negligable, especialy in comparison
to the overhead of SSL in general.

>     Introducing a TCP option to denote encryption is a nice engineering 
> option but totally impractical. 

Definately a bad idea..  great for IPv6 with the socket layer encryption
with authentication ON TOP at the application level, but right now we
are stuck with what we have.

>     Adding in a SOCKS like proxy to do negotiation with before connecting
> is one approach but not to my liking ... 

Ick, another horrible idea, mostly because it would be incompatible
with a lot of existing systems and would waste port fd's and other
resources.  It would be easier just to recode the servers.  Remember
adding this sort of support will change the url to shttp: so it
will work along with https: until enough people convert to newer

I just think specification of secure requirement should be done
with the URL, even if it doesn't specify a separate service port.
(This might be netscapes problem.  The fact that the url type
wouldn't specify a unique name for encrypted connections if you
follow the URI/URL specs to the letter)
>     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).

We could probably get the Apache Group in on it..  Considering it is
now the most widely used web server on the net, it would be one big
step forward if it supports this.
>     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.

Exactly.. a new method CRYPT with an option that says what flavour
like SSL or TLS or custom encryption.  If the server doesn't understand
that it will bomb with an error saying unsupported method, which is
accurate in this case.  The connection will fail.  The browser 
developers could opt to either ask if they want to try insecure, or
just leave it as failed at that url which would be more appropriate.

I am very keen on privacy..  These issues seem very trivial to me but
as netscape appears to be the driving force in this (ugg..) we have
to play by their rules and make them aknowledge what we want.  SSL
implamentations have been done for most every port service (even NFS)
and most are available free and work with SSLeay and would work with
SSLRef with minor modifications.  The one thing holding us back is
the "big boys" microsoft and netscape sitting on their hands and
not implamenting the clients for their customers.  


Jason S. Clary

View raw message