I'm creating a client-server application which communicates via a custom socket protocol. I'd like the client to be usable from within networks that have a restrictive firewall (corporate, school, etc.). Usually this is done by connecting via HTTP, since that's always available.
If I want to do that, do I really have to use HTTP or is it enough to use my custom protocol via server port 80?
The firewall may have more restricted checks than just restricting ports, and you might also have proxies along the way, and they will deal in HTTP.
Still, using a well-known port for something other than its normal use is still far better than so many schemes which do inherently non-HTTP stuff over HTTP, and essentially implement RFC 3093 (when people implement April Fools RFCs it normally shows a combination of humour and technical acumen, RFC 3093 is the exception).
To get around the proxy issue, you could use 443 rather than 80, as HTTPS traffic can't be proxied in quite the same way. Indeed, you often don't even need to use SSL, as the proxy will just assume that they can't see it.
None of this needs to be done with your application though. What your application needs to do is to have its port be configurable (that should be done with any server application anyway). The default should be something away from well-known ports, but the sysadmin will be able to use 80 or 443 or whatever if they need to.
If it is a custom socket protocol then it is not HTTP.
But you can still use TCP on port 80 to escape the firewall but then you would have to handle the proxy situation as well. Proxies are HTTP aware and custom TCP might not work and they probably would not forward your requests.
I do not know about the reasons you want to do this (if it is legal or not) but there are software that are used to bypass the filtering in countries such as Iran. One of the softwares (Haystack) uses a sophisticated encryption to masquerade the request as an innocent looking packet.
You would be better off investigating tunneling with SSH. It is designed for precisely this. An HTTP proxy isn't likely to work for a number of reasons including those given in the other answers.
Related
I need to use http health checks on a Elastic Beanstalk application, with proxy protocol turned on. That is currently not possible, and the health check fails with a an error --> *58 broken header while reading PROXY protocol
I figured I have two options
Perform the health check on another port, and setup nginx to listen to http requests on that port and proxy to my app.
If it is possible to catch the broken header errors, or detect regular http requests in the proxy_protocol server block, then redirect those requests to a port that listens to http.
I would prefer the latter(#2), if possible. So is there any way to do this?
Ideally, I would prefer not to have to do any of this. A feature request to fix this has been submitted to AWS, but it has no ETA.
The proxy protocol specification says:
The receiver MUST be configured to only receive the protocol described in this
specification and MUST not try to guess whether the protocol header is present
or not. This means that the protocol explicitly prevents port sharing between
public and private access. Otherwise it would open a major security breach by
allowing untrusted parties to spoof their connection addresses.
I think this means that option 2 is a sufficiently bad idea that it's not even supported by conforming implementations of the proxy protocol.
Option 1, on the other hand, seems pretty reasonable. You can set up a security group so that only legitimate health checks can come in on the port without proxy protocol enabled.
Another couple of options spring to mind too:
Simply point your health checks at the thing that's adding the header (i.e. ELB?), rather than directly at your Nginx instance. Not sure if this is possible with Elastic Beanstalk, it's not a service I use.
Use something else to add the proxy protocol header before forwarding the health-check traffic on to your Nginx, which would avoid having to duplicate your Nginx config. For instance a HAProxy running on the same machine as your Nginx could do this. Again, use security groups to ensure that only legitimate traffic gets through.
we need to protect our webservices with SSL (https) or any other security mechanism. Our problem is that current clients (delphi exe's) have references to our http webservices fixed in code and can not change that code.
I've tried to implement URL redirection rule from http to https but that didn't work because of the "hand shake"...Changing client to use https reference did work but saddly we can not do that for every client.
I know this question is in contradiction with encription theories but i'll fire this question anyway if anyone has any type of suggestion/idea to at least make connection or data transfer more secured (either with or without SSL protocol) without changing client side.
Thanks,
Luke
You need some kind of transparent TCP tunneling software/hardware on the clients, so the encryption occurs without the delphi clients noticing it.
My Google search using "transparent encrypted tunneling" keywords got this vendor of such solutions. There's must other vendors with similar solutions.
This is really an networking question.
PS.: hardcoding the URL is the real problem here. After the tunneling palliative is done, change that because this really will cause more headaches in future.
The client will be connecting over a port (non SSL) that will need to remain. What you could possibly do is that if you allow access both http and https you could possibly only allow http from specific IP addresses if you know them? its still not secure, but least you know where the calls are coming from and can do something about that?
Suppose computer A sends an HTTP request to a server B, and B wants C to answer it. Is it possible for C to send a response back to A without B intervention and without specific actions from A (as with a 3xx redirection)? Suppose C may not have a public IP address.
That's what a reverse proxy would do. Depending what platform you are on, there are a lot of options.
One way that works on many platforms is e.g. node-http-proxy that you could start on server B. In the most simple case, this one-liner would do:
require('http-proxy').createServer(81, 'serverb').listen(80);
It listens on port 80 and redirects to port 81 on serverb.
See https://github.com/nodejitsu/node-http-proxy for more options.
Of course, there are lots of well-established proxies with a lot more bells and whistles (although node-http-proxy can do https tunneling etc. as well), but configuring those can be more challenging that running this one-liner. It all depends on your use case.
Edit: Reading your comment, this can be done using direct routing. Your question is about HTTP (layer 7), and as direct routing works on a lower layer, higher-level protocols like HTTP work as well. Quote from http://horms.net/projects/has/html/node9.html:
Direct Routing: Packets from clients are forwarded directly to the
back-end server. The IP packet is not modified, so the back-end
servers must be configured to accept traffic for the virtual server's
IP address. This can be done using a dummy interface, or packet
filtering to redirect traffic addressed to the virtual server's IP
address to a local port. The back-end server may send replies directly
back to the client. That is if a host based layer 4 switch is used, it
may not be in the return path.
I would like to know how "realistic" is to consider implementing an intercepting proxy(with cache support) for the purpose of web filtering. I would like to support also IPv6, authentication of clients and caching.
Reading to the list of disadvantages from squid wiki http://wiki.squid-cache.org/SquidFaq/InterceptionProxy that implements an intercepting proxy, it mentions some things to consider as disadvantages when using it(that I want to clarify):
Requires IPv4 with NAT - proxy intercepting does not support IPv6, why ?
it causes path-MTU (PMTUD) to possibly fail - why ?
Proxy authentication does not work - client thinks it's talking directly to the originating server, in there a way to do authentication in this case ?
Interception Caching only supports the HTTP protocol, not gopher, SSL, or FTP. You cannot setup a redirection-rule to the proxy server for other protocols other than HTTP since it will not know how to deal with it - This seems quite plausible as the way redirecting of traffic to proxy is done in this case is by a firewall changing the destination address of a packet from the originating server to the proxy's own address(Destination NAT). How would in this case, if i want to intercept other protocols besides http know where the connection was intended to go so I can relay it to that destination ?
Traffic may be intercepted in many ways. It does not necessarily need to use NAT (which is not supported in IPv6). A transparent interception will surely not use NAT for example (transparent in the sense that the Proxy will not generate requests with his own address but with the client address, spoofing the IP address).
PMTUD is used to detect the largest MTU size available in the path between the client and server and vise versa, it is useful for avoiding fragmentation of Ip packets on the path between the client and server. When you use a Proxy in the middle, even if the MTU is detected, it not necessarily the same as the one from the client to the proxy and from the proxy to the server. But this is not always relevant, it depends on what traffic is being served and how the proxy is behaving.
If the proxy is authenticating in the client behalf, it needs to be aware of the authentication method, and it will probably need some cookies that exist in the client. Think of it this way... If a proxy can authenticate an access to a restricted resource on your behalf, it means anyone can do it on your behalf, and the purpose of a good authentication is to protect you from such possibilities.
I guess this was a very old post from the Squid guys, but the technology exists to redirect anything you want to a specific server. One simple way to do it is by placing your server as a Default Gateway for the network, then all packets pass through it and you could redirect the packets you like to your application (or another server). And you are not limited to HTTP, BUT you are limited to the way the application protocol works.
I want a cloud machine to send a message to a machine behind a corporate NAT / Firewall.
My idea is to install on the corporate machine a client which sends a long HTTP request to the cloud machine and when the cloud has a message it returns the response.
I thought I invented the wheel until I read about "http tunneling" (is this what I am doing?).
I also read that some firewalls block non html traffic even if it is on http.
So what is my chance to make it work?
I have also read that skype uses a more sophisticated machanism.
Is it because my idea does not work or because their idea is faster?
I can compromise on speed now - which approach works and easy to implement?
I know you'd like to do it with TCP/HTTP,
but the way I'd do it is use UDP to
NAT 'hole punch', thus establishing a UDP channel,
and then use UDP packets sent over that
channel as the signaling mechanism...
These may (or may not) be useful or relevant:
http://en.wikipedia.org/wiki/STUN
http://en.wikipedia.org/wiki/Hole_punching
http://en.wikipedia.org/wiki/UDP_hole_punching
http://en.wikipedia.org/wiki/TCP_hole_punching
Also -- if you really have to use HTTP, you could
simply issue a new HTTP request every X seconds...
HTTP Polling, if you will...
If they block non html on port 80, you could try port 443. Unless there is a SSL "man in the middle" proxy (unlikely), you'd be ok.
IIRC skype uses port hopping, so basically you'll need an algorithm to find an unfiltered (by brute force with intelligent guesses) port that you can connect to.