I would like to discuss this scenario:

There is a HTTPS service which responds with signed keys to an authenticated client. These signed keys can be used for another service to return very sensible data. Let's assume that because of some internal security hole (unexperienced internship, exposed ssh key on git server, somebody sent the ssl ca with an email, ...) a person gets the certificate, and now can encrypt every connection and just listen on the server responding with one of the signed security keys which he can use to access the sensible data of the other service.

Is there any technique which could make the signed security key invalid when a man-in-the-middle attack may have occurred (maybe a second SSL tunnel)?

  • It's a little hard to tell what you are asking, but I have tried to give a broad explanation to see if it covers what you are trying to figure out. Please clarify your question further if this doesn't handle your needs. Aug 24, 2013 at 18:18
  • install anti arp poisoning first to avoid of change mac address. Jun 26, 2016 at 5:33

3 Answers 3


Well, there are many options other than SSL to prevent a man in the middle attack, but most all of them have a similar cryptographic basis. Fundamentally, to ensure that a communication can't be attacked by a man in the middle you must be able to prove that a) both parties can validate the other and b) that no other party can monitor the communication.

Both of these are most commonly accomplished through a shared secret. Asymmetric cryptographic operations can also be used where both parties have a trusted public key for the other, however this is much more difficult (computationally) than exchanging a shared secret and then using that.

The shared secret can either be pre-shared, such as in the case of an encrypted wifi network, or it can be negotiated through an authentication process. For example, with SSL, the server validates itself to the client through signing the public key, the client then establishes a shared secret with the server by using the server's trusted certificate and the server then validates the client through a traditional login (or possibly a client certificate in rare cases.)

This general process is not unique to SSL, but the basic steps of verifying identity of one or both parties and establishing a secure communications key is the critical bits. If, however, the root of the trust for that certificate was compromised, it would be possible for someone to man in the middle since they could pretend to be the server and open their own connection with the server and their own connection with the client.

In the event of a private key leaking, the certificate should be revoked via a revocation list. This is generally published by a CA and is included as part of the signed certificate. As a condition of validating the validity of the certificate, the revocation list should be checked for validity.


It sounds like what you're asking is: how do I prevent a MITM if my private key may be compromised? And to that, the answer is get a new private key (and therefore new certificate).

If your security policy is so disastrous that an intern is able to upload your SSL private key to github, then that is your problem. Private keys are private, and need to be protected as such. No one should have access to your private key, which means that people should be physically or technologically prevented from accessing it. Just instituting a policy saying "do not upload the private key to usenet" isn't enough. You have to actually prevent unwanted access to private data.

Unless you can do that, you have no hope of maintaining any semblance of data security.

Also, you seem to be confusing the private key with the certificate. You can do whatever you want with the certificate (which includes signed certificates); email it to friends, post it on your Facebook wall, publish it to Github, anything is safe. But the private key never should leave the computer where it was generated.


As MITM take place in the key exchange phase, you can apply ID-based encryption , where the public key is the recipient's ID to prevent it.

You must log in to answer this question.

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