Comment by huhtenberg
8 years ago
Putty binaries are all signed, which is what you should be looking at when authenticating a release. Whether you fetch them over SSL is of little importance.
8 years ago
Putty binaries are all signed, which is what you should be looking at when authenticating a release. Whether you fetch them over SSL is of little importance.
You are, of course, absolutely correct. And I hope this is what internal package maintainers in large companies and individuals using putty as their standard SSH client do. However, for many of us putty is a backup when they are not on their linux/osx machine and just quickly need an SSH client to do something. The workflow there is google->putty->first result->download->execute. You absolutely shouldn't, but we also shouldn't drink and sleep 8h a night :)
I put a copy of putty at a short but private url at my own domain so that I can get it over https.
How do you know the public key is correct?
The level of assurance you get with a signing key downloaded over HTTP and one downloaded over HTTPS is roughly equivalent. Sure, HTTPS gives you a degree of protection from MitM attacks, but it won't stop attackers (whether criminals or militaries) from hacking the web server and changing both the software and the signing keys---after all, if one is possible, so is the other.
Clearly we have different concepts of "roughly equivalent" :) One means everyone on your network can trivially serve you trojanized binaries, the other doesn't.
2 replies →
That still allows an attacker to deliver you an older binary than you previously had installed — potentially one with major vulnerabilities.
Signing doesn't prevent downgrade attacks, HTTPS does.
You would also look at the version number when you check the signature...
The signature is automatically verified by the system — when you open the installer, it either shows "unknown developer" or "PuTTY team" in the UAC dialog. Which is easy to verify.
Do you know the version of PuTTY you have installed without checking?