On Tue, May 19, 2015 at 12:33 PM, Jonathan Bennett <[email protected]>
wrote:
> Threw together a quick script to pull keys from an access.conf and
> make a qrcode for each access stanza. No guarantees it deals correctly
> with every valid access.conf, but it's a start. To use it, "sh
> console-qr.sh < access.conf"
>
Cool, I'll do some testing and add this into the extras/ directory.
--Mike
>
>
> #!/bin/sh
> while read line; do
> line=$(echo "$line" | sed 's:#.*$::g')
> if [ "$(echo $line | grep -c 'SOURCE')" -ne "0" ] && [ -n "$qr" ]
> then
> qrencode -o - -t UTF8 "$qr"
> qr=""
> fi
> if [ "$(echo $line | grep -c 'KEY')" -ne "0" ]
> then
> trline="$(echo $line | sed 's/^[ \t]*//;s/[ \t]*$//' | sed 's/ /:/')"
> qr="$qr$trline "
> fi
> done
> if [ -n "$qr" ]
> then
> qrencode -o - -t UTF8 "$qr"
> fi
>
> On Mon, May 18, 2015 at 11:02 AM, Jonathan Bennett
> <[email protected]> wrote:
> > 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
> >>
>
--
Michael Rash | Founder
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F
------------------------------------------------------------------------------
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
