Re: restricting wireless access
martin f krafft, 2003-Jan-12 19:27 +0100:
> also sprach iain d broadfoot <ibroadfo@cis.strath.ac.uk> [2003.01.11.2115 +0100]:
> > Squid is a FTP, HTTP and HTTPS proxy cache. For general
> > information on
>
> "marketing"
>
> you can't proxy HTTPS, think about it. squid can tunnel it, but that's
> not more than an circuit level gateway.
Just to clarify, I believe you are saying that Squid can't proxy
HTTPS. However, HTTPS can be proxied [see below for more on this].
There are commercial products that terminate the SSL connections and
then send clear text http on the backend to the web servers. The
purpose really is to offload the SSL processing from the webserver.
The firewall will will redirect all port 443 traffic to the SSL
"accelerator" for processing and then the clear text http on the
backend can be sent thru another firewall or directly to the web
server, or a load balancer for a farm of web servers.
>
> > i know ssh can't be sensibly proxied though, and i have no idea what
> > ipsec is. :D
>
> ssh can't be proxied for the same reason that HTTPS can't be proxied.
Thinking about it, what I described above really isn't a proxy but
rather an offload of the SSL part of HTTPS. However, the clear text
HTTP on the backend could then be proxied. I've not seen this done
though.
I agree that SSH cannot be proxied, but the big reason for it, as I
see it, is that the clear text traffic inside the encryption can be so
many different things. Also, I don't know that a need for an offload
of the encryption, like for HTTPS, is really needed since the load
from SSH usage on a server isn't what it can be for HTTPS.
jc
--
Jeff Coppock Systems Engineer
Diggin' Debian Admin and User
Reply to: