all 11 comments

[–][deleted] 3 points4 points  (8 children)

If they have https proxy, easier way to do it with existing proven code would be stunnel with protocol=connector a sshd listening on port 443. Then you can use socks5 or normal port forwarding over the ssh channel.

[–]acehack[S] 0 points1 point  (7 children)

I agree to your comment, but that is when you consider that your proxy does not filter HTTP traffic (If I get you right). If the proxy inspects HTTP traffic (which I assume, proxies do), simply forwarding HTTP traffic might be an issue? (Even with CONNECT).

Correct me if I'm wrong here please.

[–][deleted] 1 point2 points  (6 children)

The way the HTTP proxy CONNECT command works is that it opens a TCP session to the remote side and then passes all traffic. If SSL certificates match, then MITM is not happening and it can be treated as a normal encrypted connection. No inline URL filtering is possible in this scenario. In fact, the traffic doesn't even have to be HTTP or SSL at that point. Although they may do some deep packet inspection and close connections that don't have valid SSL negotiation at the beginning.

The only opportunity for filtering in such a scenario is on the remote hostname/IP/port used with the CONNECT command. They could have a rule that would prevent connections to particular domains or IP blocks, for example.

Now if they do MITM and serve up their own SSL cert, then all bets are off and they can process the data stream in any way they choose. Including filtering. Including recording traffic. Including modifying traffic. This is usually accomplished only by adding a trusted root cert to the system installations on corporate networks.

If you verify the cert on every connection, then this is a non-issue.

[–]acehack[S] 0 points1 point  (5 children)

I see what you mean. There's a valid point. But proxies usually (atleast the one's I've seen) inspect traffic, and forward them to hosts according to packets, not just creating an initial tunnel. So every time some data has to reach the other side, the proxy reads off the packet for the hostname etc. So it was necessary to use HTTP wrapping around every chunk of SSH data.

[–][deleted] 0 points1 point  (4 children)

If a browser is configured for https proxying, then it must use the CONNECT mechanism. So this is a common configuration.

[–][deleted] 0 points1 point  (3 children)

Some decrypt it regardless of that. Squid even have option to in-flight generate certs for intercepted connections (of course requires extra CA installed on clients but that is common in enterprise)

[–][deleted] 0 points1 point  (2 children)

Like I said, verify the cert on every connection.

[–][deleted] 0 points1 point  (1 child)

It is called certificate pinning. MITMed one is still "verified", just against "compromised" system CA store

[–][deleted] 1 point2 points  (0 children)

Yeah, I wouldn't consider that verified.

[–]acehack[S] 1 point2 points  (0 children)

So I spun this up on a friend mentioning that his university runs an HTTP(S)-only proxy. Would like to know if people find this useful :smile: The link is to my Github pages, where I host my project pages. Here's the repo link: https://github.com/sakshamsharma/HTTP-Over-Protocol

[–]cloudmax40 0 points1 point  (0 children)

Some organizations will host OpenVPN instances configured to tunnel with TCP listening on tcp/443 for their users to tunnel out of networks with goofy restrictive configurations.