It's definitely been a group effort. Kudos to everybody that's worked on
it.
We should be able to get the qr codes in the OpenWrt 15.05 release. (their
naming scheme is a bit strange, it'll be a couple months before they are
ready to release)
What do you think about giving fwknopd the ability to generate keys? I
think it might make more sense there than in the client. It would also make
life a bit easier in OpenWrt, as there would be one less package to
install. Flash space is at a premium on some routers, and if the daemon
could gen the keys, we could make everything work without the client
package.
~Jonathan Bennett
On Mon, May 18, 2015 at 7:53 AM, Michael Rash <[email protected]> wrote:
>
>
>
>
> On May 16, 2015, at 9:41 PM, Michael Rash <[email protected]> wrote:
>
>
>
> On Sat, May 16, 2015 at 1:49 PM, Jonathan Bennett <[email protected]>
> wrote:
>>
>> TL;DR: using qr codes to add keys to the android app.
>
>
> Now that would be a really cool feature. Copying symmetric keys around has
> always been an issue (obviously not just for fwknop, and this one reason
> fwknop supports GPG keys), so I think as long as people generally access
the
> Luci interface via SSL/TLS (?) this would be reasonably secure and be a
big
> boost to useability for mobile users.
>
>>
>>
>> Fwknop/fwknopd is a very clever project. I've thought highly of it since
>> first learning about the novel approach to doing port knocking in a more
>> secure manner. There is one issue, though. It's hard to use. I'm not
afraid
>> of the command line, and yes, it's quite possible to script the use of
>> fwknop to open ports. I've been thinking about usability and
>> noob-friendlyness in the past days, especially in regards to fwknop/d
>
>
> Completely agree that usability is lacking. Lately I've been spending most
> of my time on code coverage, fuzzing, etc. to try and ensure a high degree
> of security, but usability needs to be ramped up too. I think your Luci
> interface is huge in this area, and fwknop needs more efforts like this.
>
>>
>>
>> There is a danger in trying to maximize usability. It's possible to
>> sacrifice freedom and or usefulness for usability. I am very much against
>> this trade-off.
>
>
> Agreed - fwknop has always maximized config options and capabilities I
> suppose, and this has come to some degree at the expense of usability. So
> far, the biggest contribution to usability has been Frank Joncourt's
> addition of the ~/.fwknoprc file so that people can easily reference
> consistent command line options from the client just with by naming the
SPA
> destination with "-n <server>". This was a great addition, and we can do
> more like this.
>
>
> Btw, I should have mentioned that Damien originally added the .fwknoprc
file
> Infrastructure, and Franck worked on a lot of variable processing code,
etc.
> It's all there in git history.
>
> Mike
>
>
>>
>>
>> With the new Luci module for openwrt, I feel like there is now an easy to
>> use option for configuring fwknopd on a router. For a home user that
simply
>> wants to protect port 22 without locking himself out of his network,
this is
>> perfect. I've intentionally avoided making this interface too simple.
It's
>> easy to get started, but you can do everything from luci that you can do
>> with the command line interface, in regards to fwknopd.
>
>
> Very cool. This is definitely the first major step towards better
useability
> on the server side of things.
>
>>
>>
>> When I'm away from my desktop, for better or worse, I access the internet
>> through an android phone, an android tablet, or occasionally a customer's
>> desktop. Using the fwknop client from my android tablet isn't much of an
>> option. Yes, I could compile the binary and make it run in the android
>> terminal, etc, but that is a big hurdle to a typical user, and quite a
pain,
>> even to those of us who can do it.
>>
>> I took a closer look at the android app today, and it has some great
>> potential. It also has, in my opinion, some issues. The lack of base64
key
>> support is a big one, and that is a known weakness that is planned to be
>> addressed. Another problem is the fact it tends to hang on launch,
waiting
>> to verify external ip. Again, planned to be addressed.
>>
>> Once base64 is supported, typing both keys in every time one wants to
open
>> a port is a bit crazy. This is easily fixed by making the keys savable.
But
>> on further thought, it's a bit crazy to type the keys in even once.
>>
>> So, this leads me to a couple ideas, somewhat inspired by how openvpn
>> connect works. The first is a text file that contains both keys, and
*maybe*
>> the ip address/hostname to connect to. I believe we could make openwrt
>> generate this file, and make it available from the luci interface. The
end
>> user would then just install the fwknop android app, open the luci
interface
>> on the phone, and grab the file. It could open automatically in the
fwknop
>> app, and add the keys as a connection option. This format could be useful
>> for the cli interface, too.
>
>
> If the Android client could be made to essentially handle the ~/.fwknoprc
> file like the normal client, then on openwrt the Luci interface could just
> drive the client with '--key-gen --use-hmac --save-rc-stanza ...'. I guess
> this assumes the client is installed on openwrt as well. If there is a
more
> natural style of file on Android for this type of data (xml maybe?) then
the
> fwknop client could be updated to produce this format too, although a
quick
> python wrapper around the existing ~/.fwknoprc format would probably be
> easier/faster.
>
>>
>>
>> The second, slightly more outlandish option is to embed a qr code in the
>> luci interface. Add a qr scanning feature to the android app, and just
scan
>> the qr code to add the keys. This *could* be the ultimate in usability.
It
>> wouldn't be forced on anyone, but it could be there as an option. I
>> personally think this could be a really slick feature.
>>
>> It seems like either idea would be feasible. Any thoughts or ideas are
>> welcome. I might try to dive into the android code soonish, at least to
get
>> a handle on what all is going on there.
>
>
> I think both ideas are excellent. The QR feature is definitely really
slick.
>
> --Mike
>
>
>>
>>
>> ~Jonathan Bennett
>>
>>
>
>
------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
> _______________________________________________
> Fwknop-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
>
>
>
------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Fwknop-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Fwknop-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
