`shrpx --client-proxy' behind a transparent proxy

[n0wa11]

Moving from #31 .

In a following situation, where the client is behind a transparent proxy often seen in a corporate environment,

[ < client/chrome > <--> < proxy > ] <===> [ < shrpx > <--> < squid > ] ] <===> < google.com >

I think a possible solution is to let `shrpx --client-proxy' support a transparent proxy.

[ < client/chrome > <--> < shrpx --client-proxy > <--> < proxy > ] <===> [ < shrpx > <--> < squid > ] ] <===> < google.com >

What do you think?

[tatsuhiro-t]

Do you want to connect from inside network to SPDY proxy (shrpx) in SSL/TLS? What does a transparent proxy do to SSL/TLS connection? I think it seems impossible to tunnel through to the outside, but I may be missing something.

[n0wa11]

Do you want to connect from inside network to SPDY proxy (shrpx) in SSL/TLS?

Yes

 What does a transparent proxy do to SSL/TLS connection?

That depends. The proxy could just passthrough, only checking the URL. Or the proxy may be a MITM. I believe most corporate proxies just passthrough.

This is expected to work the same way as the OpenVPN http-proxy directive.

http://openvpn.net/index.php/open-source/documentation/howto.html

[tatsuhiro-t]

That depends. The proxy could just passthrough, only checking the URL. Or the proxy may be a MITM. I believe most corporate proxies just passthrough.

Indeed it depends. But checking URL in SSL/TLS connection, the transparent proxy must decrypt the stream, so it must be MITM? http://tektab.com/2012/09/28/squid-transparent-proxy-for-https-ssl-traffic/ http://openvpn.net/archive/openvpn-users/2005-05/msg00100.html

If the proxy is MITM, it talks to outside shrpx and performs SSL/TLS handshake on behalf of client. If the proxy does not support NPN or SPDY protocol, I think client can talk to shrpx in HTTPS (non-SPDY) if the proxy passthoughs the requests. If proxy supports SPDY, it may relay SPDY frames.

If the proxy does not support SPDY and you want to connect to the outside shrpx in SPDY..., then your proposal comes in? But without defining the behavior of the transparent proxy, it seems to me that we could not make a solution.

[ < client/chrome > <--> < shrpx --client-proxy > <--> < proxy > ] <===> [ < shrpx > <--> < squid > ] ] <===> < google.com >

What kind of HTTP request is moving between client/chrome and shrpx --client-proxy and proxy, and to the outside?

[n0wa11]

On the URL check part, I didn't make myself clear. The users behind the corporate proxy usually browse gmail, Facebook, YouTube etc. The proxy can see the URLs and want to block the users.

In our case, the proxy only sees the SPDY proxy's URL, so won't do anything.

To see the URLs inside the SPDY stream, as you said it has to be MITM, and the proxy needs to know NPN.

According to my experience, MITM in a corporate environment is very rare. There might be legal issues. And the users can find out easy, by checking the certificates.

We can assume the proxy just passes through any https traffics.

If shrpx can do what openvpn does, it will be nice.

[tatsuhiro-t]

I think proxy sees only hostname, not URL. I think we are now talking about forward proxy, aren't we? Then for HTTPS traffic, client sends CONNECT to the proxy. Then proxy connects to the outside host, say, google.com, and responds to the client with 200 OK. After that, client and google.com communicate in encrypted stream which proxy cannot sniff. Then I understand the problem. For client to connect to the outside SPDY proxy, it must somehow send CONNECT to the proxy. We are lacking this part of interaction. If I understand correctly, we need something like this:

[client <--SPDY--> shrpx --new-mode <--SPDY (proxy passthrough after CONNECT) ]--> [shrpx <--> squid] <--> google.com

Is this correct?

[n0wa11]

Host names for https. I wasn't accurate.

You are right about the rest, too.

I was confused with a different setup. But most of corporate proxies are set up as you described.

[tatsuhiro-t]

Added --spdy-bridge and --backend-http-proxy-uri options to accomplish this. See http://spdylay.sourceforge.net/package_README.html#shrpx-a-reverse-proxy-for-spdy-https Also read the Note in the above link about MaxConnectionsPerProxy setting.

[n0wa11]

You are really quick. I will try it out in the next few days.

A quick question. How does shrpx --spdy-bridge know --backend-http-proxy-uri is a Web site or a proxy? Given the fact that these 2 diagrams are repeated below, I guess there are some editorial problems.

Client <-- (SPDY, HTTPS) --> Shrpx <-- (SPDY) --> Web or SPDY Proxy etc
                          [SPDY bridge]           (e.g., shrpx -s)

[tatsuhiro-t]

--backend-http-proxy-uri must be a HTTP proxy as its name suggests.

The configuration:

Client <-- (SPDY, HTTPS) --> Shrpx <-- (SPDY) --> Web or SPDY Proxy etc
                          [SPDY bridge]           (e.g., shrpx -s)

is without --backend-http-proxy-uri.

The configuration with --backend-http-proxy-uri is described at the end of the section:

Client <-- (SPDY, HTTPS) --> Shrpx <-- (SPDY) --
                         [SPDY bridge]

        --===================---> SPDY Proxy
          (HTTP proxy tunnel)     (e.g., shrpx -s)

More over, shpx with --spdy-bridge does not need to worry about whether its backend is proxy or web, because it is the client which decides the first proxy (shrpx --spdy-bridge) is proxy or web and its request is just relayed to the backed by --spdy-bridge.

[tatsuhiro-t]

Can we close this?

[tatsuhiro-t]

This feature had been entirely broken. I fixed it yesterday. Get the latest copy.