On Tue, Aug 13, 2002 at 02:21:30PM -0600, David Waite wrote:
> Greg Stein wrote:
>
> >And a verifiable certificate is for *authentication*, not for encryption. We
> >can self-sign a certificate and get the same level of strong encryption. So
> >we *will* have "real security" in the sense of "real encryption."
> >
> >We just won't be using the associated certificate for authenticating that
> >we're talking to the "right" server.
>
> Although I'm sure you realize that encryption doesn't do very much if
> you are talking to an intermediary between the client and the 'right'
> server :-)
Yah :-)
> SSL makes sense as long as HTTPS is to get around proxy problems rather
> than for security (it doesn't make sense for security since you can do
> secure authentication without SSL, and the actual content being sent is
> publicly available already)
Yup... this is for guys with proxies that:
* don't support WebDAV methods over port 80 (e.g. it is an app-level
firewall/proxy which is proxying requests with knowledge of the HTTP
method being used)
* don't support contacting port 81 (e.g. the firewall/proxy only allows port
80 outbound connections, yet its port 80 is app-level and filters the DAV
methods)
By embedding the HTTP methods within an encrypted stream, the
application-level firewall/proxy cannot filter out the WebDAV methods. We
would also be on a port which the firewall/proxy allows for outbound
connections.
However, your point about turning encryption is pretty neat. I didn't
realize that SSL/TLS supports that (although I imagine with a bit of
thought...). But in this case, we definitely want the encryption. By virtue
of needing to use https, we've already determined that the client's
firewall/proxy is an app-level package and is analyzing the HTTP methods. We
don't want that thing to get a chance to look at the methods travelling over
port 443.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 23:22:58 2002