On 04/10/2011 02:53 AM, Amos Jeffries wrote: > 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.
I agree that using ssl-bump can add more problems than just the man-in-the-middle attack it is meant to be. I may be wrong, but I suspect most of those problems are specific to how and where ssl-bump is used. In other words, it should be possible to use ssl-bump more-or-less securely (the man-in-the-middle attack aside) but not all ssl-bump uses are secure. We should make secure use easier/better, of course. > * 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. This is discussed below. > * 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 existing bumping code was never meant for cache hierarchies that need tunnels to peers. If it works, great. If it does not, let's welcome fixes. Meanwhile, we can claim that bumping such hierarchical tunnels while ignoring requests for internal objects is not supported. > * 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. I hope the above is not universally true but specific to some setups. I know that encryption worked correctly in the setups the implementation was meant for, but perhaps something got broken. Are outgoing requests encrypted in the setups where CONNECT requests are bumped? > IMO these all stem from the lack of a distinct sslbump "mode" of > operation and its leveraging accel mode flags to achieve some > behaviours. I agree that a special ssl-bump code may be needed in more places (e.g., your tunneling of internal requests to known peers seems like a good candidate). I am not sure leveraging other modes in other places is necessarily bad on its own, but perhaps the code is leveraging wrong modes in wrong places. > 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. I do not think we should identify bumped traffic using any of the existing reverse proxy flags. When special handling of bumped traffic is needed, we should use an "ssl-bumped" flag or test. Please note that this does not mean that bumped traffic should not reuse some of the existing reverse proxy flags/code at the same time, to trigger the right handling outside of those special bump-only cases. > 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? If I understand the question correctly, the motivation for using the "reverse proxy" mode was that the ssl-bump, after the bumping, deals with requests typical to a reverse proxy environment: Those requests are sent to origin servers, not Squid. I doubt there was ever a clear understanding of the difference between various reverse-proxy flags. We probably used what seemed to work. Keep in mind that the setting of those flags itself was changed/fixed (IIRC) since the original ssl-bump code was written. It is possible that what used to be the more-or-less right flag is no longer correct. It is also quite possible that something other than "accel" would work much better, but I am not quite sure we need a _new_ reverse proxy flag, orthogonal to the existing ones (a new "ssl-bumped" flag may be a good idea though). Finally, from the squid.conf and administrator point of view, ssl-bump is used in at least two modes: interception (TCP hijacking) and forward (CONNECT) proxy. I do not know whether both setups require the same "reverse proxy" flag internally or not, but the latter setup essentially becomes the former after the CONNECT request is "bumped". To summarize, I think the best way forward may be: 1. Decide which existing reverse proxy flag(s) the ssl-bump code should set. The decision can depend on whether we are bumping CONNECT requests or intercepted connections. Use the right flag(s). 2a. Add a new "this connection (and transaction) was ssl-bumped" flag. 2b. Identify cases where bumped traffic needs special treatment. Document current limitations/bugs on the wiki. Implement special treatment code, using the new flag from (2a) as a trigger condition. This may require several iterations, one special case at a time. Thank you, Alex.
