Nikos Mavrogiannopoulos [Fri, 10 May 2024 18:29:44 +0000 (20:29 +0200)]
.gitlab-ci.yml: use saas-linux-small-amd64 as tag
The linux and shared tags are deprecated:
https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#removal-of-tags-from-small-saas-runners-on-linux
Dimitri Papadopoulos [Wed, 28 Feb 2024 06:31:00 +0000 (07:31 +0100)]
Search wintun.dll in the application directory only
Now that wintun.dll is installed in the application directory by
both openconnect and openconnect-gui packages, we can get rid of
LOAD_LIBRARY_SEARCH_SYSTEM32.
Wade Cline [Wed, 28 Feb 2024 03:19:00 +0000 (19:19 -0800)]
Fix logging of rekey / trojan invocation delay
Closes #677
The rekey / trojan invocation is supposed to happen in the future.
Therefore subtract current time from expected time of rekey / invocation,
not the reverse.
Marios Paouris [Thu, 22 Feb 2024 10:03:01 +0000 (12:03 +0200)]
MinGW build improvements
- Decoupled wintun and vpnc-script-win.js from building installer.
- Added required dependencies for downloading wintun and vpnc-script-win.js.
- Install wintun, vpnc-script-win.js and list-system-keys by default.
- Added configure option to disable building installer (doesn't work in
msys/mingw builds, can also speedup build when no installer required).
Nikos Mavrogiannopoulos [Wed, 21 Feb 2024 21:24:56 +0000 (22:24 +0100)]
openssl-dtls: use DTLS 1.2 for PSK-NEGOTIATE
Avoid reducing the security level for PSK-NEGOTIATE by
setting DTLS 1.2. This works well because all PSK-NEGOTIATE
ocserv servers are using gnutls that supports DTLS 1.2.
This addresses a previously undetermined issue with DTLS on centos7.
The openconnect client disables DTLS if it fails to
connect. Openconnect-gui couldn't do that because of
the restrictions of openconnect_disable_dtls(). This
MR removes those restrictions and allows disabling DTLS
even if we attempted connection before.
Daniel Lenski [Fri, 29 Sep 2023 20:51:07 +0000 (13:51 -0700)]
Modify `fake-gp-server.py` to add regionalized priority-rules to the gateway list
The fake GP server will now assign the connecting user to a random planet in
its portal prelogin response, then randomly and haphazardly prioritize the
gateways by planet.
For example, start fake-gp-server.py, then configure it with 3 gateways:
$ curl -k https://localhost:8080/CONFIGURE -d gateways=Red,Orange,Yellow
$ curl -k https://localhost:8080/CONFIGURE
Current configuration of fake GP server configuration:
TestConfiguration(gateways=['Red', 'Orange', 'Yellow'], ...)
Then attempt to connect to it:
$ openconnect --protocol=gp --dump-http-traffic localhost:8080
...
Greetings, user from MERCURY. Please login to this fake GP VPN portal
Username: bar
Password:
POST https://localhost:8080/global-protect/getconfig.esp
...
< <?xml version="1.0" encoding="UTF-8" ?>
< <policy><version> 6.7.8-9 </version><gateways><external><list>
< <entry name="localhost:8080">
< <description>Red</description>
< <priority-rule>
< <entry name="VENUS"><priority>1</priority></entry>
< <entry name="Any"><priority>99</priority></entry>
< </priority-rule>
< </entry>
< <entry name="localhost:8080">
< <description>Orange</description>
< <priority-rule>
< <entry name="JUPITER"><priority>2</priority></entry>
< <entry name="MARS"><priority>1</priority></entry>
< </priority-rule>
< </entry>
< <entry name="localhost:8080">
< <description>Yellow</description>
< <priority-rule>
< <entry name="MERCURY"><priority>1</priority></entry>
< <entry name="EARTH"><priority>2</priority></entry>
< </priority-rule>
< </entry></list>
< </external></gateways>
< <hip-collection><hip-report-interval>600</hip-report-interval></hip-collection>
< </policy>
Portal reports GlobalProtect version 6.7.8-9; we will report the same client version.
Portal set HIP report interval to 10 minutes).
5 gateway servers available:
Red (localhost:8080) [priority 99]
Orange (localhost:8080) [unprioritized]
Yellow (localhost:8080) [priority 1]
Please select GlobalProtect gateway.
GATEWAY: [Yellow|Red|Orange]:
Note that the gateways are now presented to the user in the priority order
for the user's "region" of MERCURY.
Starting from version 8.0, PAN GlobalProtect portal servers are able to send
a priority rule list for each gateway. Per
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClSsCAK,
the gateways can be prioritized by geographic region.
The gateways should then be presented to the user in order of geographic
priority, rather than just in their order of appearance in
policy/gateways/external/list (from the portal config XML).
How does the client know which geographic region it is in?
1. The client itself may have some way to figure out which region it is
connecting from (e.g. geolocation, not implemented yet for OpenConnect).
2. The client may have an option to explicitly specifiy the desired region
(not implemented yet in OpenConnect).
3. The *server* tells the client which region it thinks the client is
connecting from, in the portal *prelogin* response, and the client
follows that (implemented here).
Fixes: https://gitlab.com/openconnect/openconnect/-/issues/663
[DRL fixed a small mistake in qsort usage, and tweaked code structure,
comments, and log messages.]
Signed-off-by: Jan-Michael Brummer <jan-michael.brummer1@volkswagen.de> Signed-off-by: Daniel Lenski <dlenski@gmail.com>
Daniel Lenski [Tue, 20 Feb 2024 06:12:20 +0000 (22:12 -0800)]
Update changelog
This bug in GlobalProtect IPv6 split-include handling was introduced in
https://gitlab.com/openconnect/openconnect/-/commit/a2b8134edf8e5f8e942dedf105e2813a0824b919;
see also
https://gitlab.com/openconnect/openconnect/-/merge_requests/367#note_1780223796.
Daniel Loxtermann [Tue, 20 Feb 2024 01:59:47 +0000 (17:59 -0800)]
Fix GlobalProtect config-parsing bug that misidentified IPv6 split-include routes as split-exclude
As reported on the mailing list at
https://lists.infradead.org/pipermail/openconnect-devel/2024-January/005386.html,
the relevant code wasn't handling the IPv6 case correctly.
Daniel Lenski [Mon, 25 Sep 2023 14:14:37 +0000 (07:14 -0700)]
Send 'cas-support=yes' in GlobalProtect prelogin request
Per https://gitlab.com/openconnect/openconnect/-/issues/651, some newer GP
servers are responding to prelogin.esp requests with an error:
CAS is not supported by the client. Minimum client version is 6.0
It appears that CAS ("Central Authentication Server";
https://apereo.github.io/cas/index.html) is a standardized single-sign-on
protocol requiring an external browser.
Per https://gitlab.com/openconnect/openconnect/-/issues/651#note_1576596243,
the field 'cas-support=yes' needs to be sent in the POST *body* of the
prelogin request, in order to avoid this error message; the error message's
claim that a specific client software version is necessary isn't very
helpful.
Daniel Lenski [Tue, 26 Sep 2023 19:08:45 +0000 (12:08 -0700)]
Real GlobalProtect SAML authentication forms won't work without JavaScript
This adds a 'saml_needs_js' option to fake-gp-server.py. If set, the fake
SAML login form that it generates won't work correctly without JavaScript
execution, just like a "real" GlobalProtect SAML server.
Jon DeVree [Sat, 3 Feb 2024 17:09:58 +0000 (12:09 -0500)]
Force final newline in xmlstarlet
By default xmlstarlet does not include a final newline on the output.
Because POSIX says that all lines must end in a newline, this causes the
final line of output to be skipped by the 'while read ...' loop in bash.
Adding a '-n' after the '-v ...' causes xmlstarlet to include a final
newline at the end of its output.
Brahmajit Das [Mon, 29 Jan 2024 17:58:53 +0000 (23:28 +0530)]
Fix implicit declaration of function 'malloc'
First observed on Gentoo Linux with GCC 14. This is due to GCC 14
enabling -Werror=implicit-function-declaration by default.
Thus resulting in errors such as:
openconnect-internal.h: In function 'alloc_pkt':
openconnect-internal.h:911:27: error: implicit declaration of function 'malloc' [-Werror=implicit-function-declaration]
911 | struct pkt *pkt = malloc(alloc_len);
| ^~~~~~
Plese refer gentoo bug: https://bugs.gentoo.org/923173 Signed-off-by: Brahmajit Das <brahmajit.xyz@gmail.com>
../mtucalc.c: In function 'calculate_mtu':
../mtucalc.c:75:33: warning: passing argument 4 of 'getsockopt' from incompatible pointer type [-Wincompatible-pointer-types]
75 | &mss, &mss_size)) {
| ^~~~
| |
| int *
In file included from ../openconnect-internal.h:31,
from ../mtucalc.c:20:
C:/msys64/mingw64/include/winsock2.h:1010:82: note: expected 'char *' but argument is of type 'int *'
1010 | WINSOCK_API_LINKAGE int WSAAPI getsockopt(SOCKET s,int level,int optname,char *optval,int *optlen);
| ~~~~~~^~~~~~
CC libopenconnect_la-lzo.lo
../cstp.c: In function 'calculate_dtls_mtu':
../cstp.c:134:33: warning: passing argument 4 of 'getsockopt' from incompatible pointer type [-Wincompatible-pointer-types]
134 | &mss, &mss_size)) {
| ^~~~
| |
| int *
In file included from ../openconnect-internal.h:31,
from ../cstp.c:21:
C:/msys64/mingw64/include/winsock2.h:1010:82: note: expected 'char *' but argument is of type 'int *'
1010 | WINSOCK_API_LINKAGE int WSAAPI getsockopt(SOCKET s,int level,int optname,char *optval,int *optlen);
| ~~~~~~^~~~~~
They add spaces (BWS) at the end of chunk-size, even in the absence of chunk-ext.
Be lenient when parsing chunk:
1. Accept bogus chunk-ext, with ";" not followed by chunk-ext-name.
2. Discard leading/trailing spaces in chunk-size, strtol() will do that for us.
Nikos Mavrogiannopoulos [Wed, 10 Jan 2024 19:51:37 +0000 (20:51 +0100)]
nsis: create self-contained nsi file
Including from a relative path is interpreted differently
depending on where the caller is started. This allows running
nsis on the output nsi even if not located at the build directory.
warning 9100: Generating version information for language
"1033-English" without standard key "FileVersion"
warning 9100: Generating version information for language
"1033-English" without standard key "FileDescription"
<libxml/tree.h> used to be included both by "openconnect-internal.h"
and from *.c source files. We don't need both. Let's settle on including
from "openconnect-internal.h" only.
Rahul Rameshbabu [Thu, 21 Dec 2023 20:46:08 +0000 (12:46 -0800)]
cstp: Check if uri is NULL in sso_detect_done
Passing a NULL value to strcmp is undefined behavior. Some web engines
might have events where cookies are enumerated, but the event does not
contain a uri enumeration. An example is QtWebEngine where it has discrete
signals, QWebEngineView::urlChanged and QWebEngineCookieStore::cookieAdded.
Add a check similar to the one found in gpst_sso_detect_done for the uri
member of struct oc_webview_result.
Because we know the code in `main.c` is executed in a single-threaded
environment, we don't need to modify non-reentant functions in this file,
unless some linter complains in the future:
* localtime()
* getpwnam()
The only remaining non-entrant function is:
* getpwuid()
Using constant 2049 instead of sysconf(_SC_GETPW_R_SIZE_MAX) might not
be the best idea. I want to avoid dynamic allocation. On Ubuntu 18.04,
sysconf(_SC_GETPW_R_SIZE_MAX) is 1024, so 2049 "ought to be enough".
From the POSIX documentation of ctime:
The ctime() function shall convert the time pointed to
by clock [...] to local time in the form of a string.
It shall be equivalent to:
asctime(localtime(clock))
From the POSIX documentation of asctime:
The asctime() function shall convert the broken-down time
in the structure pointed to by timeptr into a string in the
form:
Sun Sep 16 01:03:52 1973\n\0
We need to get rid of that new line otherwise it appears in the log.
The POSIX documentation goes on:
These functions are included only for compatibility with older
implementations. They have undefined behavior if the resulting
string would be too long, so the use of these functions should
be discouraged. On implementations that do not detect output
string length overflow, it is possible to overflow the output
buffers in such a way as to cause applications to fail, or
possible system security violations. Also, these functions do
not support localized date and time formats. To avoid these
problems, applications should use strftime() to generate
strings from broken-down times.
Because we have already been using strftime() with gmtime() elsewhere,
using strftime() with locatime() here makes sense.
The i1On mechanisme we currently use to print dates is non-sensical:
we force the format string to "%a, %d %b %Y %H:%M:%S" which might not
make sense in some locales. We shall fix i10n in a different merge
request or commit.
Daniel Lenski [Tue, 26 Sep 2023 22:29:48 +0000 (15:29 -0700)]
Change default user-agent string to be compatible with newer Cisco servers
See https://gitlab.com/openconnect/openconnect/-/issues/665 for a summary of
this issue.
This implements the simplest reasonable solution to the problem: Just Change
The Default™ UA string.
Short summary: Cisco did something stupidly backwards-incompatible in their
authentication flow. It's hard to tell if it was due to incompetence or due
to malice towards unofficial clients
(https://gitlab.com/openconnect/openconnect/-/issues/635#note_1451782874)
but it doesn't really matter.
If merged, this should fix #544, #593, #602, #618, #635, #657, #662,
and #665.
Daniel Lenski [Sat, 30 Sep 2023 05:02:33 +0000 (22:02 -0700)]
Bugfix GP XML config: always include portal
Ever since 8e7efd51f, the GlobalProtect *portal* has been included in the
newly-written XML config (`<ServerList>`) only if the portal config XML
contained a `<portal-name>` tag.
We should include the portal even if it doesn't have a name for itself.
Daniel Lenski [Fri, 22 Sep 2023 16:54:11 +0000 (09:54 -0700)]
GlobalProtect SAML completion pages sometimes have the SAML fields only in comments
This modifies the fake GP server to have a 'saml_comments_only' option. If
set, the SAML completion fields ('saml-username', 'prelogin-cookie', etc.)
will be sent to the client *only* in a blob of XML wrapped in HTML comments,
and *not* in HTTP headers.
Some real GP servers are known to behave like this, and authentication
handlers like 'gp-saml-gui' need to be able to handle this case correctly
(see https://github.com/dlenski/gp-saml-gui/issues/51 and
https://github.com/dlenski/gp-saml-gui/pull/59).
Some GlobalProtect servers complain about old versions of the client
software connecting to them.
In the case of a connection via the GlobalProtect "portal" interface,
we capture the preferred software version from the portal and parrot it back,
as of https://gitlab.com/openconnect/openconnect/-/commit/c0d2daeaa85f69ed2f89330a53d97ae7eafdffb1?merge_request_iid=333.
However, we should update the GlobalProtect software version used as a fallback
in the case of a direct connection to the "gateway" interface.
Signed-off-by: Dimitri Papadopoulos <3234522+DimitriPapadopoulos@users.noreply.github.com> Signed-off-by: Daniel Lenski <dlenski@amazon.com>
projects / users / dwmw2 / openconnect.git / log