Preventing Man-in-the-Middle Attacks on Non-HTTPS

Is there a way to prevent or detect a man-in-the-middle attack on plain HTTP?

I want to run a javascript applet on a client machine with the certainty that the code has not been changed. Are there any clever tricks to sign the code or deliver it securely without going through the usual HTTPS and certificate path?

+3


source to share


4 answers


No, not at all. By the time you make it secure, you will have to reinvent at least 90% HTTPS (or something very similar, anyway), but probably made it worse. No insult is intended, but very few people are capable of adequately designing something like this. It is common for a specialist (or a few of them) to design as good as they can, and still plan to solve at least a few problems over the next few years as more cryptanalysts see them. Most likely, a layman who received this right for the first time is where there is a victory in a large lottery, and hits the lightning at exactly the same moment.



+8


source


In one form or another, I think public key cryptography will be involved. Perhaps you could implement it yourself, but that would probably be insecure and tricky. Why don't you want to use HTTPS? It exists for this purpose.



+1


source


If it's javascript, then you can't even confirm that the person on the client machine hasn't changed your applet, whether you're using SSL or not.

0


source


If they can modify the javascript, then they can remove any checksums or similar data you put in. Your best bet is to use a javascript obfuscator / minimizer as it will just complicate things where all hell changes and still works.Yahoo has a good one, I believe, as does Google.

This is no wacky proof, but it will likely crowd out just about anyone considering spoofing your applet. Go to maps.google.com and look at their javascript. Consider hiding something about it. This probably won't happen.

EDIT: in the end it might not be that good, see links below

-1


source







All Articles