~mamarley/openconnect/+git/gitlab-main:add_fake-cisco-server.py

Last commit made on 2021-05-25
Get this branch:
git clone -b add_fake-cisco-server.py https://git.launchpad.net/~mamarley/openconnect/+git/gitlab-main

Branch merges

Branch information

Name:
add_fake-cisco-server.py
Repository:
lp:~mamarley/openconnect/+git/gitlab-main

Recent commits

c572016... by Dan Lenski

Use check_http_status in cstp.c

This function was added in d257a7e7cec848c58671ba7df8e035757bf10183
("Consolidate check_http_status from gpst.c and ppp.c").

With this change, there is no longer any place where OpenConnect *expects*
the exact string HTTP/1.1 from a server; it should now accept HTTP/%c.%c everywhere
(even in f5_dtls_catch_probe which handles HTTP-over-DTLS).

This simplifies fake-cisco-server.py, since we can now allow Flask to operate in
its default, naïve HTTP/1.0 mode, and not worry about the complicates of HTTP/1.1
connection reuse in this very simple server.

Signed-off-by: Daniel Lenski <email address hidden>

266f708... by Dan Lenski

WIP: add fake-cisco-server.py

Only offers username/password auth method right now, and doesn't even check the structural validity of the response.

Intended as a starting point for a 'fake-cisco-multiauth-server.py' (see https://gitlab.com/openconnect/openconnect/-/merge_requests/194#note_583857598).

Signed-off-by: Daniel Lenski <email address hidden>

a79fb43... by Dan Lenski

Make xmlnode_get_val() trim whitespace from XML node content

This is motivated by the fact that GlobalProtect portals often put extra
whitespace in the software version tag ('<version> 5.1.2-3
</version>'), and there is no case where we actually want to keep
leading/trailing whitespace.

The function fetch_and_trim() from xml.c already handles the needed
whitespace-trimming behavior, but we need to *duplicate* it (as
xmlnode_get_trimmed_val) in order to use it in both openconnect (the
application) and libopenconnect (the library), without making it a public
function of the library.

Signed-off-by: Daniel Lenski <email address hidden>

1bd1513... by Dan Lenski

Parrot GP server version (from portal) as client software version

Some GlobalProtect gateways reject client connections from software versions
that they think are "too old"
(see https://gitlab.com/openconnect/openconnect/-/issues/176 for an example).
In order to fix this, we have to bump the version of the GP client that
OpenConnect is emulating
(thus https://gitlab.com/openconnect/openconnect/-/merge_requests/131).

Interestingly, the GlobalProtect portal itself includes a server software
version identifier ('<version>X.Y.Z-W</version>' in the response to 'POST
/global-protect/getconfig.esp').

It appears that releases of the server and client software are closely
matched, so one approach to avoiding "client too old" errors is to simply
parrot the software version from the portal back to the gateway as the
*client* version. This commit does just that, (ab)using the
vpninfo->mobile_platform_version field to store the version identifier.

Adding openconnect_set_local_id() API and --local-id CLI option to override
this will provide a more customizable solution to this issue
(https://gitlab.com/openconnect/openconnect/-/merge_requests/103).

Signed-off-by: Daniel Lenski <email address hidden>

200de70... by Dan Lenski

Bugfix GlobalProtect ESP magic pings over Legacy IP

GlobalProtect IPv6 support was added in
https://gitlab.com/openconnect/openconnect/-/merge_requests/188, and
specifically support for initiating an ESP connection via ICMPv6 "magic
pings" in specifically 5b98b62883216cf9306f06c6b3c9dde81bcfe789.

Getting the ICMPv6 packets to have correct checksums was quite tricky (see
commit notes) and the commit was revised several times.

Somehow we managed to remove the pre-existing code to compute the checksum
correctly in the case of ICMPv4 "magic pings", leaving behind an ICMPv4
checksum that's always zero (and thus rejected by the server, and never
correctly initiates a connection).

Signed-off-by: Daniel Lenski <email address hidden>

066b005... by dwmw2

Fix store_le16/store_le32 harder

Signed-off-by: David Woodhouse <email address hidden>

0cfdb7b... by Tom Carroll <email address hidden>

Use C99 initializer instead of memset.

Strictly speaking, using memset() here violates strict aliasing rules,
and it would be entirely permissible for an assert() like this example
to *fail*:

 struct gtls_cert_info gci;

 memset(&gci, 0, sizeof gci);
 assert(gci.pkey == NULL);

Signed-off-by: Tom Carroll <email address hidden>

63c984b... by dwmw2

Add more buf_append_base64() tests... and fix it.

Signed-off-by: David Woodhouse <email address hidden>

3b88d27... by dwmw2

Fix first line length in buf_append_base64()

We need to add four (for the characters we're about to append) *after*
checking against line_len and resetting ll to zero. Otherwise the first
line thinks it starts at 4 while the others start at 0.

Signed-off-by: David Woodhouse <email address hidden>

51ff522... by dwmw2

Validate line_len argument to buf_append_base64() too

Based on a patch by Tom Carroll <email address hidden>

Signed-off-by: David Woodhouse <email address hidden>