It has become clear that ssl-bump opens several nasty security
vulnerabilities to networks using it. Even putting aside the detail
that it starts off life as a man-in-middle in the first place.
* ssl-bump traffic is marked as "accel". Even though it is not. Which
causes http_port vhost, vport, defaultsite come into affect. Along with
MISS and cache-control overrides not available in forward or intercept
proxy.
* It is conceivable that the tunnel may be legitimately made to
another proxy. This proxy will answer the cache_object:// requests
intended for that remote one.
* The decrypted requests are not re-encrypted when sent outbound. IIRC
there were measure attempted to make this happen, but they seem to have
been unsuccessful.
IMO these all stem from the lack of a distinct sslbump "mode" of
operation and its leveraging accel mode flags to achieve some
behaviours. Some of these flaws can be fixed with ssl-bump specific code
which will be dangerous to accel, and some of the accel behaviours are
dangerous for intercepted traffic. But the way to identify bumped
traffic being the accel flag makes this overly difficult.
Alex, Christos:
can you please point out the reasons for using accel mode? which
areas need to have (accel|sslbump) tests added when moving to a
dedicated sslbump mode flag?
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.6
