-
-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
packet encryption for tcp sockets #197
Comments
2012-10-10 20:50:26: lindi commented
|
|
done in r1907 - see changeset log message for details |
2012-10-12 15:46:48: lindi commented
|
No you cannot, the salt is per client now, which means that one client's challenge is irrelevant to anyone else. |
2012-10-12 16:05:39: lindi commented
|
By salt I mean the salt used for the initial HMAC password verification step. The cipher salt is not very important and can be made public since it isn't the "secret" used with AES (the password is - after stretching), it just has to be random: it is only there to prevent rainbow tables attacks. There is no way to force clients to use encrypted connections, but I don't see how that helps in any way since you still have to get past the password authentication - or am I missing something? To only allow encrypted connections you would need a pre-arranged secret (cert, passphrase, whatnot) - which we do not have. Edit: And just to clarify: once a client has requested encryption, any non-encrypted packets at either end will cause a disconnection (this is covered in the changelog message) |
2012-10-12 21:03:17: lindi commented
|
Hah, so this has nothing to do with AES at all, this is just plain mitm against password auth, with or without encryption makes no difference. The only way to defeat that is with a "hostkey" ala ssh, so the client can be certain it is talking to |
2012-10-13 08:36:56: lindi commented
|
OK, so it is related but only for people who make the wrong assumptions.. (I can include myself in that since I was mistaken in comment:4 as I assumed the comment was related to AES when in fact it was related to HMAC password auth) So, to clarify, this ticket (as per the original ticket text) prevents snooping: anyone eavesdropping on the connection between a client and server cannot decrypt the data. |
2012-10-13 13:52:10: lindi commented
|
Lindi - thanks for taking the time to look into this. I understand what you're saying, except for the part that says "Since you use PBKDF2 to generate the key and the client can choose the salt". Isn't the problem here the fact that the salt can be intercepted, not that the client can choose it? I mean, the clients do choose safe enough random salts, the problem here is that an attacker can see what the value of the salt is/was, right? What good would it do to an attacker to re-use a previously used salt? For the record, this is what happens now (as of r1981 - see #198):
The fact that we change the key does not really help against rainbow tables since after cracking the first key the attacker will then know what the password was, it can generate the new key easily enough (since it will be able to decrypt the new salt and iv) Now, I do understand your concern about offline rainbow tables, but PBKDF2 with 1000 iterations is relatively expensive, and then you still have to test each key until you find one that works (by trying to decrypt a sample packet then parsing it), is it really worth worrying about? I am tempted to just make a note of it in the man page: use strong passwords... After all it is a I can't think of anything else we can do, can you? (well apart from implementing the algorithms mentioned in #198 that is) |
2012-10-13 15:12:56: lindi commented
|
Gotcha, so in this case, we can do this: avoid using encryption in step-2 above, we send a random salt to the client with the encryption request, then we combine this salt with the one provided by the client to make the server key. The client has no way of pre-calculating since it won't know the actual salt used until the connection is made. Right? |
2012-10-14 11:10:12: lindi commented
|
I'm not following you... the mitm can change the salt, but since this salt is combined with the salt from the other end (be it client or server), and obviously not with a dumb xor.. then he has no way of knowing the actual salt used until the connection is made, hence no way of using any precomputed rainbow tables. |
2012-10-14 11:45:04: lindi commented
|
2012-10-14 11:56:33: lindi commented
|
No you don't. The encryption uses the secret, and both salts. |
In any case, this is looking more and more like a home made crypto algo, which is a recipe for disaster, and as it happens SPEKE (#198) is actually very easy to implement, and it fits very well within the current initial packet exchange format, so I will just drop all this and replace it with SPEKE: the initial packets do the key exchange, each end can verify the other has the password and we use an AES secret key based on that (the SPEKE derived 'K'). |
2012-10-14 13:12:02: lindi commented
|
Sorry, it's not all wasted anyway because there are many similarities, the only major change is how the key is derived. |
If someone wants to use a password to protect a session exposed with "
--bind-tcp=
", chances are do not want to be snooped upon either.We should use a block cipher with the same password and encrypt all traffic (quite cheap).
Here is a good tutorial: Symmetric Encryption with PyCrypto
The cost will be:
The main difficulty is that our packet header sends the data size and now we will have a padded size and actual size...
The text was updated successfully, but these errors were encountered: