lobby server<->client protocol encryption
Moderator: Moderators
lobby server<->client protocol encryption
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.
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.
-
- Posts: 98
- Joined: 22 Sep 2014, 20:29
Re: lobby server<->client protocol encryption
It's amazing except that any server public key can be injected thus defying the purpose.
-
- Posts: 834
- Joined: 19 May 2009, 21:10
Re: lobby server<->client protocol encryption
Clients should save the public key to signal changes to the user (either by server change or MITM attack).
Re: lobby server<->client protocol encryption
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!
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!
Re: lobby server<->client protocol encryption
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.
Also, it is actually HASH^1024 (at the moment) instead of HASH. The *crypt's were already on my radar however.
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.
If you have a bunch of spare bitcoin miners to throw at the DB, yes.gajop wrote:This is unsafe:
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.
-
- Posts: 98
- Joined: 22 Sep 2014, 20:29
Re: lobby server<->client protocol encryption
hardcode the sig in the clients
Re: lobby server<->client protocol encryption
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).MetalSucker wrote:hardcode the sig in the clients
- cheapsheep
- Lobby Developer
- Posts: 69
- Joined: 31 Dec 2011, 16:42
Re: lobby server<->client protocol encryption
excellent joke.
Re: lobby server<->client protocol encryption
Thats felony 1 & 2. What do you mean? whats wrong? what can be done better?cheapsheep wrote:excellent joke.
please learn to give constructive critism.
- cheapsheep
- Lobby Developer
- Posts: 69
- Joined: 31 Dec 2011, 16:42
Re: lobby server<->client protocol encryption
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?
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?
Re: lobby server<->client protocol encryption
then you should ask and not assume wrong things.cheapsheep wrote:I don't understand exactly what this is supposed to solve, but lets pretend I do.
it is a standard solution! read CryptoHandler.py, it uses AES for encryptioncheapsheep wrote:I don't understand why a standard solution wasn't chosen.
atm its optional. how to make it more secure without adding encyption?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.
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)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 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: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.
details? it shouldn't crash the server. if it does, its a bug and will be fixed.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?
-
- Posts: 98
- Joined: 22 Sep 2014, 20:29
Re: lobby server<->client protocol encryption
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/
I know this is borderline trolling.
Also useful (I don't think it's ready yet, basically free certs) https://letsencrypt.org/
Re: lobby server<->client protocol encryption
"session key" is the internal name.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.
It persists until a client issues another SETSHAREDKEY, but not across disconnects assuming the server properly cleans up dead clients.
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.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).
Also, I hear trusting e.g. OpenSSL might not be such a good idea these days.
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 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.
This thread is one day old.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.
TLS can always be enforced later if the simple solution is found insufficient.
You have a really depressing way of interpreting things.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?
"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 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.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.
Those comments constitute what normal people would call "jokes".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?
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.
Funny, a pervasive TLS initiative sponsored by "let's backdoor our hardware to make the NSA's job easier" Cisco.MetalSucker wrote:www.letsencrypt.org
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: lobby server<->client protocol encryption
Thanks for putting the work into this!
Re: lobby server<->client protocol encryption
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.
I've never used tried it myself, but I heard it's good from a few people.
Re: lobby server<->client protocol encryption
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?
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?
Re: lobby server<->client protocol encryption
Thank you for this work! I was sorely missing encrypted communication in spring.
(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.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?
Re: lobby server<->client protocol encryption
This only makes sense for bots (software), and probably should be done as an API key.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.
Users should not be expected to keep such files.
-
- Posts: 98
- Joined: 22 Sep 2014, 20:29
Re: lobby server<->client protocol encryption
Tinfoil hat mode enabled.
/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.
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!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.
That was the main selling point for said hardware!Funny, a pervasive TLS initiative sponsored by "let's backdoor our hardware to make the NSA's job easier" Cisco.
/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.
Re: lobby server<->client protocol encryption
Why not? It's an option to use when logging in with ssh, why could it not be an option in spring?gajop wrote:This only makes sense for bots (software), and probably should be done as an API key.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.
Users should not be expected to keep such files.
They would not be expected to keep keys, as naturally you would still allow password login.