> This is most likely the result of the PIN entry thing being involved. > For libgpgme engines that require PIN entry, the only way I know of to > get around this is to remove the password from the gpg key. Or you can > use gpg-agent, but that usually isn't a good solution for a remote > system you want access to (reboots for whatever reason, passwords > getting timed out of gpg-agent, etc.). If you want to take this step, > you'll need to use the GPG_ALLOW_NO_PW variable in the access.conf stanza: > > *GPG_ALLOW_NO_PW* /<Y/N>/ > > Allow *fwknopd* to leverage a GnuPG key pair that does not have an > associated password. While this may sound like a controversial > deployment mode, in automated environments it makes sense because > "there is usually no way to store a password more securely than on > the secret keyring itself" according to: > > "http://www.gnupg.org/faq/GnuPG-FAQ.html#how-can-i-use-gnupg-in-an-automated-environment";. > Using this feature and removing the passphrase from a GnuPG key pair > is useful in some environments where libgpgme is forced to use > gpg-agent and/or pinentry to collect a passphrase. > > > > > > Btw, annoying non-technical question and I know there's probably no > 'objective' answer but how much more secure is the system when using gpg > keys (+HMAC digests), assuming a 'proper' implementation (whatever that > means!)? > > > In some sense, the most important aspect of SPA communications is > authentication instead of encryption. That is, most usages of SPA are > going to ask for access to SSH, and frequently the IP to be allowed will > be the source IP of the SPA packet. So, there aren't too many "secrets" > that need the protection of encryption (yes, there are a few other > things sent in the fwknop SPA payload, but the point stands). The main > thing is to authenticate the payload so that it can't be tampered with > en-route. The HMAC is critical. > > However, if you are doing something more advanced or different, such as > using the ghost services feature > (http://cipherdyne.org/blog/2009/11/creating-ghost-services-with-single-packet-authorization.html) > or using fwknop as a command channel, then encryption becomes more > important because the contents of the payload contain non-default > information worthy of protecting. And, even if you aren't doing > something like this, there's no reason to not encrypt anyway. > > Now, for gpg vs. AES, fwknop's usage of 256-bit AES is vastly "more than > enough" in terms of security. Some users gravitate towards gpg though > because of workflow differences, gpg-agent, key distribution, etc., but > there is no reason to move away from AES in terms of its ability to > strongly encrypt data. > > To me, deploying fwknop in the most secure manner is done by using the > --key-gen option to generate symmetric encryption and HMAC keys and then > compiling fwknopd without gpg support and also without pcap support > (--udp-server mode). Yes, this means the firewall must allow SPA packets > through to the UDP port where fwknopd is listening, but fwknopd never > answers anything so it is indistinguishable from a default-drop firewall > policy stance anyway. > > Thanks, > > --Mike > >
Thanks a lot Mike. "More than enough" was exactly the kind of answer I expected/hoped you'd provide. My use is fairly "plain vanilla" so I think by-passing some of the more fiddly aspects of GPG (as per my current issues) is probably sensible and efficient. Anyway, from my POV, it's a thoroughly educational and enjoyable experience getting the software up and running. Thanks so much for your valuable and ongoing contribution. Cheers, Adam ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Fwknop-discuss mailing list Fwknop-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
