0

I was designing a system where there is a chance of losing the SSL certificate to the attacker.

But I am not clear that if the certificate is compromised which all attacks are possible?

  1. Man in the middle attack
  2. Impersonated attack

I want to continue to use SSL certificates to encrypt the communication channel (i.e. prevent man in the middle attack)

For authentication I want to send data to predefined end points asynchronously depending on the querying user (Very similar to how we get email notification when we or the attacker tries to reset our login credential)

This is coming from How can a process authenticate and communicate securely with another process on the same host

Community
  • 1
  • 1
Saurabh
  • 195
  • 1
  • 2
  • 7
  • I don't get it. Certificates are public. You can freely disclose them without losing any security. Are you talking about the corresponding private key? If you lose that, you lose everything. – erickson Oct 08 '12 at 04:46
  • I was implementing secured IPC on the same host; now that certificates are sufficient only to verify the host; so another process can start up on the same host (I am planning to put the keystore password in the application's ), use the same keystore and then impersonate. I'll clarify my question, does using the same public and private key pair by user and the attacker lead to generation of same symmetric key every time or the key pair is used to generate a random symmetric key for every communication channel, in which case man in the middle attack is prevented – Saurabh Oct 08 '12 at 05:07
  • I think I was confused with http://crypto.stackexchange.com/questions/2867/whats-the-fundamental-difference-between-diffie-hellman-and-rsa – Saurabh Oct 08 '12 at 05:22

2 Answers2

1

Presumably, you're not talking only about losing the certificate, but having its private key compromised.

In this case, someone in possession of the private key could perform a MITM attack, provided that they're also in a position to do so.

I'll clarify my question, does using the same public and private key pair by user and the attacker lead to generation of same symmetric key every time or the key pair is used to generate a random symmetric key for every communication channel, in which case man in the middle attack is prevented

Random symmetric keys are generated for every connection (unless SSL/TLS sessions are re-used, but that's more about optimisation, distinct clients or connections done after a certain period of time will have distinct symmetric keys). Having new symmetric keys every time certainly doesn't prevent MITM attacks on its own, since the negotiation of new symmetric keys is authenticated with the certificate: that's what prevents MITM attacks.

If you're really worried about your private key being copied from your machine, you could use an HSM module (Java supports PKCS#11).

This being said, since you seem to assume that there can be someone in a position to perform a MITM attack on your machine, using a communication between two processes on the same machine, it sounds like you're assuming your machine is compromised. In this case, your chances of success in using SSL/TLS to protect whatever you're trying to protect are limited. It sounds like there's a bigger problem with the general approach.

Bruno
  • 119,590
  • 31
  • 270
  • 376
  • There is also the additional issue that if you use a weak ciphersuite obtaining the server's long term private key allows an attacker to decrypt sessions which he recorded without performing an active attack. – CodesInChaos Oct 08 '12 at 10:04
  • @CodesInChaos, that's true, although this can be prevented using (EC)DHE cipher suites. – Bruno Oct 08 '12 at 10:13
  • There is a need to prevent man in the middle attack and authenticate each process on the same host. We cant secure the keystore storing the certificates as the keystore password has to be given in the config file. Also root users will have access to the host so they can start another process which uses the same keystore and break into protected data. To solve this issue, I want an implementation that will exchange symmetric keys without certificates as its the case in ElGamal key exchange protocol. – Saurabh Oct 08 '12 at 11:26
  • From @Bruno comment, its clear that if the keystore is compromised, symmetric keys are also compromised during handshake. – Saurabh Oct 08 '12 at 11:30
  • @ChatC, if you can't even trust the root user on that host, you might as well give up. – Bruno Oct 08 '12 at 11:34
  • The server we use is a shared server so we shall protect the key-store from other people using the same host – Saurabh Oct 08 '12 at 12:08
  • Don't use a shared server if you can't trust its admin. – Bruno Oct 08 '12 at 12:18
0

I'll clarify my question, does using the same public and private key pair by user and the attacker lead to generation of same symmetric key every time or the key pair is used to generate a random symmetric key for every communication channel, in which case man in the middle attack is prevented

New symmetric keys are generated for every SSL session, based on random numbers chosen by both the client and the server. (There are actually several different symmetric keys used in one TLS session, for different cryptographic services, and in each direction of communication.)

erickson
  • 265,237
  • 58
  • 395
  • 493