On Sun, Mar 3, 2013 at 4:50 PM, David Woodhouse <dwmw2 at infradead.org> wrote: > Thanks. Please could you make sure you test the version I just pushed > out to the git repository a few minutes ago. Kevin, please could you > look over that (particularly commit ed14a3013c) too? The current head of tree works OK for me. > If the XML POST fails and we try a GET, we need to handle redirects for > that too. So re-use the same loop. Except the bit about not allowing local > redirects. Why do we do that for the XML POST case anyway? The official Cisco AnyConnect client seems to do something like: - Try XML POST first (POST /) - If we get a local redirect, switch back to regular GET requests. - If we get a redirect to another host, re-POST the data to the new host. - If we get a good response from the POST, stay in XML POST mode, and use "POST /" for subsequent responses. A few random observations regarding the gateway side: - A gateway might send a local redirect in response to "POST /" because it is configured to do so based on the client's OS type (see below). - A gateway might send a local redirect in response to "POST /" due to other configuration items, or because the server side only supports the legacy method. - The local redirect normally takes you to /+webvpn+/index.html - If you POST your data to the /+webvpn+/index.html URL, you'll get an error response. - A gateway might send a non-local redirect due to a load balancing setup. - Some servers appear to be set up to reject clients that aren't using XML POST (you'll get Login Denied even with a valid l/p). This might be related to the use of hostscan/CSD, and the desire to use the newer hostscan implementations which are tightly integrated into AnyConnect. Here is what happens if the gateway tries to dissuade the client from using XML POST mode, but the client still POSTs to /+webvpn+/index.html (I overrode the check in http.c): $ ./openconnect --os mac -v ltuvpn.latrobe.edu.au Attempting to connect to server 131.172.15.1:443 SSL negotiation with ltuvpn.latrobe.edu.au Matched DNS altname 'ltuvpn.latrobe.edu.au' Connected to HTTPS on ltuvpn.latrobe.edu.au POST https://ltuvpn.latrobe.edu.au/ Got HTTP response: HTTP/1.0 302 Object Moved Content-Type: text/html Content-Length: 0 Cache-Control: no-cache Pragma: no-cache Connection: Close Date: Mon, 04 Mar 2013 02:22:31 GMT Location: /+webvpn+/index.html Set-Cookie: tg=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure HTTP body length: (0) SSL negotiation with ltuvpn.latrobe.edu.au Matched DNS altname 'ltuvpn.latrobe.edu.au' Connected to HTTPS on ltuvpn.latrobe.edu.au POST https://ltuvpn.latrobe.edu.au/+webvpn+/index.html Got HTTP response: HTTP/1.1 400 Bad Request Connection: close X-Transcend-Version: 1 HTTP body http 1.0 (-1) Unexpected 400 result from server SSL negotiation with ltuvpn.latrobe.edu.au Matched DNS altname 'ltuvpn.latrobe.edu.au' Connected to HTTPS on ltuvpn.latrobe.edu.au GET https://ltuvpn.latrobe.edu.au/+webvpn+/index.html Got HTTP response: HTTP/1.1 200 OK Transfer-Encoding: chunked Content-Type: text/xml Cache-Control: max-age=0 Set-Cookie: webvpn=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure Set-Cookie: webvpnc=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure Set-Cookie: webvpnlogin=1; secure X-Transcend-Version: 1 HTTP body chunked (-2) Please enter your username and password. Username: For this server, if the client identifies itself as a Linux PC, the extra redirect doesn't happen: $ ./openconnect --os linux -v ltuvpn.latrobe.edu.au Attempting to connect to server 131.172.15.1:443 SSL negotiation with ltuvpn.latrobe.edu.au Matched DNS altname 'ltuvpn.latrobe.edu.au' Connected to HTTPS on ltuvpn.latrobe.edu.au POST https://ltuvpn.latrobe.edu.au/ Got HTTP response: HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Cache-Control: no-cache Pragma: no-cache Connection: Keep-Alive Date: Mon, 04 Mar 2013 02:36:20 GMT X-Aggregate-Auth: 1 HTTP body chunked (-2) XML POST enabled Please enter your username and password. Username:
