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.
>
> 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
