here are some links that confirm what i said: ftp://ftp.isi.edu/in-notes/rfc2817.txt http://www.web-cache.com/Writings/Internet-Drafts/ draft-luotonen-web-proxy-tunneling-01.txt http://www.squid-cache.org/Doc/FAQ/FAQ-1.html#ss1.12
*but*: work is in progress: http://squid.sourceforge.net/ssl/ however, i am much in doubt that this is a good thing. SSL does not have the capabilities to include a third-party's key in the session key creation process. forwarding/gatewaying SSL is surely possible. even proxying seems to be, but you will not have a standing SSL tunnel with the ability to identify the target system, and you will not have access to information pertaining to the validity of the SSL session between proxy and target system. but, for the case in the original question, squid's SSL forwarding (using HTTP/1.1 CONNECT) may make sense... i do doubt that the ISP is enforcing proxy-usage over 443 links... -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] "and if the cloud bursts, thunder in your ear you shout and no one seems to hear and if the band you're in starts playing different tunes i'll see you on the dark side of the moon." -- pink floyd, 1972
pgpKCLKr4iwXW.pgp
Description: PGP signature
