0

I have used the client/server chat example to implement my SSL requirements. The main part of my requirement is session management.

I want to:

  • Create SSL (TLS) "tunnels" from my clients to the server
  • The SSL tunnel (channel) will only be opened and available, when specific requirements are fulfilled. Otherwise, the channel and hence the connection will be closed immediately.
  • To check, if the requirements are fulfilled. The plan is, that the client sends an ID to the server. The ID will be for example assembled using the client-PC-ID, Username, IP-Address, Timestamp, etc. This ID can be used as the channel ID and as a Client-Sesion-ID, so that the server can locate/track/identify the user.

When creating an SSL connection, once the configuration is created, I am executing the handshake() method. The connection is then created and a random Integer is used as the Channel-ID. So, on the server side, I have the IDs of the clients and can send messages to them. But, I want to have my own unique IDs, which I can also use as session IDs. And most importantly, the clients will create these IDs and "login" using them. So I want to decide on the server side - using the ID created by the client - if the TLS tunnel (channel) will be opened (logged-in) or not (no-access-to-log-in). This needs the client to send the self-created unique ID during the handshake, doesn't it?

Once the client has sent a valid ID, the server should check, if the SSL-Certificate is valid, and so on. But this is the next step.

So, the question is, how can I use an ID sent by the clients? Or is this not possible? Or is it maybe not required? Or maybe it does not make any sense?

Any ideas on that?

Ivan Ferić
  • 4,725
  • 11
  • 37
  • 47
ALtheViZ
  • 1
  • 2
  • To simplify the question, you want to send a custom data during SSL handshake phase and to let the server fail the handshake if the validation of the custom data fails. Correct? If so, why don't you just send the custom data (client ID in your case) *after* handshake is successful? – trustin Jan 10 '13 at 05:28
  • Yes, that's what I want to do. After the handshake, the server uses an internal randomly generated ID as the "session id". Of course, I could associate the id with a channel in a Map, but that seems like a workaround. On the other side, I will provide this functionality to many different clients. I don't want to tell them, that they have to send a special id after the handshake. – ALtheViZ Jan 11 '13 at 13:24
  • Actually, I could imagine havein something like this: - The client makes a handshake and it send a certificate, which contains all the data needed to be able to open the connection and remain open, because the authentication was OK. - From the certificate, the needed information can be extracted (but how?) – ALtheViZ Jan 11 '13 at 13:29

0 Answers0