I'm writing a server-client application where communication is done over the internet and I have several questions and concerns regarding security. I have done some research and found some posts here useful, but I would like more information. Some related questions I read were:
Secure authentication of client over RMI
java rmi authentication & security. exportObject makes it public?
Is communication in java rmi secure?
I have 3 parts to consider:
Information exchanged between the client and the server.
Authentication of the client.
Exploiting a running RMI server (hacking etc.).
What I know:
RMI over SSL. Using SSL sockets instead of the default socket would encrypt all information passed between the client and the server. This includes the objects exchange and method calls.
Authentication using username/password combination over SSL before RMI connection has been established. To my understanding there was supposed to be a way to authenticate inside the RMI connection but it was voted down.
Not too sure what can or needs to be done here. I do know that you can't just write your own client and ask to connect to the server since you need an ObjectID and the remote interfaces. However, is it not possible to decompile the classes \ interfaces you need since they are sent in RMI anyway? I also saw this Youtube video [http://www.youtube.com/watch?v=otjllNaBxiw] while researching and it got me worried with how easy it is, although I don't know if the server was not setup correctly.
All in all, are there other security issues I need to consider in RMI over the internet? Am I missing a solution I need to look at? Is what I already know wrong?
Information exchanged between the client and the server.
RMI over SSL.
Authentication of the client.
Authentication of the client is done by SSL. You mean authorisation, which is 'relatively' easy. Define your own RMIServerSocketFactory that returns an ServerSocket override whose implAccept() method wraps the socket in an SSLSocket, to which you add a handshake listener and set needClientAuth to true on it (and clientMode to false). Your handshake listener should then get and check the client certificate from the SSLSession, to see if the identity it authenticates is authorised, and simply close the socket if non-authorised.
Authorising the server, in the client, is on the other hand baroquely complex. You really need the JERI API in Jini to do it properly.
Exploiting a running RMI server (hacking etc.).
I won't go so far as to say it's impossible, but it's extremely difficult, and there are several strong lines of defence. You need the ObjectID, which is random, and can be made securely random, and you need the classes. Classes and interfaces aren't sent in RMI unless you specifically enable it, and they are sent by a side channel that you can secure arbitrarily strongly, for example with two-way-authenticated HTTPS. So you can't get those. Then you need to get yourself authorised, which basically requires compromising the server. And if that's possible, anything is.
Related
I'm coding a Chat system in java with an encrypted tcp connection.
I understand that I have to use SSL sockets, but besides that how would the code differ from a normal chat system without the encryption? So besides the SSL object, is there anything I need to consider?
Thanks for the help
SSL is a transport layer security protocol. it will ensure that your packets are not legible to an eavesdropper (man in the middle).
I would recommend you also incorporate your own application layer security for example to verify the person who you are talking to.
I am trying to work to secure a java based RMI service using SSL.
I have some basic questions about the capabilities of using SSL. Specifically, from what I understand, the client and server connecting via SSL will need to have appropriate credential certificates in both client and server, for a client to be granted access to the server. Am I correct in my understanding?
Also, what I want to know is, can a person who is already using my RMI service and has access to a client machine , make a copy of the certificate in the client machine to other client machines-- and then invoke my RMI service from those other machines as well?
How do I prevent such a situation from occurring? I mean, in a REST API you can use OAuth authentication, can we have some kind of authentication in an RMI Service?
Also, can I possibly limit usage of the RMI service? For eg, a specific client may be allowed to make only 5000 calls per day to my RMI service, and if he makes more calls the calls occurring after the 5000 calls limit are all denied? How do I do such rate limiting and/or authentication for my RMI Service?
Specifically, from what I understand, the client and server connecting via SSL will need to have appropriate credential certificates in both client and server, for a client to be granted access to the server. Am I correct in my understanding?
No. Only the server needs a certificate. The client certificate is optional.
Also, what I want to know is, can a person who is already using my RMI service and has access to a client machine , make a copy of the certificate in the client machine to other client machines-- and then invoke my RMI service from those other machines as well?
Certainly. Physical security of the certificates and the application is your problem. SSL can't solve it for you.
Also, can I possibly limit usage of the RMI service? For eg, a specific client may be allowed to make only 5000 calls per day to my RMI service, and if he makes more calls the calls occurring after the 5000 calls limit are all denied? How do I do such rate limiting and/or authentication for my RMI Service?
Code it yourself. Stick a daily counter in the database.
I intend to have .NET thick clients running inside a Windows domain connect to a Java server via a straight TCP connection (protocol will be custom Google Protocol Buffer messages). I'm looking at how I can authenticate these clients without requiring further credentials be entered by the users (in other words, support single sign-on).
My initial thinking was to use Kerberos, but I'm not even certain that it's possible or ultimately secure over straight TCP. Can anyone comment on this? Is it possible? Are there any examples out there of how to achieve this, both client-side and server-side?
Kerberos doesn't run over 'straight TCP'. It uses an encryption protocol. See the JGSS-API, built into the JRE.
I'm working on a school project with a server application that holds centralized data, and client applications that hold cached data that will be synchronized with sockets.
Everything is written in Java.
What is good practice?
How can I stop people from listening to my traffic? Or prevent people to understand what is said?
You simply use SSLSocketFactory instead of SocketFactory for your client server application. That way, the communication between the two will be totally encrypted. You can secure your client server app in less than a day, if you know basic Java. Here's a tutorial.
SSL is the standard practice. See the javax.net.ssl package, and the JSSE Reference Guide. But this may be beyond the scope of your project or your abilities at this stage. Check with your instructor.
I'm trying to implement a Web Anonymizer (like ktunnel) in java, but I really could not get the idea, I need some information about how a web anonymizer works. I really do not need the source or a sample application, just the idea or a tutorial explaining the anonymizer idea.
Thanks.
A basic anonymizer just acts as an encrypted proxy, creating an encrypted "tunnel" between a proxy server and a client, where all traffic from the client goes through the proxy. This accomplishes 3 things:
The client cannot* be determined by looking at traffic between the proxy and endpoint. Hosts on the other end just see the proxy server.
The content of a client's traffic is hidden from monitoring, because the connection to the proxy is encrypted.
It is impossible* to determine the endpoint for traffic originating from the client, because all of it appears to go to the proxy only.
*In reality, a simple anonymizer doesn't provide full protection, because if you look at the amount of traffic between client and proxy, and the traffic between proxy and various sites, you can associate a specific client with their traffic. This is called traffic analysis.
Fancier anonymizers, such as Tor, provide protection against traffic analysis and a lot of other techniques to break anonymity, BUT that's really beyond the scope of the question.
From your point of view, all that matters is writing the proxy software. Your program should be able to create and manage encrypted connections to clients. This means it needs to be able to (securely) initiate an encrypted connection to a host, pass on connections to external hosts, and then pass traffic back and forth. Basically, it needs to act as a router.
There are protocols in place for how to accomplish this -- I suggest you read up on the SOCKS protocol, or Tor. Your best bet if this is a learning project is to write basic SOCKS proxy software. If this is for actual use, there should be libraries in Java that provide the necessary services.
EdiT:
Ktunnel is a less fancy proxy -- it uses a CGI script to redirect information from a URL back and forth. Basically, you enter an address, it fetches the page for that address, and sends it to you. Fairly simple, actually.
I don't know ktunnel, but for basic information about anonymity networks have a look at Tor at wikipedia.