lobby server<->client protocol encryption

lobby server<->client protocol encryption

For the discussion of infrastructure improvements and changes.

Moderator: Moderators

abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

lobby server<->client protocol encryption

Post by abma »

kloot wrote some code which adds (optional) encryption to the lobby server protocol:

https://github.com/spring/uberserver/pull/119/files

here is some description:

https://github.com/spring/uberserver/co ... c347233ee4

thoughts about this?

basicly it allows to enable/disable encryption from client at any point. to make it work clients have to support it, too. also user password is stored in a safe manner.

seems its not fully working yet, but i think i can fix it.
MetalSucker
Posts: 98
Joined: 22 Sep 2014, 20:29

Re: lobby server<->client protocol encryption

Post by MetalSucker »

It's amazing except that any server public key can be injected thus defying the purpose.
SirMaverick
Posts: 834
Joined: 19 May 2009, 21:10

Re: lobby server<->client protocol encryption

Post by SirMaverick »

Clients should save the public key to signal changes to the user (either by server change or MITM attack).
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: lobby server<->client protocol encryption

Post by gajop »

This is unsafe:

passwords for all newly registered accounts using a secure connection according
to the protocol below are now stored as HASH(PASSWORD + RANDSALT) where RANDSALT
is a 16-byte random string unique per user and HASH is SHA256

Please use bcrypt or scrypt instead, there are python implementations available so using that is a few lines at the most. All in all, great work kloot, good to have you back!
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: lobby server<->client protocol encryption

Post by Kloot »

GETPUBLICKEY is only provided for convenience.

The public key should be published to some "trusted" location (to avoid any discussion on the tangled mess that are certificate authorities and trust chains, let's call this springrts.com for now) for lobby clients to grab over HTTPS which would eliminate MITM's, but I predict that getting clients to adopt this protocol will be enough of a challenge.
gajop wrote:This is unsafe:
If you have a bunch of spare bitcoin miners to throw at the DB, yes.

Also, it is actually HASH^1024 (at the moment) instead of HASH. The *crypt's were already on my radar however.
Last edited by Kloot on 21 Nov 2014, 12:48, edited 4 times in total.
MetalSucker
Posts: 98
Joined: 22 Sep 2014, 20:29

Re: lobby server<->client protocol encryption

Post by MetalSucker »

hardcode the sig in the clients
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: lobby server<->client protocol encryption

Post by abma »

MetalSucker wrote:hardcode the sig in the clients
the public should be thrown into the uberserver git repository and clients should store it the first time it connects (or hardcode it to the source code, not sure if thats good).
User avatar
cheapsheep
Lobby Developer
Posts: 69
Joined: 31 Dec 2011, 16:42

Re: lobby server<->client protocol encryption

Post by cheapsheep »

excellent joke.
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: lobby server<->client protocol encryption

Post by abma »

cheapsheep wrote:excellent joke.
Thats felony 1 & 2. What do you mean? whats wrong? what can be done better?

please learn to give constructive critism.
User avatar
cheapsheep
Lobby Developer
Posts: 69
Joined: 31 Dec 2011, 16:42

Re: lobby server<->client protocol encryption

Post by cheapsheep »

I don't understand exactly what this is supposed to solve, but lets pretend I do.

Protocol is not very clear... I'd have to read the code. Because "shared key" is meaningless... a key that isn't shared doesn't have much value. I'd rather have the key named "session key" so I don't have to dig in the code to find if the key persists between sessions or not... which would open many other questions.

I don't understand why a standard solution wasn't chosen. Something that has libraries for every language, where you can find hardware accelerator if you need it, that provide certificate revocation... that allows you to trust a certificate authority that can sign certs for various servers (dev, test, ...) and not bother the users with accepting each certificate (ie. not train them to close the warning popup as fast as possible).

I don't think forcing lobby devs to write more code will make the system as a whole more secure. I know people writing servers are not responsible for client code. But IMO, not considering what *will* happen is not good. This also has a side effect... more effort invested into client means more resistance to change.

I don't understand why nobody is asking for example, how is this solution compared to TLS? The only explanation I have is that everyone knows why TLS has been discarded or people are afraid to ask. This makes me uneasy and cynical.

I don't understand how security features can be optional, when they are the only function providing basic utility. Anyone willing to take a bet that someone will soon brag about his client implementation of this "security layer"... despite not implementing optional features?

I don't understand how this is helping one of the major authentication problem... authentication by a third party. None of this is helping secure me if I no longer want to trust ZK infra with my user/password. This protocol change doesn't seem to help there.

Finally, I'm puzzled by the comments in the code, not yielding much confidence. They say the security system can leak data and crash the server. Am I foolish to believe the comments?
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: lobby server<->client protocol encryption

Post by abma »

cheapsheep wrote:I don't understand exactly what this is supposed to solve, but lets pretend I do.
then you should ask and not assume wrong things.
cheapsheep wrote:I don't understand why a standard solution wasn't chosen.
it is a standard solution! read CryptoHandler.py, it uses AES for encryption
cheapsheep wrote:I don't think forcing lobby devs to write more code will make the system as a whole more secure. I know people writing servers are not responsible for client code. But IMO, not considering what *will* happen is not good. This also has a side effect... more effort invested into client means more resistance to change.
atm its optional. how to make it more secure without adding encyption?
I don't understand why nobody is asking for example, how is this solution compared to TLS? The only explanation I have is that everyone knows why TLS has been discarded or people are afraid to ask. This makes me uneasy and cynical.
this question goes to kloot. imo this solutions is more lightweight as only one specific encryption is allowed, not the full stack of tls encryption which is afaik AES/Tripple DES/DES with a LOT of options (compression/keepalive/etcetc)
cheapsheep wrote:I don't understand how this is helping one of the major authentication problem... authentication by a third party. None of this is helping secure me if I no longer want to trust ZK infra with my user/password. This protocol change doesn't seem to help there.
i guess this change will lock out "secured" logins from zero-k infrastructure. idk if its possible to make zk's infrastructure secure as well. afaik they store the username & password as well (which sucks if they do).

cheapsheep wrote:Finally, I'm puzzled by the comments in the code, not yielding much confidence. They say the security system can leak data and crash the server. Am I foolish to believe the comments?
details? it shouldn't crash the server. if it does, its a bug and will be fixed.
MetalSucker
Posts: 98
Joined: 22 Sep 2014, 20:29

Re: lobby server<->client protocol encryption

Post by MetalSucker »

Maybe the whole thing could be rewritten as an xmpp extension, thus benefiting from already very stable implementations, plugins such as openid integration http://wiki.xmpp.org/web/JabberID_and_O ... ile_export and lots of nifty stuff.

I know this is borderline trolling.

Also useful (I don't think it's ready yet, basically free certs) https://letsencrypt.org/
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: lobby server<->client protocol encryption

Post by Kloot »

cheapsheep wrote: Protocol is not very clear... I'd have to read the code. Because "shared key" is meaningless... a key that isn't shared doesn't have much value. I'd rather have the key named "session key" so I don't have to dig in the code to find if the key persists between sessions or not... which would open many other questions.
"session key" is the internal name.

It persists until a client issues another SETSHAREDKEY, but not across disconnects assuming the server properly cleans up dead clients.
I don't understand why a standard solution wasn't chosen. Something that has libraries for every language, where you can find hardware accelerator if you need it, that provide certificate revocation... that allows you to trust a certificate authority that can sign certs for various servers (dev, test, ...) and not bother the users with accepting each certificate (ie. not train them to close the warning popup as fast as possible).
Because this is a tiny RTS engine project in the middle of nowhere, not a government bank or agency tasked with protecting state secrets that can deal with the hassle brought by certificates.

Also, I hear trusting e.g. OpenSSL might not be such a good idea these days.
I don't think forcing lobby devs to write more code will make the system as a whole more secure. I know people writing servers are not responsible for client code. But IMO, not considering what *will* happen is not good. This also has a side effect... more effort invested into client means more resistance to change.
Capable lobby devs that consider security important will know what to do, the protocol isn't rocket science. Perhaps I should be more pessimistic like you though?
I don't understand why nobody is asking for example, how is this solution compared to TLS? The only explanation I have is that everyone knows why TLS has been discarded or people are afraid to ask. This makes me uneasy and cynical.
This thread is one day old.

TLS can always be enforced later if the simple solution is found insufficient.
I don't understand how security features can be optional, when they are the only function providing basic utility. Anyone willing to take a bet that someone will soon brag about his client implementation of this "security layer"... despite not implementing optional features?
You have a really depressing way of interpreting things.

"Optional" only means a client can choose not to perform a step. If the client has user security in mind it won't skip any, but who you gonna call?
I don't understand how this is helping one of the major authentication problem... authentication by a third party. None of this is helping secure me if I no longer want to trust ZK infra with my user/password. This protocol change doesn't seem to help there.
I neither know nor care about ZK (or any other third-party) infrastructure. This is about providing clients the option of secure communication and authentication with the lobby server. The ZK project can solve its own problems.
Finally, I'm puzzled by the comments in the code, not yielding much confidence. They say the security system can leak data and crash the server. Am I foolish to believe the comments?
Those comments constitute what normal people would call "jokes".

A client can send out plaintext data by choosing not to apply the encryption step, much like I could choose to publish my private key on the interwebs. Both would be monumentally stupid.

MetalSucker wrote:www.letsencrypt.org
Funny, a pervasive TLS initiative sponsored by "let's backdoor our hardware to make the NSA's job easier" Cisco.
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: lobby server<->client protocol encryption

Post by Silentwings »

Thanks for putting the work into this!
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: lobby server<->client protocol encryption

Post by gajop »

As far as libraries goes, (if you feel you could use one), check https://code.google.com/p/keyczar/ .
I've never used tried it myself, but I heard it's good from a few people.
User avatar
Jools
XTA Developer
Posts: 2816
Joined: 23 Feb 2009, 16:29

Re: lobby server<->client protocol encryption

Post by Jools »

I also say thanks for working with this topic, I find encryption quite important and too underused, not just here but also for trivial things like sending email. It is really not that hard to set up a PGP/GPG encryption.

But I also wonder, would this maybe also allow us to login with a RSA key instead of password? Key-based login is supposed to be more secure, provided you handle keys well, and it's also quite convenient.

I have to say I do not know very much about encryption methods, but I heard that AES was supposed to be less secure than DES. Wasn't one of those back-doored by NSA?
dansan
Server Owner & Developer
Posts: 1203
Joined: 29 May 2010, 23:40

Re: lobby server<->client protocol encryption

Post by dansan »

Thank you for this work! I was sorely missing encrypted communication in spring.
Jools wrote:I have to say I do not know very much about encryption methods, but I heard that AES was supposed to be less secure than DES. Wasn't one of those back-doored by NSA?
(3)DES can be broken rather quickly nowadays, AES is - well implemented and with sufficiently big keys - considered secure. The NSA didn't backdoor any of them. They did however provide a vital part of DES (very good S-boxes). Those have been researched a lot, and not found to contain a backdoor of some kind. DES was invented 30y before 9/11.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: lobby server<->client protocol encryption

Post by gajop »

Jools wrote: But I also wonder, would this maybe also allow us to login with a RSA key instead of password? Key-based login is supposed to be more secure, provided you handle keys well, and it's also quite convenient.
This only makes sense for bots (software), and probably should be done as an API key.
Users should not be expected to keep such files.
MetalSucker
Posts: 98
Joined: 22 Sep 2014, 20:29

Re: lobby server<->client protocol encryption

Post by MetalSucker »

Tinfoil hat mode enabled.
Because this is a tiny RTS engine project in the middle of nowhere, not a government bank or agency tasked with protecting state secrets that can deal with the hassle brought by certificates.
You mean it's not a realistic warzone simulation that can be used to predict battle outcome by world powers? It should be, they would fund it like crazy!
Funny, a pervasive TLS initiative sponsored by "let's backdoor our hardware to make the NSA's job easier" Cisco.
That was the main selling point for said hardware!

/tinfoil

Securing the lobby is certainly important for the future, however it's by no means a priority (I actually have a very very very basic lobby thing going on but it's highly dysfunctional atm.) While recent events have shaken the trust in that well known and used library, rolling your own is much worse since it requires a degree of specialization in that particular area - and most people have a shallow understanding of how the thing works in the first place. I also don't think it should be optional, it's 2014 (almost '15) and cpu cycles are no longer an issue, not even when dealing with high bandwidth situations, and this certainly isn't the case.

I will figure out why I'm getting myself involved in the politics of this thing, I had a 'usability + getting new players agenda' when I started posting on this forum and like most things I do, I got derailed.
User avatar
Jools
XTA Developer
Posts: 2816
Joined: 23 Feb 2009, 16:29

Re: lobby server<->client protocol encryption

Post by Jools »

gajop wrote:
Jools wrote: But I also wonder, would this maybe also allow us to login with a RSA key instead of password? Key-based login is supposed to be more secure, provided you handle keys well, and it's also quite convenient.
This only makes sense for bots (software), and probably should be done as an API key.
Users should not be expected to keep such files.
Why not? It's an option to use when logging in with ssh, why could it not be an option in spring?

They would not be expected to keep keys, as naturally you would still allow password login.
Post Reply

Return to “Infrastructure Development”