On 04/05/11 02:02, Tsantilas Christos wrote:
I create the bug 3209.
Also I uploaded a first patch here.
Found the original discussion again:
http://bugs.squid-cache.org/show_bug.cgi?id=2314
That old bug covers the full feature redesign to both do SSL properly to
SSL marked peers and make CONNECT tunnels through non-SSL peers.
Your new one can be left separate for now to track the smaller
enhancement of blocking the info leakage.
On 04/29/2011 06:52 PM, Amos Jeffries wrote:
On 29/04/11 20:33, Tsantilas Christos wrote:
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==>
Yes that appears to be it. The problems being that a) proxy2 may not
have OpenSSL feature built in to re-crypt, and b) that the middle
channel is cleartext
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
As a short-term it may be okay. I don't see that working well with
normal proxied https:// URL requests, but those seem relatively rare.
Also we should define if the "allow-direct" http-port options will have
any effect in ssl-bump...
allow-direct being an accelerator mode option I think it will be
irrelevant once ssl-bump mode is created.
Since always_direct is documented as recommended, allow-direct behaviour
would seem to be implied for ssl-bump mode.
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...
Yes. I imagine the MITM crowd doing interception of LAN traffic from
local workmates and funneling up to a corporate proxy will want that.
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
