Should i use secure sockets for my whole client/server application?
Hi,
I have a client server application, and I want to ensure that the login process is secure (i.e. use secure sockets). but I dont know how to switch back to a normal socket once that is done.
So I am left thinking that i should just use SSL for my whole application, which can last pretty long. But I would rather not. Is there any other way of doing this?
or should I just encrypt the login info using MD5 or something like that, then send it over an unsecure socket?
thanks!
[509 byte] By [
gmonieya] at [2007-10-1 11:45:32]
Hello again,
I'm not stalking you, I promise.
I'm guessing Kerberos was too trouble some for you? It certainly was for me - perhaps just ignorance, fear of the unknownon my part.
If however, you know enough about kerberos, then I strongly suggest using JGSS.
Warm regards,
Darren
Hi Darren,thanks for the reply. I looked into Kerberos a bit, then just seemed to get lost. I'll give it another shot though.
Hi Darren,
So I have read up on JGSS, and I am back to my same ol question. It seems that JGSS ensures that the whole connection is secure. Which, to me, indicates that this would be much slower than an unsecure connection.
My question is, how much is this gonna slow me down? If i have 1000 users, all interacting with 1 server, is JGSS gonna slow me down a lot vs. an unsecure socket connection?
thanks!
Hey,
Are you sure you haven't confused JGSS for JSSE?
Imagine you have a client-server system and you sometimes want data sent over the wire to be encrypted... JGSS offers you this flexibility; if you a encrypted transmission, run ift through JGSS before transmitting it; if you don't want an encrypted transmission, bypass JGSS and just send the transmission.
The benefit is the security (encryption) isn't hard-wired into you communications protocol i.e. TLS. JGSS has nothing to do with connections it is just protocol for securing messages, not sending them.
You would need to establish the secure context but this could be done at startup and persist for the duration of you applicaiton invocation. You perhaps might need to implement a mechanism to identify encrypted messages on the receiving peer (so it knows to attempt decryption).
Admittedly, kerberos seems like one of those 'inside-joke' things. I've come to realise if you don't have some sort of kerberos realm/server against which to authenticate - you need to swap it out as the underlying mechanism. How this is done I'm not sure yet, but I intend to find out today....further down the rabbit hole I go!
If I discover anything helpful, I will let you know.
Warm regards,
D
Hey, I'm back,
It seems that everyone is soooo happy with Kerberos, no one has bothered to implement/provide an alternative mechanism, atleast not Java anyway... so when you read, ... Kerberos v5 mechanism, which can be swapped out... you witness some one just spreading their tail-feathers.
So basically if you have a Kerberos KDC or passwrod change server (?) available or are prepared to make one available, I'm afraid JGSS is useless. I myself an quite dissappointed about this but such is life
...
I have just read through some of the Java Cryptography Extension (JCE) guide, it's quite interesting!
http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.html
You will have to get you hands dirty, but there is no need for a 3rd-party authenticator i.e. a Kerberos Server, and again it plays no role in data transmission, just encrpytion/decrytion.
SealedObjects are cool!; I've read some threads on people complaining about object-based access control... they obviously don't read enough; GuardObject, SignedObject and SealedObject are all on offer.
Anyway, there's half my day gone.
Goodluck - hope it helps,
D
D,thanks for the replies, I'll get to reading the cryptography extension soon. As you mentioned in your other post, that I could use JGSS for certain transmissions, and not for others. Could you point me to an example of this (Hopefully using ObjectStreams)?thanks!
Sorry,
You can't use object streams after encryption with JGSS - it handles data in the form of byte arrays so you would need to use DataXxxxStreams. Still you could abstract a layer that serializes objects to a ByteArrayXxxxStream, get the bytes and encrypt them and finally send.
In my last post I mentioned SealedObjects - these can be used within the JCE framework with you ObjectXxxxStreams. You pass you object and a Cipher object to the SealedObject.getInstance() method, which could then be written to a stream - simple.
As for JGSS guide:
http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/index.html
Warm regards.
Hi Darren,thanks for all your help. I took a closer look at the data I was sending across, and I found that the majority of it included some type of sensitive data. So it would just be easiest to incorporate SSL into my entire connection.
