Robert Adkins wrote:
>
> Gosh, I am really uncertain about that. I believe that SSL is much more
> than simply data on a different port number. If that was the case, there
> should be no problem with that.
SSL is running ontop of TCP/IP. As mostly any other clean TCP/IP
application it plays nicely with NAT etc.
> However, I do know that it is not possible to compress SSL traffic, at
> least with a compression software client/server system that I helped
> support. It could be something to do with the encryption being placed
> upon the SSL data. I am only speculating as I am just beginning to get
> into that area of knowledge.
Any good encryption will make data impossible to compress. SSL is no
exception. If you can compress encrypted data then the encryption is too
weak as it obviously has failed to encrypt the information denseness of
your data.
> I believe that due to the difference between http and https data squid
> and probably other proxy servers are just unable to cope with that data
> without severely compromising the safety and or integrity of SSL traffic.
Squid can at most tunnel SSL exactly as it is, bit for bit. Squid knows
nothing of what is going on within the SSL connection. Squid can only
know from where to whom the SSL connection is established.
In theory by snooping the SSL traffic, a man-in-the-middle (i.e. a
proxy, or a hacker sniffing your network) can also see the public
certificate of the server, and some information about the encryption
level selected. See the excellent tool "ssldump" if you are interesting
in these kind of SSL analyzes.
> Your best bet might be just to leave SSL traffic alone and work out
> something with the automated proxy server settings change. Sure, it will
> be a bit of work, but that is always something well worth knowing.
Agreed.
Regards
Henrik
Received on Fri May 03 2002 - 16:33:59 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:07:54 MST