[squid-users] does http_port sssl-bump work require-proxy-header?

[Yuhua Wu]

I worked a fix:

diff --git a/squid-3.5.1/src/client_side.cc b/squid-3.5.1/src/client_side.cc
index d72e8c4..025316d 100644
--- a/squid-3.5.1/src/client_side.cc
+++ b/squid-3.5.1/src/client_side.cc
@@ -3045,7 +3045,8 @@ ConnStateData::parseProxy1p0()
         debugs(33, 5, "PROXY/1.0 protocol on connection " <<
clientConnection);
         clientConnection->local = originalDest;
         clientConnection->remote = originalClient;
-        clientConnection->flags ^= COMM_TRANSPARENT; // prevent TPROXY
spoofing of this new IP.
+        if (clientConnection->flags & COMM_TRANSPARENT)
+            clientConnection->flags ^= COMM_TRANSPARENT; // prevent TPROXY
spoofing of this new IP.
         debugs(33, 5, "PROXY/1.0 upgrade: " << clientConnection);

         // repeat fetch ensuring the new client FQDN can be logged
@@ -3135,14 +3136,16 @@ ConnStateData::parseProxy2p0()
         clientConnection->local.port(ntohs(ipu.ipv4_addr.dst_port));
         clientConnection->remote = ipu.ipv4_addr.src_addr;
         clientConnection->remote.port(ntohs(ipu.ipv4_addr.src_port));
-        clientConnection->flags ^= COMM_TRANSPARENT; // prevent TPROXY
spoofing of this new IP.
+        if (clientConnection->flags & COMM_TRANSPARENT)
+            clientConnection->flags ^= COMM_TRANSPARENT; // prevent TPROXY
spoofing of this new IP.
         break;
     case 0x2: // IPv6         clientConnection->local =
ipu.ipv6_addr.dst_addr;
         clientConnection->local.port(ntohs(ipu.ipv6_addr.dst_port));
         clientConnection->remote = ipu.ipv6_addr.src_addr;
         clientConnection->remote.port(ntohs(ipu.ipv6_addr.src_port));
-        clientConnection->flags ^= COMM_TRANSPARENT; // prevent TPROXY
spoofing of this new IP.
+        if (clientConnection->flags & COMM_TRANSPARENT)
+            clientConnection->flags ^= COMM_TRANSPARENT; // prevent TPROXY
spoofing of this new IP.
         break;
     default: // do nothing
         break;

I assume the intention of code is to turn off COMM_TRANSPARENT if PROXY
protocol is used.

Is this proper change? At least, it works for me now,

Alex


On Tue, Apr 14, 2015 at 3:14 PM, Yuhua Wu <ywu at bitglass.com> wrote:

> I found out what is wrong, but I am not familar to squid code, so I post
> here to see if someone can show me the next step:
>
> The problem is at this part of code:
> void
> ClientHttpRequest::sslBumpStart()
> {
>     debugs(85, 5, HERE << "Confirming " << Ssl::bumpMode(sslBumpNeed_) <<
>            "-bumped CONNECT tunnel on FD " << getConn()->clientConnection);
>     getConn()->sslBumpMode = sslBumpNeed_;
>
>     AsyncCall::Pointer bumpCall = commCbCall(85, 5,
> "ClientSocketContext::sslBumpEstablish",
>                                   CommIoCbPtrFun(&SslBumpEstablish, this));
>
>     if (request->flags.interceptTproxy || request->flags.intercepted) {
>         CommIoCbParams &params = GetCommParams<CommIoCbParams>(bumpCall);
>         params.flag = Comm::OK;
>         params.conn = getConn()->clientConnection;
>         ScheduleCallHere(bumpCall);
>         return;
>     }
>
>     // send an HTTP 200 response to kick client SSL negotiation
>     // TODO: Unify with tunnel.cc and add a Server(?) header
>     static const char *const conn_established = "HTTP/1.1 200 Connection
> established\r\n\r\n";
>     Comm::Write(getConn()->clientConnection, conn_established,
> strlen(conn_established), bumpCall, NULL);
> }
>
> if require-proxy-header is not used, then request->flags.interceptTproxy
> is 0, and when requir-proxy-header is used, the
> request->flags.interceptTproxy is 1!
>
> since request->flags.interceptTproxy is 1, the 200 status code for CONNECT
> call is not sent. (The last part of code sending 200 status code is
> skipped.)
>
> Any kind help?
>
> Alex
>
>
> On Tue, Apr 14, 2015 at 10:05 AM, Yuhua Wu <ywu at bitglass.com> wrote:
>
>> I think, in the sslbump mode, if PROXY protocol is enabled, client cannot
>> set up the SSL tunnel with squid after CONNECT call succeeds. I remember
>> that HAProxy will send PROXY protocol line during ssl negotiation. If squid
>> does not parse the PROXY protocol header during SSL negotiation, this will
>> cause the problem.
>>
>> Alex
>>
>> On Mon, Apr 13, 2015 at 7:56 PM, Amos Jeffries <squid3 at treenet.co.nz>
>> wrote:
>>
>>> On 14/04/2015 4:47 a.m., Yuhua Wu wrote:
>>> > For example, is this configuration supported?
>>> >
>>> > http_port 3129 require-proxy-header ssl-bump ……
>>> >
>>> > By the way, we added acl rules:
>>> >
>>> > acl frontend src 10.0.0.0/8
>>> > proxy_protocol_access allow frontend
>>> >
>>> > Alex
>>> >
>>>
>>> Yes that should work.
>>>
>>> <http://www.squid-cache.org/Versions/v3/3.5/RELEASENOTES.html#ss2.7>
>>>
>>> Your above config example decrypts the traffic through the following
>>> layers:
>>>   HTTPS over HTTP/1.x over PROXY/TCP ...
>>>
>>> As you can see the PROXY and HTTPS layers are separate protocols that
>>> dont interact.
>>>
>>> Amos
>>>
>>> _______________________________________________
>>> squid-users mailing list
>>> squid-users at lists.squid-cache.org
>>> http://lists.squid-cache.org/listinfo/squid-users
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150414/5a0904f2/attachment.html>