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. 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. You can also have a way to manually edit the individual items like 'form:main:username' = 'nmav', but that's not going to be the normal UI, especially for initial setup. This will only cope with the case where the authentication responses we need are *constant* ? no OTP or anything like that. Actually, supporting OTP in the future wouldn't be *so* hard... but let's leave that for the future. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140728/b4b0201b/attachment.bin>
