-1

I have a https connection from Client to Server and a malware in client. The malware modifies the message and compromises its integrity. I am using a proxy to check the Integrity of the message after the malware has changed the message and before sending it over the internet to the server.

Now, How can I check the Integrity of the message (Sure that it has not been modified by any Man in the Middle) for the second half of my communication channel(Which is from Client to the Server over the internet).

I see few conventional approaches of CRC or Checksum will help. But I am looking for some non traditional or upcoming approaches. I am new to this area and want to take expert advise about the direction I need to search for answer to my question.

Any pointers would be of great help.

Thanks,

Pavan K
  • 1
  • 5

1 Answers1

2

As I mentioned in your other question, if you have an https session, you can't do this.

If you could do it, it's possible your proxy could be the "man-in-the-middle", which is exactly what SSL is designed to prevent.

Also, it's not clear how you expect the malware on the client side is changing the message - your software can always validate the message before it is sent via SSL, and after it's sent, the only thing that should be able to decode it is the server.

I strongly recommend spending some time learning about specific well known client server security patterns rather than trying to invent your own (or trying to hack apart SSL). A great starting point would be just picking through some questions on http://security.stackexchange.com. (A personal favorite there is this question about how do to password security). There are likely some questions/links you can follow through there to learn more about client-server security (and eventually understand why I'm confused about what it is you're trying to do).

If you are required to make up your own for some reason, a possible (but still hackable with enough determination) way of doing validation is to include a checksum/hashcode based on all the values, and make sure the same checksum can be generated server side from the values. You don't need a "middle" to somehow crack the SSL to do this though - just do the validation on the server side.

Community
  • 1
  • 1
Krease
  • 15,805
  • 8
  • 54
  • 86
  • Hi Chris, Thanks for your comment.Yes, Ideally SSL Data shouldn't be able to be deypted by any MIM. But my assumption is that any Protocol is subjected to attack and compromised in real world and few recent studies are proving that https is breakable. Thus, its a What if analysis? On the client side, lets say malware is not more powerful than just modifies the transaction amount and destination account number in a typical online Baking transaction. – Pavan K Feb 28 '14 at 23:26
  • _If_, for example, the malware was somehow powerful enough to decrypt SSL, modify some numbers, and re-encrypt, and you wanted to have some validator in between the client and the server, that validator would also have to be powerful enough to do the same thing, and decrypt the SSL, look at the numbers, do something with the validation result (would failure mean not getting the reply from the server, but from this "validator"?) – Krease Mar 01 '14 at 04:05