On 26/05/11 01:01, Ming Fu wrote:
It is too late to alter the client certificate. By the time a server
connection is opened Squid may have already served replies out of cache
to the client.
I am a bit surprised. Can sslbump make some https content cacheable?
Why surprised? ssl-bumps' purpose is to remove the SSL layer on arriving
traffic.
The data inside is just HTTP and gets handled same as any other.
Caching, filtering, alterations. Anything goes once the security layer
is erased.
A lot of agent behaviour when using HTTPS is based on the false
assumption that proxies and middleware cannot unwrap it. That all sorts
of private information can flow down the channels without any other
protection. Squid being designed to handle HTTP as securely as possible
does correct the auth and cookie problems, but cannot erase URL and body
content information disclosures.
Meanwhile it is worth investigate why you are getting so many failures...
The actual failure is not my problem, however, the potential of failure or
behavior difference from none sslbump setup is becoming a roadblock for sslbump
acceptance.
Potential is just that, potential. This particular potential has been
attended too and minimized within Squids capabilities.
If you want to fix roadblocks to ssl-bump please pay attention to the
problem of "Anything goes once the security layer is erased.". There is
a thread on squid-dev ("ssl-bump security bugs") where we discuss the
worst known security vulnerabilities on networks which bump.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.7 and 3.1.12.1
