0

I'm working on a chat system and I want to add it some kind of security (not just HTTPS with SSL since I've read it can be sniffed and decrypted with a few tools). Now, my knowledge in cryptography is scarse, but I'm willing to learn, providing what I'm asking is possible to do:

Taking in account there's an eavesdropper (client C) bypassing HTTPS in the beginning of all connections (say a MITM, proxy, firewall, etc), and that I have my own concepts, this is the procedure I have in mind:

Send:

  1. The client A connects to a web interface which contains inside the response code (javascript) a public key (say, a123456789b) randomly generated on intervals (key re-negotiation can happen later).
  2. The user's password is hashed locally and that hash is sent to verify it is the same in the server. If it is, continue (say, DEADBEEF).
  3. So now I have a public key (a123456789b) and a private key (DEADBEEF). I can use both to encrypt a message and send it.

Receive:

  1. The client B connects to the server and gets the same public key (a123456789b) and gets another hash (since his password is different, say, FACEFEED).
  2. The client B receives a message from client A, and...

Here's my show-stopper: Whatever B receives, C can see it AND replay it since it has the public key and the hash (and by replaying I mean replaying the data instead of submitting the requests to my server again (which would invalidate them, obviously)).

As I see it, it doesn't matter if the message can be decrypted with either DEADBEEF (if it is sent along with the encrypted message) or with FACEFEED, since C is watching the whole protocol and can decrypt what B receives (but not what it sends?)

I'm stumped here. I know that C can hack the client code injecting its own public key or functions, but it will only receive and send garbage to the other side. If that's so, I'm happy with that because then I can show a warning and whatnot. What worries me is how do I avoid C to replay the packets and then decrypt the messages, since to decrypt it I need the public key and either FACEFEED or DEADBEEF, and those 3 are sent over the same channel?

Any help is welcome! please remember I don't know much of cryptography, I've been wandering through a lot of wikipedia links, (DH key exchange, PFS, MTProto, etc) but only understood around 50% of them all and this is what I came up with but now I need some help.

Improve this question
8
  • 1
    Maybe it is just me, but I do not get the HTTPS can be sniffed and decrypted with a few tools thing. Can you elaborate on that?
    – dst
    Sep 28, 2014 at 0:18
  • Sure, here's what I found: blog.philippheckel.com/2013/08/04/…
    – DARKGuy
    Sep 28, 2014 at 0:25
  • 1
    To do so, it dynamically generates a certificate and signs it with a the private key of a CA certificate that the client must trust. This is only possible if C has access to all clients or a CA they trust, which is unlikely. If that should happen, I doubt there is much you can do (your JS has to get delivered through some channel, too!).
    – dst
    Sep 28, 2014 at 0:30
  • 2
    I highly doubt that there is anything that can be done against an administrative user with physical access to all clients. He could just screencap/keylog the whole place (and probably does) without your fancy client noticing.
    – dst
    Sep 28, 2014 at 0:35
  • 1
    "It's easier (and less riskier) to kill those apps than breaking into the proxy/firewall to check if they are sniffing packets or not :P" - no it's not. How can you be sure of the integrity of the firewall or even the OS? If your adversary has "root" on your system then there is nothing you can do to be sure your system is secure. If you can be certain of the integrity of the hardware then you could say live boot another OS, but you can't be certain of the hardware integrity in the case of a Cyber Cafe either.
    – thexacre
    Sep 28, 2014 at 0:43

1 Answer 1

Reset to default
1

not just HTTPS with SSL since I've read it can be sniffed and decrypted with a few tools

This is not true.

In general (and in the case of SSL/TLS) replay attacks are prevented using a "number only used once" (ie. nonce). If the other party receives the nonce twice then it's obviously a replay attack.

With regard to the blog post you linked:

To do so, it dynamically generates a certificate and signs it with a the private key of a CA certificate that the client must trust.

For this to be successful an attacker must have physically gained access to the machine and installed a new trusted CA certificate (or else compromised the private key of one already trusted which would most likely be a global security issue). That attack would not work if you were simply a man-in-the-middle (without also having a CA certificate to sign forged certificates with).

Improve this answer
4
  • Well that's what I want to avoid. There are environments where someone can install the trusted CA of the SSL sniffing tool and unless you know about it and remove it, you're prone to be sniffed. I've thought about the nonce, but if you grab a log of the network packets, there's no need to go against the server because you already have the responses with the current nonce generated at that time, beating its purpose, am I right?
    – DARKGuy
    Sep 28, 2014 at 0:41
  • 1
    @DARKGuy no. Basically the client encrypts a random key with the servers public key, then the server encrypts the response with random key. A MITM can't decrypt the random key on the way to the server, and therefore can't decrypt the response. If an attacker can install a CA certificate then all that goes out the window, but if an attacker can install a CA then they probably have "root" and you have bigger problems.
    – thexacre
    Sep 28, 2014 at 0:54
  • Alright, I can live with that since it's something I can't control, but I can try to make its job harder. Your suggestion intrigues me, could you please elaborate? as I understand it, the client A generates keyA from the public keyP (with a nonce?). MITM can't decrypt it, but when the message arrives to client B (and sees message + keyA), how does client B know the nonce used in order to decrypt the message? there must be some kind of "nonce synchronization" after each message is transferred, right?
    – DARKGuy
    Sep 28, 2014 at 1:00
  • Also, what @Sky says here is similar to what I want to archieve - If the browser holds the public key, and the private one is a hash generated by the user's entered password (DEADBEEF or FACEFEED), I can use a nonce to make that hash salt change (and instead of being incremental, use something else that the server and the client don't have to share in order to know, like Blizzard's token generator). Sounds good to me, what do you say?: security.stackexchange.com/questions/58715/…
    – DARKGuy
    Sep 28, 2014 at 1:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .