Warning, /plasma/plasma-nm/vpn/openconnect/README is written in an unsupported language. File is not indexed.

0001 README taken with slight modifications from the network-manager-openconnect
0002 auth dialog
0004 AnyConnect works over HTTPS; authentication is through HTTP forms and
0005 POST responses. Once you've filled in the forms that the server demands,
0006 you're rewarded with an HTTP cookie which is handed on to OpenConnect to
0007 actually make the connection.
0009 The auth-dialog handles the arbitrary forms as the server presents them,
0010 and spits out the cookie after a successful authentication. It's just a
0011 really simple web-browser, effectively. (It has its own HTTP client
0012 implementation instead of using libsoup because it needs to be able to
0013 support certificates from a TPM, and to work around Cisco bugs).
0015 To make it slightly more fun, you have a *choice* of servers; an
0016 AnyConnect VPN is provisioned with an XML file that gives various pieces
0017 of configuration for the client. We ignore most of the XML file, except
0018 the list of available VPN server addresses.
0020 So this is a brief flow of what the auth-dialog does...
0022  1. Choose a server to connect to.
0024     If we already have the XML configuration file for this VPN, you get
0025     to choose a server from the list. Otherwise, you only have the host
0026     that you configured in the VPN setup.
0028     The auth-dialog will give you the choice of automatically connecting
0029     to the last server you used. It does so by storing the boolean
0030     'autoconnect' option, as well as the address of the last successful
0031     server, in "secrets" that NetworkManager stores for it, but which
0032     aren't actually used by OpenConnect itself at all.
0034  2. Offer your SSL certificate and fill in all the forms it presents.
0036     The server will present a sequence of forms which are filled in just
0037     like normal web forms. At this point, the auth-dialog is just acting
0038     like a really simple web browser. It uses the same trick with fake
0039     secrets to remember the answers for any multiple-choice selection,
0040     or input elements of type 'text'. Input elements of type 'password'
0041     are not currently saved, but probably should be.
0043     The choices and input boxes that we fill in at this point may not be
0044     limited to *just* authenticating ourselves. You may also get to make
0045     choices which affect your resulting connectivity. Some networks
0046     offer the choice of full-tunnel or split-tunnel routing, IPv6 or
0047     Legacy-only connectivity, etc. (The routing configuration is not
0048     handled by the auth-dialog; that just manifests itself in the IP
0049     configuration which is given to OpenConnect by the server, much
0050     later when the connection is actually made.)
0052 (
0053  2½. Run the "Cisco Secure Desktop"[sic] trojan.
0055     In some cases you are required to download a strange executable from
0056     the server and run it. It is supposed to perform various "checks" on
0057     your system and report its results to the server. The authentication
0058     sequence is kept in a holding pattern with HTTP refresh responses
0059     until the "trojan" has done its job.
0061     Most people seem to bypass this crap and run a local tool of their
0062     own devising to report the "correct" results. It's just another
0063     simple HTTP POST, although the exact results that are expected may
0064     vary from one server/configuration to another.
0066     Try not to think about it. It will only make you sad.
0067 )
0069  3. Note the 'webvpn' cookie.
0071     Once authentication is complete, the server's HTTP response will
0072     include a 'webvpn' cookie.
0074     This cookie is one of the three *real* secrets which are actually
0075     passed to OpenConnect to make the connection. The other two are
0076     the address of the server we finally ended up talking to (after
0077     the user's initial choice and any HTTP redirects), and a hash of
0078     the server's SSL certificate (to prevent MiTM attacks).
0080  4. Check the XML configuration file.
0082     With a successful authentication, we are *also* given the SHA1 of
0083     the current XML configuration for this VPN connection. If it differs
0084     from what we have, we are expected to fetch the new one. We store
0085     this, base64-encoded, in yet another fake "secret".
0087  5. Dump all the "secrets" to NetworkManager.
0089     Finally, we write the secrets into the setting, so that NM can use them.