I'm trying to set up a proxy server that can handle both http and https traffic without prompting the browser about certificates (just like tunlr.net).
So far I've tried to use Squid and Nginx.
While handling regular http traffic is a walk in the park, https is proving very difficult.
Can anybody point me in the right direction?
I think you should use a socks proxy not an http proxy, just like doing ssh tunnels, I used one on my vps, a package called dante the set up is kinda tricky but it really does the trick.
The package is available by default in ubuntu's repositories, and I assume probably other distros too.
Search on google on how to configure dante, and make sure you don't use a standard port, and even better use authentication to use the proxy, you don't want random people using your server as their proxy.
I just figured it out, turns out you don't need to set the https_port directive, only the http_port.
Related
I have two projects running on Wildfly-8 and I have two SSL certificates for each of them and one IP.
I figured out that I should have one IP for one SSL certificate.
But I needed to use these two SSL for one IP. I couldn't find a way to do it with Wildfly but there was a way to do it with Apache Server. So,I installed Apache Server up to Wildfly.
I listen https port(443) on Apache and redirect it to Wildfly's http port(I used 8080). It works without any problem.
What I wonder is;
1. Is Apache decrypt request and redirect it to Wildfly?
2. Is it correct way to do it or I have done it by chance?
3. Does this method create a security hole?
I googled some, but I could not find satisfied answers.
Thanks for replies.
For this answer, I'm supposing that by "redirecting" you mean "proxying": Apache receives the request, proxies it to Wildfly, receives an answer from Wildfly, sends the answer to the client.
If you mean something else, then the simple answer is: it is wrong[1].
Is Apache decrypt request and redirect it to Wildfly?
Yes. Apache will receive and send secure data to/from the client. Its communication with Wildfly will be plaintext.
Is it correct way to do it or I have done it by chance?
That's how it's usually done, yes. In other words: a load balancer and/or a proxy in front of Wildfly (Apache in your case). Wildfly itself is not reached directly by the public internet.
Does this method create a security hole?
It does, just like everything else is a security "compromise". In this case, you are trusting your internal network, in the name of a more practical/manageable architecture. If you do not trust your internal network, you should look for another solution. In the general case, the price to pay seems fair to me, as you'll "only" be open to a man-in-the-middle between your Apache and your Wildfly. So, if you trust your internal network, you should trust that there won't be any MITM there.
Edit
[1] - As everything else in life, there's no absolute truth. Basically, there are 3 techniques that can be used in a scenario like this: pass through, edge and re-encryption.
Pass through is a "dumb" pipe, where nothing about TLS is known by the proxy. Wildfly would then handle the secure communication with the client. I'm not sure Apache would do this, but this can be done with haproxy in TCP mode;
Edge (or offloading) is the situation I described above: Client talks TLS with Apache, Apache talks plaintext with Wildfly;
Re-encryption, which is like Edge, but the communication between Apache and Wildfly is also TLS, using a different certificate.
I've been wanting to setup a linux VirtualBox instance and use iptables to route traffic from other VMs through it and on to an external SOCKS proxy server. However, I have recently read that transparent proxies like this break HTTPS transmissions and that this is part of the design – to prevent man-in-the-middle attacks. If I want this to work, I'll need to configure the proxy inside the browsers of the VM clients for port 443. Are there any other options I could explore to achieve my goal?
To access a SOCKS server each TCP connection must be prefixed with the necessary SOCKS header. That means, that a simple redirect is not possible. You need instead a protocol converter like redsocks or transocks (never used these, but from the description they do what you need).
Apart from that it is not a problem to simply redirect HTTPS traffic or use these protocol converters, as long as you don't change the SSL stream itself. The only problem is if transparent proxies try to intercept and re-route this traffic to other sites (like redirecting to a capture portal) or try to decrypt the connection in order to analyse it (like in firewalls). These kind of interceptions will be noticed from the browser, because either the name in the certificate does not match the target name and/or the issuer of the certificate is not trusted.
I'm trying to set up a reverse proxy on Apache 2.2 (Windows). I am able to do it on a non-corporate network without any problems. I am attempting to reverse proxy content from a vendor domain, but keep it under my own domain for SEO reasons.
dev.example.com/stuff ===> devstuff.vendor.com
However, when I try to incorporate this on my internal network, the Internet Gateway proxy is blocking the request, presumably as I'm not properly authenticating the call to the external domain.
dev.example.com ===> Internet Proxy =X=> devstuff.vendor.com
I've been googling every term I can think of and reading the Apache docs and can't find anything which seems to work. I have tried running Apache as a service with a network account which would have access, but naturally, it's probably not trying to use the proxy at all.
Is there any way to tell Apache to send external ProxyPass requests to use a specific proxy server, and perhaps a specific username/password as well? I'd love to avoid modifying the proxy or firewall too heavily to accomplish this.
Thanks!
Never quite did figure out the "with passing credentials" part, but using the ProxyRemote directive, we could pass everything for our devstuff.vendor.com domain through our network proxy. From there, we had a proxy exception put in to allow from our web server IPs without authentication, since this was an approved arrangement anyhow.
Though, in hindsight, even after solving this, we ended up backing up one step further and just going straight out the firewall for performance reasons (both for the end user with too many hops) as well as negative impacts to our proxy server.
We've got an establish Apache/PHP site, with a Flash front-end. We're going to start to need to implement some sort of socket communication, or 'long-polling', to push updates to the flash app. Since this obviously isn't going to be a good situation for Apache, or PHP, I'd like to use Tornado for this aspect of the functionality, but I also don't want to run Tornado on another port, since the Flash app will be running on the client machine, we don't want to have to deal with restrictive firewalls blocking the socket connections.
Ideally I'd like to run a proxy which can forward most requests to Apache, and other requests to Tornado. I saw some suggestions for using Apache as the first-contact proxy, forward requests to Tornado when necessary, but I've also seen this discounts a lot of the async capabilities of Tornado.
I thought, why no use Tornado as the first-contact for port 80 and have it proxy back to Apache? I couldn't find anything on this at all and am wondering if this is even possible?
Another option would be to use something like lighttpd as the proxy and have it decide whether to pass things along to Apache or to Tornado, but does this kind of setup make sense? Or what about Nginx?
Any suggestions, advice or corrections on my understanding of things would be greatly appreciated!
This is called a reverse proxy and it's very easy to configure nginx to perform this. (lighttpd should also be able to do this job well, but I have no experience using it).
The tornado documentation has an example nginx configuration
One thing to note when using a reverse proxy is that the connection to your upstream server will now be originating from the proxy, not the client. The de facto standard is to put information about the original request in certain http headers. In the example from the tornado docs, the X-Real-IP header is set to the IP of the original client and X-Scheme is set to the scheme of the original request (http/https for example).
This may require some modifications to your upstream server. With tornado this is done by constructing the HTTPServer with the xheaders argument set to True. This will instruct the server to try and pull the IP address and scheme from the X-headers. Note that if you use this with a server that isn't behind a reverse proxy that sets the appropriate headers than you are open to IP Address spoofing.
I have an HTTP server which is in our internal network and accessible only from inside it. I would like to put another server that would listen to an HTTPS port accessible from outside, and forward the requests to that HTTP server (and send back the responses via HTTPS). I know that there are several ways to do this with some programming involved (and I myself made a temporary solution with Tomcat and a very simple servlet I wrote), but is there a way to do the same just plugging parts already made (like Apache + modules)?
This is the sort of use-case that stunnel is designed for. There is a specific example of using stunnel to wrap an HTTP server.
You should consider whether this is really a good idea, though. Web applications designed for use inside a corporate firewall are often fairly lax about security. Merely encrypting the connections prevents casual eavesdropping, but does not secure the site. If an attacker finds your outward facing server and starts connecting to it, they can still try to find exploitable flaws in the web service (SQL injection, cross-site scripting, etc).
With Apache look into mod_proxy.
Apache 2.2 mod_proxy docs
Apache 2.0 mod_proxy docs