After not too much trouble, I have this working:
http://incomsystems.biz/fwknop-interface-qr.png

It only looks for the 4 kinds of keys, and just encodes what it finds in
the form of "LABEL:keytext LABEL:keytext".

I imagine it working like this. Open the android app, and find an option to
add new connection. In that dialogue, there is an option for qr code. The
camera is enabled, and once a qr code is read, it populates the right
fields on the dialogue. The rest of the needed fields are filled in by
hand, and the connection can be saved. Then, all a user has to do is open
the app, hit the connection, and the knock is sent, then he has 60 seconds
to start ConnectBot, or even ssh from another device if needed.

Android app development is not something I have ever done, so if I get a
chance to work on it, it will come slowly. I would like to make this work,
though. If somebody else wants to do the Android side, I'll gladly help
test and give feedback.

~Jonathan Bennett

On Sat, May 16, 2015 at 8: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.
>
>
>>
>> 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

Reply via email to