[OpenWrt-Devel] openwrt + openconnect

[David Woodhouse]

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/openwrt-devel/attachments/20140728/b4b0201b/attachment.bin>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel