On 28 July 2014 12:53:17 CEST, David Woodhouse <dwmw2 at infradead.org> wrote: >On Thu, 2014-06-05 at 08:18 +0200, Nikos Mavrogiannopoulos wrote: >> Hello, >> I'm trying to resubmit the scripts for openconnect in openwrt's luci >> interface. Currently the most difficult part in the interface is >> specifying the server certificate. There no tools installed by >default >> in openwrt that can fetch the server's certificate, and there is no >way >> to calculate the SHA1 hash of the certificate as well. Thus it >becomes a >> pretty geeky interface that very few people will be able to use. >> >> Said that I think it would be really good for openconnect to have a >mode >> trust on first use (thus no certificate will need to be specified), >or >> at least a flag --print-hash or so that will allow running >openconnect >> to obtain the server's certificate hash (and thus the web interface >will >> be able to calculate the hash without other dependencies). What do >you >> think of these two options? (mostly a question to David but other >> opinions are welcome) > >It's not ideal, but actually there's already a way to do this. Just >connect with '--servercert foo'. Where 'foo' really is a literal 'foo', >or anything else that'll never match a real sha1sum :) > >You'll get something like this (localised) on stderr: > >Server SSL certificate didn't match: >A098E8E7339BBB0FBE3BB57932DA6BAFDC2DEE8B > >That's the hash you were after. > > >Actually, I think we want a kind of 'wizard' for openconnect >configuration in luci. Rather than having hard-coded configuration >items >like 'username' and 'password' which aren't always going to be >relevant, >we actually want to work through the forms that the server offers us. That's not easily done on the current lucy interface. It allows easy access to text configuration data but any interaction with applications is pretty hard. >Hook up a trivial d?mon listening on a local socket, and using >libopenconnect's obtain_cookie() method. Every time it gets a >validate_peer_cert() or process_auth_form() callback, stop and wait for >a connection (from luci) on its local socket. Spew the request out the >socket and wait for a response. > >You then have a luci page for the 'wizard' which simply fetches the >next >"request for user interaction" from that d?mon and stores the user's >responses as the "configuration" to be stored. When the d?mon finally >reports success, the 'wizard' page then gives you the option to 'Save & >Apply' the new configuration. Could be done but looks too much work for simply configuring openconnect. The current interface accepts a username and password and a certificate in advanced settings; that should handle 90% of sessions. -- Sent fron my mobile. Please excuse my brevity.
