On 04/29/2011 08:30 AM, Amos Jeffries wrote:
On 29/04/11 05:26, Tsantilas Christos wrote:On 04/12/2011 11:10 PM, Alex Rousskov wrote:On 04/11/2011 11:33 PM, Amos Jeffries wrote:On 12/04/11 03:28, Alex Rousskov wrote:On 04/10/2011 02:53 AM, Amos Jeffries wrote:.....* 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.Do we have any such report? Which is the used configuration? I did some tests here, and also I tried to find such cases but I did not found. The traffic in my tests always re-encrypted before sent.I have two users mention replication of this in squid-users. The replicated case seems to be: http_port ... ssl-bump cache_peer ... parent ... always_direct deny all
Yep this is true. I think we should consider it as a bug. What I am actually getting is the following: <=https==> [proxy] <===http==>[proxy2]<==https==>The easier solution is to add a check in FwdState::connectStart() in forward.cc file:
if (fs->_peer && request->protocol == AnyP::PROTO_HTTPS) {
anErr = errorCon();
fail(enErr);
return;
}
The above will just disable any ssl-bumped connection through any parent
Also we should define if the "allow-direct" http-port options will have
any effect in ssl-bump...
The ideal I think is to use "CONNECT ..." when connecting through a parent proxy. But this is requires more development, I do not know if it is required and if we need it...
NP: the ssl-bump features page says "always_direct allow all" is required. Simply removing that line to allow Squid to send to a parent peer causes the behaviour seen....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).I'm not sure where yo got the new reverse proxy flag idea from. New "bumped" flag was the proposal.Sorry if I misunderstood. Let me try to clarify. We have two options, at least: 1. An ssl-bumped flag and nothing else. Used to correctly process all requests and all special cases. Implies reverse proxy mode but is exclusive to existing reverse proxy flags: if (accel) ... else if (intercepted) ... else if (sslBumped) ...maybe it make sense... Looking the code I can not find many advantages with using the accel flag for ssl-bumped connections. But it requires more study, maybe I am loosing something... Moreover the ssl-bumped requests have more similarities with the intercepted requests than the accelerated....2. An ssl-bumped flag in addition to the right existing reverse proxy flag(s). I know that the accel flag may not be the right one, but just to illustrate this option: if (accel) { ... if (sslBumped) ... ... } else if (intercepted) { ... if (sslBumped) ... ... } else { ... if (sslBumped) ... ... } I am not sure which approach is better.Both look the same to me. #1 is what we need now. #2 is extended to handle bumping inside intercepted traffic. That bit can go in when we have the cert sniffing. Amos
