On 12/09/2022 19:18, Daniel Lenski wrote:
On Mon, Sep 12, 2022 at 6:42 AM Ian Braithwaite <i...@tagvision.dk> wrote:
I'm not the original poster, but I'm experiencing the same problem.
Here's the details of the challenge form as requested.
As you guessed, OpenConnect isn't recognizing that a field needs to be
filled in
and is just continuing without it.
I guess it's this one?
<input type="hidden" name="challenge_code" value="0" />
That's a great catch. Also, a nearly identical situation was reported
~10 days ago on GitLab at
https://gitlab.com/openconnect/openconnect/-/issues/489
So now we have *THREE* reports of this on real Cisco servers.
I'm not so sure that field is the right one, after trying your next
suggestion.
I don't know how OpenConnect is supposed to recognize it... weird it's
"hidden".
Questions that may help resolve this issue.
1. Ian, does your server also fall back to the non-XML-based
authentication, like Henry Luis's report and like
https://gitlab.com/openconnect/openconnect/-/issues/489?
Yes it does (redirect, GET /+webvpn+/index.html).
2. Does spoofing an official Cisco Windows client change anything?
(openconnect --os=win --useragent 'Cisco AnyConnect VPN Agent for
Windows 4.9.0195')?)
Very much - OpenConnect successfully connects, without the redirect.
The server response is completely different - the hidden fields are gone
and it has a normal password field that OpenConnect handles just fine:
-+-+-+-
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Transfer-Encoding: chunked
Cache-Control: no-store
Pragma: no-cache
Connection: Keep-Alive
Date: Tue, 13 Sep 2022 09:10:37 GMT
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Content-Security-Policy: default-src 'self' 'unsafe-inline'
'unsafe-eval' data: blob:; frame-ancestors 'self'; base-uri 'self';
block-all-mixed-content
X-Aggregate-Auth: 1
HTTP body chunked (-2)
< <?xml version="1.0" encoding="UTF-8"?>
< <config-auth client="vpn" type="auth-request" aggregate-auth-version="2">
< <opaque is-for="sg">
< <tunnel-group>Konsulent</tunnel-group>
< <auth-handle>417970910</auth-handle>
< <config-hash>1662441803424</config-hash>
< </opaque>
< <auth id="challenge">
< <title>Login</title>
< <message id="2" param1="Indtast tilsendte engangskode"
param2="">%s</message>
< <form>
< <input type="password" name="answer" label="Response:"></input>
< <input type="submit" name="Continue" label="continue"></input>
< </form>
< </auth>
< </config-auth>
Indtast tilsendte engangskode
-+-+-+-
It may be easier to follow up on the GitLab issue:
https://gitlab.com/openconnect/openconnect/-/issues/489#note_1097313325
My best guess about the root cause here is that either it's a result
of a server being misconfigured/confused due to a lack of testing with
non-official clients, OR that it's an intentional obfuscation of the
authentication forms with the intention of confusing non-official
clients.
Or even both :-).
-Ian
Dan
ps- Oddly, we also have a very similar issue with F5 VPNs (*completely
different protocol*) that has popped up recently, wherein the form
fields for 2FA codes get sent in a needlessly obfuscatory way:
https://gitlab.com/openconnect/openconnect/-/issues/493#note_1097084348
_______________________________________________
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
