You can use an anonymity service like ultrasurf to connect to HTTPS sites. Is what they are doing illegal/immoral because it is a man-in-the-middle scheme?

I think quite the opposite, HTTPS is the only way to connect securely when going via TOR or ultrasurf because you are guaranteed to get to the right server and the proxy does not know what content passes through it - it is all encrypted between you and the HTTPS server.

This is the setup I want to duplicate in my LAN. The transparent proxy will not know what content goes through it. How do I do this?

The rule that works for port 80 below does not work if you replace 80 with 443 (HTTPS) and have both rules as below.

#! Redirect HTTP to transparent proxy by privoxy
iptables -t nat -A PREROUTING -i eth1 -p tcp --destination-port 80 -j REDIRECT --to-ports 8118

# Redirect HTTPS likewise
iptables -t nat -A PREROUTING -i eth1 -p tcp --destination-port 443 -j REDIRECT --to-ports 8118

How do I make this work? But without decrypting the traffic going through the proxy?

Please keep in mind that the the "benefits" that Ultrasurf strongly promotes, going around company or government blocks, is not a topic that is allowed for discussion on LQ. However, your post and their web site do bring up a lot of valid security tops that warrant discussion, so lets focus on those:

EDIT: I wrote this before I noticed your previous attempt at this thread that was closed with a warning. I also note that you revised the question. We will not focus on how to engage in or create a mitm. Instead we will focus on the risks and benefits of using a service like Ultrasurf or TOR.

In most countries, using an anonymity service is not illegal, in others it is. I don't see that it is immoral. Referring to the places where it is not Illegal, Where you go, and what you do on the Internet is your business. Taking steps to ensure that your traffic is not being monitored is not immoral. Could such actions be used for Illegal purposes? Yes, but we won't discuss those.

Not in the sense that term man-in-the-middle attack is concerned. Services like Tor, and I assume for the sake of discussion Ultrasurf (more on this later) are onion routing proxies. This means that they do put connections in between / in the middle of your connection. This has the effect of hiding the originating IP and obfuscating who is going to site XYZ. One concern with them is that there has to be information to get the target data back to the original host, so, theoretically it is possible to compromise these systems. Generally traffic in the middle nodes, is encrypted and by current standards isn't accessible to an eavesdropper. This isn't the case for an exit node where traffic leaves unencrypted. If the traffic is encrypted, using https, theoretically it should still remain secure.

Using HTTPS with these kinds of services does help increase your anonymity. However, HTTPS doesn't entirely cover what you are up to. There is still the DNS and the IP address of the destination. Consequently, if you go to a site like sex.com (or an IP belonging to this site) it is pretty obvious that you are looking for pornography, even what you look at specifically can't be seen by someone monitoring the connection.

Are you sure? What if you go to the wrong site that is a cleverly chosen counterfeit? What if they have a stolen certificate? This is a whole different issue. Using onion routing will help you go around, via using a random path, a deliberate mitm, but I wouldn't go as far as to say it guarantees it. You must still use due vigilance.

And here we get to the crux of the issues regarding Ultrasurf specifically. Trust is a big one here. Do you trust them? Who are they? how do they operate? How can they give this "product" away for free? Who is this "board of governors" they claim supports them on their web site? They give you a binary only application for a Windows based system and say, "here run this" and "trust us that you are secure". What guarantee do you have? Have you looked at the code? Are you sure the traffic is encrypted? How is it encrypted? Was it done in such a way that they can analyze it?

I don't fully understand. Please clarify. What is your concern here? What do you mean by transparant proxy not know what goes through it? Do you mean logging? Onion routing on your LAN doesn't make sense, so this part of the setup is not practical.If you use HTTPS from an endpoint behind the proxy, the proxy won't be able to decrypt the data. Encryption is endpoint-to-endpoint, except for a mitm scenario. Let me give you a similar example. My wife runs a small business and sells material at open air markets. As a convenience to the customers we accept credit cards. To process the credit cards, we use a terminal machine that was provided by the bank. This machine connects to a (Linux based) PC on the wired Ethernet and then we use our cell phones to get an Internet connection. The Linux PC is theoretically, a man-in-the-middle (as is every router on the net path). The data from the terminal is encrypted using TLS at the terminal. The PC is effectively an "exit" node. Running scanning utilities on the PC will only show encrypted traffic. Without a private key it would be impossible for someone of my resources to decode the traffic. I can still see where they went though, the IP address of the server that handles the processing. From this information it is a pretty good guess that is is a credit card transaction. The PC is also a transparent proxy for the system. Using a tool like iftop will show where connections are being made to. Not knowing the content is a matter of degree.


As with all security related issues, the biggest question you must ask is, "what are you trying to protect against." If you are concerned about a government agency monitoring your connections, there is probably little you can do about it. If you use a service like TOR, you may make it more difficult to trace you, but unless you have done something you shouldn't they are probably not paying attention to you anyway.

2 members found this post helpful.

I do not trust them. But it's better than being completely naked.

I am running their .exe under wine and using a restricted user account specific to wine. Chances are, they cannot mess with the browser's encryption, remember it is the browser that encrypts HTTPS data and requests the HTTPS connection, and that browser is running in another machine in the LAN. Their encryption is therefore irrelevant. Only useful for HTTP connections, but they encrypt everything anyway, including HTTPS a second time.

Probably a Chinese honeypot for windows users.

They probably sell lists of target sites and visitor ip's. Which is ok with me, as I intend to chain them with another anonymity provider so one provider knows my ip, one provider knows the sites, neither can sell anything. Or even add more to the chain.

I just mean privoxy collects the encrypted data from the LAN as a transparent proxy and passes it to its parent proxy, which is the ultrasurf .EXE proxy, which tunnels it to the remote ultrasurf server, which connects to hotmail, say. HTTPS between hotmail and the browser means no intermediate server knows the content going through because it is encrypted by the browser and the hotmail server.

So the question is, what iptables rule or other configuration will make the above work for HTTPS? So far it works for HTTP only.

PS. We don't want the transparent proxy to know the HTTPS content because that would make a man-in-the-middle scheme possible and we do not want to train readers how to do man-in-the-middle schemes.

By the way, in windows this works, microsoft's "internet connection sharing" intercepts both HTTP and HTTPS traffic. But only with the proxpn proxy which is very slow, almost as slow as dial-up.

So if windows can do it, linux can do it. Any ideas?

Thing is, for you to get that second iptables command to mean anything, Squid would need to decrypt the SSL connection (MITM attack). Otherwise, there's simply no way Squid could act as a proxy (MITM), since all the HTTP content is encrypted.

Then how does windows do it, with proxpn? Let's duplicate that in linux.

In windows afaik the proxpn .exe creates something like a virtual ethernet adapter and everything from the LAN is forwarded to that, including HTTPS. What is the linux equivalent?

You can create a virtual ethernet adapter, such as a tap device, in Linux too. What I am questioning about your results with Privoxy is that it is supposed to work with HTTPS. However, quoting from the privoxy man page: I read that TOR recommends the use of Polipo over Privoxy because it is more feature rich. I wonder if that would work?

The same way VPN is done on any OS: encapsulation. This is very different from a proxy server doing MITM (given that with a VPN, your traffic's end-to-end encryption is maintained). Also, keep in mind that the VPN service provider is free to carry out a MITM attack against you any time they wish, just like any other node between you and your final destination is able to do.

I'm not familiar with the product or company, but I would like to think that whatever they're doing is legal.

Whether it's immoral or unethical is another story, though. I mean, if they're (for example) simply providing VPN services, then that doesn't on its own interfere with your end-to-end encryption so it's all good IMO. If, OTOH, they're doing MITM and issuing their own certificates, then I'd say it's highly unethical (not to mention dangerous, sleazy, etc.), because, at that point, you're forced to trust them entirely (and letting them do whatever they want with your otherwise secure HTTPS traffic).

Alright, I'll try it with polipo, except it is not available in this distro's repositories so I'll build it and then find out how it is configured.

Any other easy to use proxies?

By the way, when you specify a proxy in firefox, HTTPS traffic is proxied too. So a proxy can do HTTPS, it is the intercepting that does not currently work with HTTPS, perhaps because of a deliberately built-in limitation.

Sure, but afaik HTTPS between me and hotmail makes a MITM attack impossible without theft of hotmail certificates therefore MITM is not an issue as long as we're connecting to hotmail with HTTPS. So can we please stop repeating MITM, MITM, MITM where MITM is no longer an issue.

Nobody is claiming that HTTPS can't be made to work with a proxy server. What I'm trying to help you understand is that HTTPS can't be transparently proxied like you do with HTTP unless you setup a MITM attack. It's not a "deliberately built-in limitation" or anything like that, it's just the way it is (for reasons I will describe near the end of this post), and it doesn't matter what operating system, proxy server software, service provider, or whatever else you use. If you take some time to study the basic workings of HTTP, SSL, and proxy servers, I'm sure the reason for it being this way will become clear to you.

As for configuring your browser to use a proxy for HTTPS, that's completely different from transparent proxying, and is therefore not applicable in this case. When your browser is set to use a proxy server for HTTPS, the CONNECT method is used, and the proxy server facilitates a tunnel between the client and destination server. In other words, the proxy server is still not doing any SSL termination and is just as unable to see the actual HTTP content as a NAT firewall would be. Another way to look at this could be that the proxy server temporarily stops acting like a proxy server and starts acting like a simple relay between the client and the destination.

Again, for the proxy server to work transparently with HTTPS, it would need to terminate the SSL connection so that it could act as a MITM (which would require that it issue its own certificates for the destination servers, and that the clients are configured to accept these certificates). This is actually easy to do with Squid if you google it, but as you already know we aren't going there.

The certificates are publicly-available, so stealing them would be pointless since you can just download them whenever you want. What you're probably trying to convey here is that a CA's private key would need to be stolen in order to sign a fake Hotmail certificate.

BTW, you do understand that a proxy server is by definition a MITM, right?

I'll take another shot at the original question:You don't. Think about what this rule is doing. It's taking a TCP/IP packet (which originally had the IP of the destination server and the port number on which the HTTPS service was listening on said server), and it's changing the destination port on it to 8118 and the destination IP to whatever IP the interface the packet arrived on had. This is done so that the packet can be automatically delivered to the proxy server for processing. So now, what does the proxy server have? It has a TCP/IP packet with it's own IP and port on it, and inside this TCP/IP packet is a bunch of (SSL) encrypted data which it obviously can't make any sense of (this encrypted data includes all the HTTP content). Can you see now why it won't work? It works for HTTP (non-SSL) because the proxy server is able to see the HTTP content, and therefore act as a MITM (it behaves as the server to the client, and it actually becomes the new client to the original destination server).

What about the CONNECT method? Well, basically, when a client is set to use the CONNECT method for its HTTPS proxy, it tells the proxy server what the destination server's hostname and port are before it begins transmitting the actual content (which doesn't need to be SSL-encrypted HTTP, but that's what we're discussing here), so that the proxy server understands that it's expected to stop acting like a MITM and start acting like a tunnel. A CONNECT request looks like this (example):As you can see, now the proxy server application has the information it needs (hostname and port) to relay information back and forth between the client and server, without having needed access to the actual content inside the TCP packet.

1 members found this post helpful.

Thanks for the detailed reply.

So it boils down to a proxy being a MITM by definition, like an imaginary postman who only accepts open envelopes. Unless the envelopes are pink (CONNECT method). We don't want a proxy then.

But wait, searching for proxies, look what I found:

"desproxy can forward TCP/IP traffic via a HTTP proxy. Desproxy uses a HTTP/1.1 method (CONNECT) to establish TCP/IP connections on demand. CONNECT is used for SSL connections when accessing to secure sites, so if you can access sites that support SSL (www.hotmail.com for example) you can use desproxy."

What is it saying here? All tcp/ip traffic, including SSL, can be put through an HTTP proxy like privoxy. This is the one I need then, isn't it?

Although the question arises, where do hotmail servers think data is coming from? What port, what IP, and what browser?

Are you saying that the initial port number is lost when a REDIRECT rule is applied? If it were port 80 being redirected to 8118, the number 80 would be forgotten? Then how would the listening software (proxy in this case) know what port to connect to at the internet site? Mustn't 80 be stored somewhere?

If yes, 443 is stored somewhere too, so the listening software (whatever it is, NOT a proxy) can deal with HTTPS connections too.

It's HTTP tunneling software. It lets you communicate using TCP through a proxy by using the HTTP CONNECT method. Remember when I mentioned in my previous post that the content you transmit/receive by means of the CONNECT method isn't limited to HTTP/S? Well, this desproxy is a good illustration of that. If, for example, a proxy server allows the CONNECT method to be used on any outbound request to port 443 (the assumption being that the requests are intended for HTTPS servers), then by using this kind of software you should be able to establish TCP connections to pretty much any TCP service you set up, as long as the service is listening on port 443. As for whether this is what you need, I have no idea. Honestly, I'm not even sure what exactly it is that you're trying to achieve. Please clarify what your objective is.

I'll try to answer your other questions when I get back (if they haven't been answered by another member by then).

I'm on my way out. TTYL.

Anonymity by using several anonymity providers in a chain in order to counter this:

In your terms, the objective is hotmail HTTPS access through a tunnel within a tunnel within a tunnel within a tunnel etc.

The IP address they see is the proxy server's external IP (or the external IP of the router which the proxy server is using, depending on the setup). The source port they see is whatever port from the ephemeral port range the proxy server used to start the connection (or the router used to forward the packets). The browser they see is whatever was sent in the User-Agent request-header field.

Squid will look at the Host request-header field in the HTTP content.

Squid doesn't have access to the HTTP content in these cases (since it's encrypted). All it cares about in these cases is the information in the CONNECT request. Anything having to do with HTTP (other than CONNECT) will be handled by the client and the final destination without Squid being involved. All Squid sees is an SSL connection.