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:"; net@madduck
"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
Attachment:
pgpJbnSEcLgsb.pgp
Description: PGP signature