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.
Related
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.
As we now, a .jar file, we can open it and see the code and classes with any decompiler. Now suppose the following situation:
I developed a Client-Server application under JAVA, in both Client and Server, i used AES-256 for encrypting the data sent over internet. So, i give the "Client" to my friend. Now.. The question is... can he hack my Server knowing how are the packets received in the Client, treated, and sent back? I mean... encrypting the data when you have a revealed code, it's.. in vain, doesn't it?
The question is... what can i do to have the best security possible in the Server? does encryption work in this case ?
Thanks !!!
Don't use encryption just to hide how your client-server protocol works. If you want your server to be secure, make it secure even when the client is in full control of what goes on.
As you've mentioned, it's easy to control the client: not just via decompilation, but also by running the client in a debugger (which can modify the contents of any object, modify control flow, etc.).
My points, then, are:
It's important to identify where the potential attack vectors are in your server, and address those. For example, if you want to be able to send a cookie to a client, which you want them to send back unaltered, you don't need encryption for that; just use HMAC.
If you actually really want to encrypt traffic between client and server, don't use straight AES (especially because it sounds like you're using a fixed key, which is insecure). You want to use a protocol designed for wire encryption, like TLS (SSL). Yes, really use TLS (including acquiring a certificate from a certificate authority); don't take shortcuts.
The nice thing about TLS is that there are no shared secrets (such as keys) that you have to embed into your jar. So there is nothing you have to worry about hiding.
If by him hacking your server you mean him meaning figuring out the protocol and contents of the packet that goes in, and then sending funky packets to make your server do unexpected things at unexpected times, the solution seems to be not as much encryption but strong validation. That is, your server should expect only a limited set of values in the incoming packets at each step of your protocol, and if some of the incoming packets do not conform to this/attempt to do something unexpected, they should be discarded.
Your encryption is not going to allow you to hide the protocol/API/etc. that the client and server use to communicate with each other. By encrypting the data flowing between the client and server, you are preventing someone that is observing this traffic as it passes across the wire (presumably the internet) from snooping on the data.
One issue to keep in mind is that AES requires a password that is know by both the client and the server. If your password is hardcoded in the jar, then anyone that has the jar can snoop on any traffic between your server and anyone's client that connects to it. So, you need a secure way for the client and server to agree on the password to use for a given connection.
I suggest using an SSL-based technology for encrypting the data going on the wire (e.g., maybe you can simply use HTTPS as your protocol). Or perhaps use public key encryption.
It is hard to make a specific recommendation, given the lack of information about the communication pattern between client and server.
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.