On Sun, Apr 9, 2017 at 6:02 PM, Adam <a...@gmx.com> wrote:
> This seems really simple but I can't figure out what's going wrong. I'm
> running in GPG mode and when I attempt to make a connection the logs say
> as follows:
>
> Starting fwknopd main event loop.
> : (stanza #1) SPA Packet from IP: [ip] received with access source match
> : [ip] (stanza #1) Error creating fko context: Decryption operation failed
> : [ip] (stanza #1) - GPG ERROR: Bad passphrase
>
>
> I've double/triple checked I have the right p/w for the right key in
> access.conf. I also tried running in non-GPG mode just to check
> everything is working that way and it is.
>
> Finally I ran the daemon as follows: fwknopd -f -v -i eth0
> The PIN entry dialogue (barebones, not even ncurses) comes up, I enter
> the p/w and what d'ya know, the right rule is inserted into the firewall.
>
> It seems the password isn't getting accepted when automated. Once
> again, any pointers?
>
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
>
>
> ------------------------------------------------------------
> ------------------
> 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
>
--
Michael Rash | Founder
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F
------------------------------------------------------------------------------
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