Re: does http_port sssl-bump work require-proxy-header?

[Yuhua Wu <ywu@xxxxxxxxxxxx>]

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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users