We Keep Coding

Best way to tunnel RMI over HTTP

I'm looking for a secure way to tunnel RMI traffic.
In My application(java Webstart) i must assume that the only port that is open is port 80.
I have the looked att socketfactories for rmi but do i really need a proxy then.
I need to do all my tunneling on the client side.
The only firewall i am trying to get past is on the client side.
I'm not able to open 1099 with port ranges above.
Would be nice to see some implementations.
Thanks!

Port 1099 was reserved for RMI at IANA in about 1995. There is no reason for it not to be open for outbound access in the client-side firewall.
RMI can be made to use fixed port numbers by supplying a port number when constructing (super(port)) or exporting (exportObject(object, port)). Better still, if you create the Registry within the server JVM via LocateRegistry.createRegistry(), all subequently exported remote objects will use that port unless they specify a different port or they use a server socket factory.
BUT ... RMI already includes HTTP tunneling 'out of the box'. No external solution required. You have to deploy the RMI-Servlet provided with the JDK, at the server end.

(a)
although not the newest fashion, exposing remote services with Hessian and Burlap seems to be a simple solution to avoid problem working across firewalls: http://hessian.caucho.com/doc/
see sample code for the server and client side:
http://www.javatpoint.com/spring-remoting-by-hessian-example
(b) or consider using Spring HttpInvokder (see some sample code here: http://www.javatpoint.com/spring-remoting-by-http-invoker-example)
HttpInvokder provides more customization options through the RemoteInvocationFactory, RemoteInvocationExecutor and HttpInvokerRequestExecutor strategies (for example, to add custom context information (such as user credentials) to the remote invocation, or using java’s built-in object serialization etc.), see:
http://docs.spring.io/spring-framework/docs/2.0.x/api/org/springframework/remoting/support/RemoteInvocationFactory.html

Simulating slow/lossy communication in java

I need to test a functionality internal to my company's server whose benefit is evident only when clients run slow (as of latency and packet loss). To that extent, I need to simulate clients on a slow and/or lossy connection (TCP/HTTP). I'm using a Mac, Mountain Lion, and ideally I'd need to run both server and client locally.
One approach I tried to pursue -- unsuccessfully -- was to get hold of some java APIs that allow me to build clients with slow connections. I know JMeter has got something called SlowSockets (or something similar), but I was looking for APIs more focused on slow-performing clients. Any ideas of useful APIs?
Another approach I tried consisted in using a proxy to act as a middleman between client and server. In that case, the proxy should provide functionalities for simulating slow links. I've tried Charles proxy (Mac) and Apache TCPMon, however I seem to miss something when I try to get them at work. With TCPMon, for instance, when I start it in 'Proxy' mode (which is the mode that offers the 'simulate slow link' functionality) I define port for the local proxy, but I can't see how to define the remote host and port. Something similar happens with Charles Proxy; I can set the local port in the Proxy settings, but I can't understand how to define the remote end of the proxy (in fact connections fail saying the remote server is not responding). Anyone having ideas what I'm doing wrong?
One further approach I have tried to pursue is by using lower-level (e.g. OS-based) means; in this case, I tried Apple's Network Link Conditioner. I switched it on and defined my slowness parameters, but when I ping I don't seem to see the expected RTT etc. I've got a feeling NLC has a tight relationship with XCode and iOS testing, anyone capable of putting it at work for testing other (e.g. Java) applications? I've also tried ipfw on Mac, however the manual says ipfw is now deprecated and I don't want to dedicate time to get to know a tool that won't be available soon.
Any idea/help will be highly appreciated.
Thanks in advance.

Use something else than JDBC over firewall

I have simple server-client application that uses JDBC to connect to database and things works ok. Application does few simple things with JDBC connection (get data, insert new line and few others).
Now, I would like to keep the same application but use it outside of firewall - so, I would put something else on some host:port (and open that port to outside world) - instead of JDBC opening database access directly.
I guess that this problem is faced many many times and sure there are a lot approches.
One way can be doing servlet on one side, accessing it on client side.
I guess, I haven't touched Spring yet, maybe another would be to do POJO Java Class and using Spring configure it as http service.
I have heard also "rumors" that Jetty has something that can help in this case (to minimaze coding on server and client side)
I would prefer something that:
- is not complicate (easy learning path)
- reuse something that is already done.
What approach would you recommend ?
Thank you and regards,
Igor

The normal approach would be to implement a web service, which can be pretty easy these days with Axis etc.
You really don't want to open direct JDBC to clients outside a firewall by tunnelling over HTTP... the server should strictly control what kind of interaction takes place with the database.

I would recommend using something like SSH tunnels to carry your JDBC connections through the firewall. Set up a tunnel on the DMZ machine on whatever publicly open port your can, and connect the other end of the tunnel to the appropriate port on the DB server.
Then just change your JDBC connection settings to connect to the tunnel machine's public port and it will transparently end up communicating with the database as usual, while passing through the firewall via the accepted port.
If this is an IT policy problem, in that they won't let you directly access the database, then you would need to work out what you are allowed to do and work with that as far as possible. Changing JDBC to another access method is unlikely to be acceptable to the IT policy in this case.
Edit: after reading Jon's answer, he may be right. I was assuming that the issue was the connection between your server/webapp, and the database server. If you were talking about the client creating direct JDBC connections to the database, then yes - firewall or no, this is very bad practice. The client should talk to your server to ask for what it wants, and your server should do the DB queries as required to get the information.

I think that would just be an unnecessary complication. Your DBMS (usually) brings access control and transport layer security. If you introduce your own layer, are you sure that you can make it safer than a direct connection to the DB?
I see your rationale, but if there isn't a framework to do this, avoid building your own! For example, PostgreSQL comes with a bunch of nifty options to tie things down. For example, require SSL certificate-based authentication on the transport level (clients must present a cert that the server checks), or IP-based access.
Of course you still have to trust your DBMS implementation to get basic details like access control right (= "uncrackable"), but you still need to rely on this anyway after the black hats have broken into your web-proxy ;)
#dtsazza: Maybe edit your answer to include the keyword "VPN"? ssh tunnels probably scale badly outside of a private setup.
Volker

Java Socket Programming behind proxy

I have written a TCP IP socket program which works fine.
But my socket program did not work if my server or client is behind proxy.
So how to overcome from this type of issue.
Thanks
Bapi

Well there's two issues to consider:
Behind a proxy; and
Behind a firewall.
Firewall tends to be easier: you simply use port 80 (HTTP) or 443 (HTTPS). Proxy is harder because direct network communication tends to be disabled from normal PCs.
This is why you often find people using HTTP and/or SSL as their transport mediums because they bypass these kinds of security issues. You can do push content (with long-lived connections aka Comet techniques) so there's typically no real technical reason not to.
But it's hard to say one way or the other if that's a good idea or not without knowing more about your application and any pertinent requirements.

Proxies usually work at the application level, not at the transport level.
Here is some information about Java and proxies.

Depending on the proxy, there may be little that you can do. If the Proxy is designed to block all traffic that it does not directly handle, then you have to either go through the proxy, somehow working with it, or you have to find a way to sneak through the proxy.
For example, many applications are built on top of HTTP precisely because it is commonly allowed through firewalls and is commonly proxy-friendly. Thus, it's a pretty safe way of communicating when you know that you'll be installing the application in environments where proxies may exist.
In your case, it depends on what port(s) your application uses, on whether these ports are commonly handled by a proxy for any existing protocol, on whether or not you're using a standard (commonly known) protocol or have invented your own, and so on.
Is this proxy a transparent proxy? (That is, do web browsers have to be configured to see it, or not?) The kind of proxy it is determines part of how your application needs to work with it. Is the proxy controlled by your organization?
You say you are using port 5018. Just as an experiment, can you try using port 80? Just because you're using port 80 doesn't mean you have to use HTTP. This is worth a try to see if it helps.

How to use RMI with applet client behind a firewall?

How can I use RMI with a applet client behind a firewall?
How can I use RMI with a firewalled server and firewalled applet client? (If possible)
I know that the RMI server uses port 1099 (by default, but this is configurable); however after this the communication requires a new socket on a different random port. I also know that you can set the proxy on the client for RMI over HTTP tunneling which in theory should solve my issue. But I can't make it work (I tried setting the environmental properties on my XP client, but Internet Explorer keeps ignoring them).

See http://java.sun.com/javase/6/docs/technotes/guides/rmi/faq.html#firewall

If the servers code is in your hand you could also restrict RMI to use a predifined port by providing a custom RMISocketFactory as described here: http://insidecoffe.blogspot.com/2012/02/firewall-friently-rmi-port-fixing.html
(Note specially the hint that it may cause problems if you use JMX in parallel)

Have not looked into it to deeply my self yet, but while looking around for a project I am currently doing I came accross LipeRMI.
You might want to have a look at it as it geared towards internet usage and mentions "shadow the clients in such way they can be behind a local network, router or firewall;"
Edit:
Remembered another implementation I came across a while back called RMI Doves 1.0: Solution for Java RMI firewall problem you might want to have a look at that one as well.

in your Server put the code like this:
RmiInterface stub = (RmiInterface) UnicastRemoteObject.exportObject(rmi, 35400);
LocateRegistry.createRegistry(1099);
Naming.rebind("//192.168.102.128:1099/rmi", stub);