SSL architecture

[Jean-Michel Vilain]

We've just added SSL over our home made protocol and it works great.
Now I'm looking to enhance our architecture and use SSL the least possible. The application is a sort of MMO game and the password is by far the most critical thing. But if only the authentification is encrypted, then a hacker could still intercept the rest of the protocol.
I've heared there's a strategy where a token is generated during the authentification and then that token must be used by the client for the whole session. I'm sktipcal about that strategy because I fear a sniffer could get the token and use it.
Anyone with a clue about this would be really welcome! Thanks.

[Ulf Dittmer]

If SSL works great, why are you looking to replace it with something homegrown?

[Jean-Michel Vilain]

I just meant the resulting strings transiting over the sockets were well encrypted.
I have been told that SSL represents heavy computations, I have started this topic only because I'm only worried about the performances, we simply don't want to ruin our service because SSL is eating all of our CPUs.

[Ulf Dittmer]

OK, so it's potentially about optimization. That only makes sense if you have solid numbers to base that on. How much of an overhead does SSL introduce? Is that acceptable? If not, how much overhead would be acceptable for secure communication? And last but not least: what is the threat model? Meaning, what kinds of attackers and attacks are you trying to guard against?

[Jean-Michel Vilain]

Exactly, thanks for your reply.
I have a hard time answering to your last two questions, my hacking culture is almost non-existent. The most conservative approach would be to have all messages secured.
I was curious to know if there's a typical approach to this problem, thus using SSL only for the authentication plus a simple trick to protect the rest of the session. Listening to you makes me think there's no other way; it's SSL or tinker your own stuff.

[Ulf Dittmer]

it's SSL or tinker your own stuff.

I think that's a fair description. There are approaches using tokens like you mentioned, but there is no entirely simple way to implement those securely. So the tradeoff is between a) leaving things as they are and potentially having to scale sooner, and b) investing development effort into something more performant, but which might not guard against as many attacks (since not everything is encrypted). But to make this decision you really have to know what kind of overhead SSL introduces. Before you can put a number on that, it's moot to decide on this. In my experience, adding SSL to an entire application (instead of just selected pages like login and payment) has a negligible impact on performance. Of course, YMMV. (And it goes without saying that SSL needs to be made secure - the Poodle and HeartBleed attacks as well as turning off obsolete ciphers/digest algorithms are things to look into.)

[Jean-Michel Vilain]

In any case you're right, I should first try to know what's the overhead cost of SSL.
I think the reason why I'm reluctant to use 100% SSL is that all client operations are processed via a unique scheduler, I did that to get rid of non-deterministic issues. And that caused no problem because every client operation in the logic involves very little algorithmics.
Given the way the scheduler works, its whole queue would be delayed each time a heavy SSL manipulation is computed, that means each client doing a simple operation would have to wait a bit for each other operation ahead of him in the queue. I'm afraid of the result.

[Ulf Dittmer]

What is an "SSL manipulation"? Are you saying that you're not using SSL on the communications channel (like HTTPS does), but for smaller instances of data sent over an unsecured channel?

The usual approach would be to use SSL for the entire channel, and to terminate (meaning, remove) it before it ever reaches the app server, possibly in an Apache that is in front of it.

[Jean-Michel Vilain]

Correct, I'm talking about not using SSL to communicate smaller instances of data. It's a game, so you can imagine the quantity of gameplay data that transits from the client to server and vice versa.

(By manipulation in fact I just meant hashing, encrypting,... anything that costs CPU.)

So the usual way is to terminate the SSL socket before handling things to the app server. Okay, I'd really like to dig into that and study which strategy I could implement, but I just don't know where to start/search.
By the way thanks a lot for your help, it's people like you that make this forum an awesome place for discussing about Java.

[Ulf Dittmer]

So the usual way is to terminate the SSL socket before handling things to the app server. Okay, I'd really like to dig into that and study which strategy I could implement

The most common case is probably a web app running on a servlet container like Tomcat, and then to put an Apache httpd server in front of that. In that case the client communicates only with the Apache, which terminates the SSL, and then forwards the traffic to the Tomcat unencrypted. It might also provide load-balancing and/or failover for the Tomcat(s), but that is independent of the SSL setup. Documentation on connecting Apache to Tomcat can be found at http://tomcat.apache.org/connectors-doc/

By the way thanks a lot for your help, it's people like you that make this forum an awesome place for discussing about Java.

You're welcome. Security is dear to my heart, so I like to dig into it.