Re: MITM to a cisco client

[David Woodhouse]

On Wed, 2024-05-08 at 17:59 -0600, Oscar Velazquez wrote:
> 
> 
> I have a hunch: it is to change server-cert-hash, but I do not know 
> what the correct values could be or if this is a valid approach.
> Any help would be appreciated.
> 

Probably the sha1 fingerprint of the (real) server's SSL certificate.

In http://david.woodhou.se/proxy.go there's support for changing such a
hash to the hash of the cert you're using for the proxy itself.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Does OpenConnect handle SCEP?

[David Woodhouse]

On Sat, 2024-04-27 at 22:56 -0400, marc...@gmail.com wrote:
> 
> I've been looking online for an alternative to Cisco AnyConnect client
> (which I haven't been able to get working on Linux) and I saw people
> recommending OpenConnect. My workplace VPN is configured to do
> certificate enrollment when connecting for the very first time, which
> I believe is done through SCEP (simple certificate enrollment
> protocol). I've installed and tried NetworkManager-openconnect but it
> doesn't seem to do this initial certificate enrollment. Does
> OpenConnect implement SCEP?

It doesn't. And unless it's integrated with the protocol to the point
where it *absolutely* necessary, I think I'd prefer it to remain that
way — at least for OpenConnect *itself*.

But if this is a setup that people need to use, we should definitely
work out how to integrate it with an existing SCEP client.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: SSL connection failure: PKCS #11 error

[David Woodhouse]

On Fri, 2024-03-08 at 11:54 +0100, traxto...@gmail.com wrote:
> 
> if I attempt the gnutls-cli command, I see the following.
> gnutls-cli --x509certfile=cert.pem --
> x509keyfile="pkcs11:model=%01%01%04%00%02%01%02%00%00%00%00%00%00%00%00
> %00;manufacturer=STMicro;serial=;token=TL_ECC256;id=%55
> %34%65%38%63%66%65%35%64%61%33%66%30%62%33%33;object=KL_ECC256;type=pri
> vate;pin-value=userpin" vpn.com

That's using it via PKCS#11. Can you just use the '-BEGIN TSS2
PRIVATE KEY-' PEM file instead? Isn't that what you were using with
OpenConnect?


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: SSL connection failure: PKCS #11 error

[David Woodhouse]

On 7 March 2024 19:03:33 GMT, traxto...@gmail.com wrote:
>David,
>tried to patch it no luck
>i.e.
>diff -ur openconnect-9.12.orig/gnutls_tpm2_esys.c openconnect-
>9.12/gnutls_tpm2_esys.c
>--- openconnect-9.12.orig/gnutls_tpm2_esys.c   2022-04-28
>17:58:05.0 +0200
>+++ openconnect-9.12/gnutls_tpm2_esys.c2024-03-07 16:03:54.521631835
>+0100
>@@ -498,12 +498,11 @@
>   case SHA1_SIZE:   inScheme.details.ecdsa.hashAlg =
>TPM2_ALG_SHA1;   break;
>   case SHA256_SIZE: inScheme.details.ecdsa.hashAlg =
>TPM2_ALG_SHA256; break;
>   case SHA384_SIZE: inScheme.details.ecdsa.hashAlg =
>TPM2_ALG_SHA384; break;
>-  case SHA512_SIZE: inScheme.details.ecdsa.hashAlg =
>TPM2_ALG_SHA512; break;
>+  case SHA512_SIZE: inScheme.details.ecdsa.hashAlg =
>TPM2_ALG_SHA512; digest.size = 32 ; break;
>   default:
>-  vpn_progress(vpninfo, PRG_ERR,
>-   _("Unknown TPM2 EC digest size %d for
>algo 0x%x\n"),
>-   data->size, algo);
>-  return GNUTLS_E_PK_SIGN_FAILED;
>+inScheme.details.ecdsa.hashAlg = TPM2_ALG_SHA512; 

That wants to be SHA256 too.

>+digest.size = 32;
>+break;
>   }
> 
>   memcpy(digest.buffer, data->data, data->size);
>
>I am on Fedora 39 using gnutls-3.8.3-1.fc39.x86_64

Ah, by v3.8 GnuTLS actually includes my TPMv2 code natively. Can you test with 
gnutls-cli connecting to the same server with the same key?


___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: SSL connection failure: PKCS #11 error

[David Woodhouse]

On Wed, 2024-03-06 at 12:44 +0100, Grant Williamson wrote:
> I am attempting to transition our existing environment of signed
> Digicert certificates from RSA-4096 to ECC256. The digicert one
> signing process appears to work.
> When using a software-emulated TPM, the connection is succesful.
> 
> When I try hardware tpm(3 laptops) I encounter the folowing problem
> ERROR: Esys_Sign: tpm:parameter(1):structure is the wrong size
> SSL connection failure: PKCS #11 error.
> 
> I have tried generating the csr to be signed using both tpm2-openssl
> and pkcs11-provider, same result.
> 
> Maybe the following gives a clue. Any ideas?
> (openconnect with --gnutls-debug=99 -v)
> 
> https://pastebin.com/d2gT4t6q

I think that's a GnuTLS bug. What version of GnuTLS is it?

If you're using a Prime256 key, then the SHA512 hash ought to be
truncated to 32 bytes, and then we'd tell the TPM that it's actually a
SHA256. See 
http://git.infradead.org/?p=users/dwmw2/openconnect.git;a=blob;f=gnutls_tpm2_esys.c;hb=HEAD#l487

As a nasty hack, since you know you have a 256-bit EC key (although I
didn't personally validate that assertion in your logs), can you try
hard-coding it to use TPM2_ALG_SHA256 and set digest.size=32 in
tpm2_ec_sign_hash_fn() ? 

Do this in either gnutls_tpm2_esys.c or gnutls_tpm2_ibm.c; whichever is
being used on your system. Probably the former.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Openconnect to bypass CGNAT

[David Woodhouse]

On Thu, 2023-12-14 at 11:55 -0300, Paulo Wollny wrote:
> Dear All,
> 
> i have sucessefully installed openconnect (ocserv on my VPS and 
> openconnect on my home server) and works.
> 
> As my home server is sitting behind a CGNAT, i need help to create the 
> forwarding rules for some ports, like 8081 from 0.0.0.0 to the VPS to my 
> internal 8081 server port.

Can't you just route a full /64 subnet to the home network via the VPS?



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: csd-post.sh "You are attempting to use a digital certificate not assigned to this device"

[David Woodhouse]

On Fri, 2023-06-30 at 11:09 -0700, Daniel Lenski wrote:
> On Mon, Jun 26, 2023 at 4:56 AM Grant Williamson  wrote:
> > I'm encountering an issue with the csd-post.sh script. When attempting
> > to use it, I receive the error message: "You are attempting to use a
> > digital certificate not assigned to this device." I would appreciate
> > any insights on how to add support for when a server cross checks the
> > MAC address functionality in the script.
> 
> > Helps if I just try using what is there. Sorry.
> > endpoint.device.MAC[".."]="true";
> 
> Glad you figured out, but… wow.
> 
> "Digital certificate not assigned to this device" is a very
> misleading/unclear/irrelevant error message for "you didn't tell us
> your MAC address."

To be fair, we *did* tell it our MAC address. We just *lied* and told
it our MAC address was FF:FF:FF:FF:FF:FF. While using a certificate
assigned to some other device.

Using a MAC address as the host identifier isn't that unusual (although
it does have issues when you have multiple devices, and it's better to
use the system UUID from /etc/machine-id where it exists).




smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Split Tunneling based on domain name possible?

[David Woodhouse]

On Tue, 2023-06-06 at 10:09 +0200, Michael Herzhauser wrote:
> Hello, 
> 
> I've setup Ocserv in my corporate network with split tunneling and it's
> working good so far.
> However some of my colleagues in home office need to connect to some cloud
> servers of 
> our customers, which implement IP whitelisting to our company's public IP. 
> Due to split tunneling, requests to these cloud servers are not routed via
> VPN but the normal
> internet connection and the connection gets blocked.
> 
> Therefore I'd like to add a route based on the domain name of these servers 
> (public IPs of these servers are dynamically assigned and change
> frequently), but didn't find 
> any information about that. All the examples in the config file only use IP
> addresses.
> 
> Is it even possible? And if so, any info on syntax (e.g wildcards for
> subdomains) would be great to have.
> Otherwise I'd have to convert to "tunnel all", which I'm trying to avoid.

I think we did have something like this implemented on the client side
in ConnMan once. It would monitor the DNS lookups and automatically add
routes to the target IP address.

Probably easier to do it with a proxy PAC file though, and set the
relevant domains to use a proxy within your corporate network.




smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

OpenConnect 9.12 release

[David Woodhouse]

They're like buses. Wait a year, and then three come along at once.

This fixes the MacOS and FreeBSD builds. I'd really like to get some
kind of CI on those.

It also increases the maximum size (of e.g. cookie) read from stdin to
4KiB and doesn't attempt to configure a WINS server address of 0.0.0.0.

The openconnect_set_sni() function added in v9.10 should not have been
retrospectively added to the @OPENCONNECT_5_8 library API. That's not
how symbol versions work. It's moved to @OPENCONNECT_5_9, and I've
finally implemented the tests I promised when I released v9.01 a year
ago. As a side-effect of sanity-testing the symbol versions, we now
also provide a symbols file to assist with Debian-style packages
getting their dependencies right (and use it in the OBS autobuilds).

https://www.infradead.org/openconnect/download/openconnect-9.12.tar.gz
https://www.infradead.org/openconnect/download/openconnect-9.12.tar.gz.asc

David Woodhouse (18):
  Fix Windows installer links
  Add dpkg-gensymbols template file and test for ABI violations
  Move openconnect_set_sni() to API v5.9
  Fix library dependencies for OBS Debian packages
  Attempt to put OBS libopenconnect5.symbols in the right place
  Slightly cleaner dpkg-gensymbols invocation
  Merge branch 'optipng' of gitlab.com:openconnect/openconnect
  Fix time_t handling in parsing F5 session timeout
  Disable explict setting of IP_PMTUDISC_DO on MacOS
  Fix link to OpenBSD port
  Fix unaligned accesses in ESP checksum calculation
  Always define 'environ' in POSIX systems
  Clean up ifreq_set_ifname() and use it from bsd_open_tun() too
  Use extended regular expressions in gensymbols.sed
  os-tcp-mtu.c: Explicitly include  for sockaddr_in(6|)
  Update changelog
  Update translations from GNOME
  Tag version 9.12

Dimitri Papadopoulos (3):
  Optimize PNG compression
  Increase limited read_stdin() max buffer size
  Ignore non-sensical NBNS/WINS server address

Mike Gilbert (1):
  Move JSON_CFLAGS before LIBPROXY_CFLAGS



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: [Networkmanager] NetworkManager-openconnect 1.2.10 release

[David Woodhouse]

On Wed, 2023-05-17 at 16:43 -0700, Daniel Lenski wrote:
> On Wed, May 17, 2023 at 12:00 PM David Woodhouse  wrote:
> > 
> > Traxtopel (1):
> >    Add support for OpenConnect's `--no-dtls` option to disable UDP
> 
> This one has been much sought-after
> (https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/merge_requests/55
>  )…
> 
> Now if users are connecting from bizarre/broken networks, we can tell
> them "Just disable DTLS/ESP, and deal with a slow TLS-based tunnel"…
> like we can do with the command-line client. Of course, we still
> continue to make OpenConnect [even more] robust against broken/mangled
> connections to the VPN servers, but this will help a lot of users
> overcome their immediate pain points.
> 
> Hooray 

Indeed. Thanks again to everyone who helped get that release out the door.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

NetworkManager-openconnect 1.2.10 release

[David Woodhouse]

Overview of changes since NetworkManager-openconnect-1.2.8
==

This is a new stable release of NetworkManager-openconnect.  Notable
changes include:

* Improved cancellation handling.
* Support SAML/SSO authentication for some VPN protocols.
* Allow useragent override.
* Support webkit2gtk-4.1.
* Allow choosing certificates/keys from PKCS#11 tokens.
* Allow custom interface name.
* Allow UDP connectivity to be disabled.
* Support multi-certificate authentication for AnyConnect.
* Fix hangs with external browsers which spam stdout.
* Update translations.



Download

https://download.gnome.org/sources/NetworkManager-openconnect/1.2/NetworkManager-openconnect-1.2.10.tar.xz
 (899K)
  sha256sum: 844b6bf64ecadb97b4a68c776db89aa5e6ee7e59bd24b0180228406863136464


Changes
===


Alan Mortensen (2):
  Update Danish translation
  Update Danish translation

Andika Triwidada (1):
  Update Indonesian translation

Asier Sarasua Garmendia (4):
  Update Basque translation
  Update Basque translation
  Update Basque translation
  Update Basque translation

Daniel Lenski (1):
  Fix inconsistent line endings in Uyghur translation

David Woodhouse (61):
  update strings
  Merge branch 'obs' into 'main'
  update strings
  Merge branch 'obs' into 'main'
  Merge branch 'openconnect-8_20-fix' of 
gitlab.gnome.org:knut.tidemann/NetworkManager-openconnect into main
  update strings
  Reinstate some Basque translations lost by accident
  update strings
  Merge branch 'citest' of 
gitlab.gnome.org:GNOME/NetworkManager-openconnect into main
  Merge branch 'fix-dialog-timeout' of 
gitlab.gnome.org:tik-stbuehler/NetworkManager-openconnect into main
  Merge branch 'webview_gp' of 
gitlab.gnome.org:bluca/NetworkManager-openconnect into main
  Merge branch 'codespell' of 
gitlab.gnome.org:DimitriPapadopoulos/NetworkManager-openconnect into main
  Add generated gtk4/nm-openconnect-dialog/ui to git repository
  Touch gtk4/nm-openconnect-dialog.ui to ensure it's newer
  Add OpenConnect COPR to build against latest libopenconnect
  Handle default routes in split excludes
  Merge branch 'fix-9' of 
gitlab.gnome.org:asymptotically/NetworkManager-openconnect into main
  Merge branch 'dbus-dir' into 'main'
  Merge branch 'fix-non-interactive-mode' of 
gitlab.gnome.org:kemurphy/NetworkManager-openconnect into main
  Merge branch 'webview_gp' into 'main'
  Link plugin against glib explicitly
  Prevent noise to stdout
  Add gmodule-2.0 to plugin link
  Merge branch 'webview_gp' of 
gitlab.gnome.org:bluca/NetworkManager-openconnect into main
  Merge branch 'thisguy726-master-patch-66046' of 
gitlab.gnome.org:thisguy726/NetworkManager-openconnect into main
  update strings
  Use openconnect_set_useragent() where available
  Update gtk4 resource file for user-agent prop
  Add make_srpm files for COPR
  Update strings, some s/openconnect/OpenConnect/
  Don't allow empty useragent string to be used for override
  Merge branch 'user-agent-gtk4' into 'main'
  Fix COPR builds
  update strings
  Update strings
  Add missing translation from OpenConnect
  Merge branch 'lr/pkcs11' of 
ssh.gitlab.gnome.org:GNOME/NetworkManager-openconnect
  Merge branch 'bugfix/user_agent_export' of 
ssh.gitlab.gnome.org:Binary-Eater/NetworkManager-openconnect
  Merge branch 'fix_line_endings' of 
ssh.gitlab.gnome.org:dlenski/NetworkManager-openconnect
  Merge branch 'add_iface' of 
ssh.gitlab.gnome.org:dlenski/NetworkManager-openconnect
  Merge branch 'add_DisableUDP_option' of 
ssh.gitlab.gnome.org:dlenski/NetworkManager-openconnect
  Fix COPR specfile to BR webkit2gtk-4.1
  update strings
  Fix build warnings in interface creation
  Re-enable webkit 4.0 build
  Fix gtk4 crash in gnome-control-center
  Remove more superfluous properties on 'Disable UDP' button
  Merge branch 'add_mca' of 
ssh.gitlab.gnome.org:ebendler/NetworkManager-openconnect
  Hide machine cert chooser for protocols which don't support it
  Clean up initial host URL parsing
  Don't force PreventInvalidCert setting
  Remove unused group variable
  Fix loading of CA cert field from config
  Send \n\n termination even if there are no secrets to output
  Handle QUIT during connection attempt
  Work around nm-applet sending QUIT too soon
  Update import-strings.sh
  Give stable links for translation hints
  Merge branch 'feature/openconnect_external_browser_callback' of 
ssh.gitlab.gnome.org:Binary-Eater/NetworkManager-openconnect
  Update NEWS file for imminent 1.2.10 release
  release: bump version to 1.2.10

Debasish Patra (1):
  Add User Agent to Openconnect VPN for NetworkManager

Dimitri Papadopoulos (1):
  Fix typos found by codespell

Dmitry Nezhevenko (1

OpenConnect 9.11 release

[David Woodhouse]

The CA certificate used for the test suite expired this week, making
all the tests fail. Now bumped to 2050 by which time it'll probably be
someone else's problem.

Also fix a couple of problems with Global Protect — ESP configuration
was broken, and some changes in new servers have highlighted that we
weren't correctly case insensitive when checking for some headers.

This attempts to add external browser support on Windows; it seems to
work under Wine at least.

Fix `openconnect --authenticate` for Pulse with a non-empty path, which
was previously emitting a literal `/(null)` as the path and causing a
connection failure. This would affect the NetworkManager auth dialog
too.

https://www.infradead.org/openconnect/download/openconnect-9.11.tar.gz
https://www.infradead.org/openconnect/download/openconnect-9.11.tar.gz.asc


Daniel Lenski (3):
  Add os-tcp-mtu utility
  Fix broken ESP config parsing for GlobalProtect
  Update changelog

David Woodhouse (19):
  Build release builds as snapshots for COPR
  Fix stray (null) in URL path after Pulse authentication
  Make GCC shut up about unknown pragmas in wintun.h
  Silence warnings about type aliasing when resolving wintun DLL functions
  Consolidate browser spawn functions
  Switch from egrep to 'grep -E'
  Build COPR package with xdg-open
  Attempt to spawn browser on Windows
  Update translations from GNOME
  Fix order-only rule dependency variables
  Add rule to rebuild ca.pem
  Ensure swtpm is started before making CSRs with it
  Change to using key fingerprint for --servercert in tests
  Rebuild all test certificates
  Merge branch 'gpst-xml-config' of gitlab.com:nemo-44/openconnect
  Merge branch 'gpst-xml-config' into 'master'
  Merge branch 'man/external_browser' of gitlab.com:Binary-Eater/openconnect
  Merge branch 'win32-extbrowser' of gitlab.com:openconnect/openconnect
  Tag version 9.11

Dimitri Papadopoulos (1):
  Document that OpenConnect calculates TOTP/HOTP codes on its own

Jan-Michael Brummer (1):
  gpst: Check headers case insensitive

Luca Boccassi (2):
  OBS: softhsm is not available in SUSE
  Merge branch 'softhsm' into 'master'

Rahul Rameshbabu (1):
  Add manpage documentation for --external-browser option



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect 9.10 release

[David Woodhouse]

On Tue, 2023-05-16 at 22:42 -0700, Daniel Lenski wrote:
> > Daniel Lenski (101):
> >    …
> >    Combine Legacy IP and IPv6 cases in GP config XML parsing>
> >    …
> 
> Unfortunately, this change introduced a bug — that is to say, I
> introduced a bug (爵) — which causes GlobalProtect ESP to be entirely
> non-functional in OpenConnect v9.10.
> 
> Thanks to nem...@gmail.com for bringing this to our attention. We've
> got a merge request for the one-line fix up
> (https://gitlab.com/openconnect/openconnect/-/merge_requests/475).
> 
> @dwmw2, how 'bout an OpenConnect v9.11 release? 

Yeah, and all the certificates in the test suite expired this week too.
I'm *really* glad I scripted all the generation of those. Just working
on doing it on a sufficiently old version of SoftHSM that it doesn't
break the tests for CentOS 9 and Ubuntu 18.

We should pull in the case sensitivity fix in MR !474 too.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: vpn issue

[David Woodhouse]

On 11 May 2023 22:12:16 BST, Sam Taylor  wrote:
>To configure local networking, openconnect must be running as root
>See https://www.infradead.org/openconnect/nonroot.html for more information
>
>Do you happen to know how I can fix this?

The web page you mentioned is a good place to look.

If you're on Linux, the best option is to configure the network in 
NetworkManager and let it handle the permissions. Or just run oprnconnect as 
root, using "sudo" or similar.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: [Networkmanager] NetworkManager-openconnect(gnome-control-center network) UI apply does not close

[David Woodhouse]

On Tue, 2023-05-09 at 10:11 +0100, David Woodhouse wrote:
> On Sat, 2023-05-06 at 06:41 +0200, Grant Williamson wrote:
> > There's a minor issue that I've noticed. When I edit a connection
> > using nm-connection-editor, I'm able to save the changes without any
> > problems. However, if I try to edit a connection using the
> > gnome-control-center network method, the changes can still be applied
> > but the dialog box doesn't close automatically. After clicking on
> > apply, I have to manually click on cancel to exit the dialog box.
> 
> Right. And if you run it from the command line, you'll see it say this:
> 
> 09:40:58.0880   nm[260279]:CRITICAL: ((src/libnm-
> client-impl/nm-device.c:2450)): assertion '' failed
> 
> You get the same when creating a new connection. And then if you click
> 'Apply' again it says this:
> 
> 09:41:07.1184 cc-network-panel[260279]: WARNING: Failed to add
> connection: a connection with this UUID already exists
> 
> And this some the dialog *does* close, giving you no indication at all
> in the UI that it thinks it failed!
> 
> I then can't *open* that connection again successfully. gnome-control-
> center just spins as if 'loading' it, for ever. And nm-connection-
> editor seems to lack the actual VPN config pane; it just has the
> standard IP/DNS configuration panes. But the VPN config has been
> created just fine.
> 
> Experimenting with it, it looks like this happens when there are no
> *secrets*. It might not even *need* any secrets, but unless I create a
> [vpn-secrets] section with some random `foo=bar` in it, the GUI won't
> load the connection editor.
> 
> I don't *think* this is specific to NetworkManager-openconnect; I don't
> really do anything with the secrets in the config UI. Not even sure I
> *can*. Can you file bugs against gnome-control-center (for the CRITICAL
> warning when you hit Apply, and the utter lack of error reporting), and
> I think probably NetworkManager for the connection failing to reload?

Turns out auth-dialog is spawned for the secrets when launching the
config GUI. Bisecting showed that it was a commit which *only* changed
auth-dialog which was breaking it.

So that part should be fixed with
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/commit/4a339f507


But please still do file the bug(s) against gnome-control-center for
the Apply button not working, and the lack of error handling when that
happens.

Thanks.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: NetworkManager-openconnect(gnome-control-center network) UI apply does not close

[David Woodhouse]

On Sat, 2023-05-06 at 06:41 +0200, Grant Williamson wrote:
> There's a minor issue that I've noticed. When I edit a connection
> using nm-connection-editor, I'm able to save the changes without any
> problems. However, if I try to edit a connection using the
> gnome-control-center network method, the changes can still be applied
> but the dialog box doesn't close automatically. After clicking on
> apply, I have to manually click on cancel to exit the dialog box.

Right. And if you run it from the command line, you'll see it say this:

09:40:58.0880   nm[260279]:CRITICAL: ((src/libnm-
client-impl/nm-device.c:2450)): assertion '' failed

You get the same when creating a new connection. And then if you click
'Apply' again it says this:

09:41:07.1184 cc-network-panel[260279]: WARNING: Failed to add
connection: a connection with this UUID already exists

And this some the dialog *does* close, giving you no indication at all
in the UI that it thinks it failed!

I then can't *open* that connection again successfully. gnome-control-
center just spins as if 'loading' it, for ever. And nm-connection-
editor seems to lack the actual VPN config pane; it just has the
standard IP/DNS configuration panes. But the VPN config has been
created just fine.

Experimenting with it, it looks like this happens when there are no
*secrets*. It might not even *need* any secrets, but unless I create a
[vpn-secrets] section with some random `foo=bar` in it, the GUI won't
load the connection editor.

I don't *think* this is specific to NetworkManager-openconnect; I don't
really do anything with the secrets in the config UI. Not even sure I
*can*. Can you file bugs against gnome-control-center (for the CRITICAL
warning when you hit Apply, and the utter lack of error reporting), and
I think probably NetworkManager for the connection failing to reload?


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Commit ba7cf175 Don't force PreventInvalidCert setting

[David Woodhouse]

On Fri, 2023-05-05 at 18:35 +0100, David Woodhouse wrote:
> 
> 
> On 5 May 2023 17:55:57 BST, Daniel Lenski  wrote:
> > On Fri, May 5, 2023 at 5:25 AM Grant Williamson
> >  wrote:
> > > It appears I have an issue when attempting to edit an existing
> > > connection using the "copr build ba7cf175", as an WARNING message
> > > is
> > > displayed in the terminal indicating that "ca.pem uses an unknown
> > > scheme". Will not add/import or save the ca,pem to the vpn
> > > configuration.
> 
> The "unknown scheme" thing is what happens when you try to set a bare
> pathname and it's expecting a URI starting with file://
> 
> I fixed this for the client certs when merging
> https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/commit/92e93976264e69cee708a13d3f4f7006d7a2593b
> but perhaps we need to fix the CA too?

Please try
https://copr.fedorainfracloud.org/coprs/dwmw2/openconnect/build/5891032/

The fix should be
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/commit/85f05b3f96296


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Commit ba7cf175 Don't force PreventInvalidCert setting

[David Woodhouse]

On 5 May 2023 17:55:57 BST, Daniel Lenski  wrote:
>On Fri, May 5, 2023 at 5:25 AM Grant Williamson  wrote:
>> It appears I have an issue when attempting to edit an existing
>> connection using the "copr build ba7cf175", as an WARNING message is
>> displayed in the terminal indicating that "ca.pem uses an unknown
>> scheme". Will not add/import or save the ca,pem to the vpn
>> configuration.

The "unknown scheme" thing is what happens when you try to set a bare pathname 
and it's expecting a URI starting with file://

I fixed this for the client certs when merging
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/commit/92e93976264e69cee708a13d3f4f7006d7a2593b
but perhaps we need to fix the CA too?

>Are you referring specifically to this change in the
>NetworkManager-openconnect plugin?
>(https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/commit/ba7cf175)
>
>> However, when using the "nmcli" command to add the "ca.pem" file to the 
>> connection, there are no issues, and a similar "ca.pem" file is successfully 
>> used for wireless connections without encountering the warning message.
>
>I suspect that this is related to
>https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/66
>…
>
>When attempting to choose a cert in the GUI, but not when using
>'nmcli', it forcibly prepends the user's $HOME to the front of the
>cert path.

I think this should be working nm-connection-editor now; I tested it yesterday. 
In gnome-control-center it lets you select a PKCS#11 token but won't show you 
any objects therein.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect 9.10 release

[David Woodhouse]

On Thu, 2023-05-04 at 15:13 -0400, Mike Gilbert wrote:
> On Thu, May 4, 2023 at 2:45 PM David Woodhouse  wrote:
> > 
> > https://www.infradead.org/openconnect/download/openconnect-9.10.tar.gz
> > https://www.infradead.org/openconnect/download/openconnect-9.10.tar.gz.asc
> 
> Hi David,
> 
> I'm getting an HTTP 403 Forbidden response when I attempt to download
> those files.

Thanks. Should be fixed now.




smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

OpenConnect 9.10 release

[David Woodhouse]

balProtect JavaScript challenge 'respMsg' as JSON string
  Merge branch 'parse_GP_javascript_better' into 'master'
  Persistent configuration for fake Fortinet server
  Persistent configuration for fake Juniper server
  Give more details about unexpected Pulse configuration packets
  Expand examples of '--useragent' in manual page
  Merge branch 'FAIL_obsolete-server-crypto' into 'master'
  Add 'except' clause for Gitlab-CI Android builds
  Parse JSON login forms for F5
  Update changelog
  Merge branch 'parse_JSON_login_forms_F5' into 'master'
  Make xmlnode_bool_or_int_value() a global, internal function
  Persist Windows installer artifacts (openconnect-installer.exe) for 
tagged commits/releases
  Unique names for each variant openconnect-installer.exe
  Update changelog and README
  Merge branch 'persist-windows-builds' into 'master'
  Junos/Pulse → Junos/Ivanti Pulse
  Ignore blank labels sent in GlobalProtect prelogin
  GnuTLS: Print more relevant information in the case of a fatal TLS alert
  Fortinet: send dual_stack parameter to support IPv6 and Legacy IP 
simultaneously
  Add a more modern LIMITATIONS section to man page
  GnuTLS: Add UNSAFE_RENEGOTIATION to allow-insecure-crypto
  Remove TAP-Windows driver from installer, and update docs to reference 
Wintun's default inclusion
  Bundled Cisco CSD wrapper script only works on GNU/Linux on Intel 
x86/x86_64 processors
  Merge branch 'tap_wintun' into 'master'
  Update .mailmap
  Add FTM-push token mode for Fortinet
  Newer Pulse servers can disable their ESP protocol layering malpractice
  Pulse needs an 'official' version string in IF/T-T establishment to 
support IPv6
  Document the potential need for an EAP-TLS-within-EAP-TTLS workaround for 
Pulse
  Merge branch 'Pulse_unstupid_ESP' into 'master'
  Small additions to changelog before release
  Update docs related to vpnc-script, platform, Trojans
  Tell Apple users not to use '-i tunX', but '-i utunX' instead.
  Bugfix Y2038 for F5 authentication timestamp
  Fix mixed line endings
  Add --no-external-auth option, and follow it for Cisco protocol
  More specific error message with proposed workaround for Pulse EAP-TLS 
requests
  Update changelog
  Merge branch 'hipreport' into 'master'

David Woodhouse (40):
  Merge branch 'obs' into 'master'
  Merge branch 'CentOS6' into 'master'
  Merge branch 'rhel5' into 'master'
  Merge branch 'autoconf' into 'master'
  Revert "Use more idiomatic super().__init__() in html.py"
  BuildRequire glibc-langpack-cs on EPEL9 for auth-nonascii test
  Import translations from GNOME
  Remove stray debug message on Pulse ESP rekey
  Fix ESP recv() error handling for Windows
  Use OpenSSL_version() not deprecated SSLeay_version()
  Add list-system-keys tool
  Fix COPR builds
  Clean up NSIS installation a bit
  Don't install list-system-keys
  Attempt to handle multiple IP packets in an Array TLS frame
  Update changelog, improve Windows certificate store documentation
  Default 'Getting Started' top-level menu to connecting.html
  Looks like Array *does* split packets across TLS records
  Detect Array session timeout and exit cleanly
  Import translations from GNOME
  Fix Solaris build
  Update translations from GNOME
  Bump default queue length to 32
  Update translations from GNOME
  Fix missing TX stats on vhost
  Update docs on running as non-root
  Redirect stdout to stderr when spawning external browser
  Fix F5 build with json-parser 1.1.0
  Revert "html.py is a Python 3 script"
  Fix installer suffix handling
  Resync translations with sources
  Set SOCK_CLOEXEC on listening socket for Cisco external browser support
  Fix --server vs. positional argument handling
  Report unexpected Pulse EAP requests more explicitly
  Fix EINTR handling for select() on cmd_fd
  Attempt to handle Legacy IP frames in the middle of oNCP config
  Rework ESP probe retries
  Resync translations with sources
  Fix use-after-free in realloc_inplace()
  Tag version 9.10

Dimitri Papadopoulos (40):
  Stop CentOS6 CI job
  AC_PREREQ expects a single version argument
  No need to support RHEL 5
  Fix signedness of character buffers in HKDF/HPKE-related functions
  Fix constness of character buffers in HKDF/HPKE-related functions
  Fix constness again in HKDF/HPKE-related functions
  Merge branch 'const' into 'master'
  Man page: fix list of supported protocols
  Man page: remove spurious space before )
  Man page: use bold for option names
  Clarify certificate verification in Cisco CSD/trojan scripts
  Fix broken links in documentation
  Python: indentation contains mixed spaces and tabs
  Python

Re: per-user device name and local server's ip pin

[David Woodhouse]

On Wed, 2023-04-26 at 06:26 +0300, Andrei Sergeev wrote:
> Hello.
> 
> Could you please help me, I'm struggling with two problems:
> 1. Is there any possibility to pin local device name on per-user basis?
> For now it says "skipping unknown option 'device' " if i place it in 
> user config file.

The options have the same name as the command line options, and that
one is --interface. So "interface" in the config file.

> 2. And the second question: is there any ability to set fixed server's 
> local side IP address for the tunnel interface?
> Even if I, for example, will set up an ipv4-network = 192.168.0.1, 
> ipv4-netmask = 255.255.255.255 and explicit-ipv4 = 192.168.0.50 for user 
> - the ocserv instance gets an address 192.168.0.3 for his side, which
> couldn't be predicted...

That's not something the client can control, is it? The server actually
has to *respond* to that address, surely? If you care at all; why does
anyone care about the IP address that the server has on its end of the
tunnel link anyway? If you want to communicate with the server itself,
doesn't it have a canonical IP address on one of its physical networks?
and if you want route through the server to anything beyond, nobody
cares what the IP address of the server is...

Knowing what you're trying to achieve with this would help to answer
it.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Building for OpenWrt

[David Woodhouse]

On Wed, 2023-04-12 at 09:57 +0100, David Woodhouse wrote:
> On Wed, 2023-04-12 at 16:33 +0800, lobbia wrote:
> > Hi experts, 
> > 
> > 
> > Can you advice me what's wrong or how shall I build myself for a
> > special branch code for OpenWrt? I'm trying to build package for
> > Openwrt from a old branch other than master from Gitlab but failed.
> > I
> > can build released version for openwrt correctly e.g. v8.20 and
> > v9.01. I can also build the old branch for Ubuntu correctly. Anyone
> > know what's the issue or how to fix? Thanks!
> > 
> > 
> > Code branch to be built: add_local_id_option 
> > https://gitlab.com/openconnect/openconnect/-/tree/add_local_id_option?ref_type=heads
> 
> If you are building from a git repository snapshot instead of from a
> release, then you are missing some autogenerated build files.
> 
> Run the ./autogen.sh script. And *then* you should be able to run
> ./configure as normal.

e.g.:

define Build/Configure
(cd $(PKG_BUILD_DIR); ./autogen.sh );
$(call Build/Configure/Default)
endef





smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Building for OpenWrt

[David Woodhouse]

On Wed, 2023-04-12 at 16:33 +0800, lobbia wrote:
> Hi experts, 
> 
> 
> Can you advice me what's wrong or how shall I build myself for a
> special branch code for OpenWrt? I'm trying to build package for
> Openwrt from a old branch other than master from Gitlab but failed. I
> can build released version for openwrt correctly e.g. v8.20 and
> v9.01. I can also build the old branch for Ubuntu correctly. Anyone
> know what's the issue or how to fix? Thanks!
> 
> 
> Code branch to be built: add_local_id_option 
> https://gitlab.com/openconnect/openconnect/-/tree/add_local_id_option?ref_type=heads

If you are building from a git repository snapshot instead of from a
release, then you are missing some autogenerated build files.

Run the ./autogen.sh script. And *then* you should be able to run
./configure as normal.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/66

[David Woodhouse]

On Mon, 2023-03-13 at 16:23 +0100, Grant Williamson wrote:
> > > > > > > > > > > > > > > > Is there a fix or workaround for the
> > > > > > > > > > > > > > > > issue described in
> > > > > > > > > > > > > > > > https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/66
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > On RHEL8, the application still adds a
> > > > > > > > > > > > > > > > prefix of > > > > > > > > '/home' to
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > usercert, and on Fedora 37, editing and
> > > > > > > > > > > > > > > > applying in the > > > > > > > > config
> > > > > > > > > > > > > > > > > > > > removes
> > > > > > > > > > > > > > > > the usercert entirely.

I just merged 
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/merge_requests/43

I think it should fix it; does it?


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: [EXTERNAL] Re: Cisco recommends OpenConnect

[David Woodhouse]

On Thu, 2022-06-09 at 14:15 -0700, Daniel Lenski wrote:
> On Mon, Jun 6, 2022 at 12:54 PM Randall Sindlinger 
>  wrote:
> > In any case, has this and the DevNet recommendation been added to the
> > https://www.infradead.org/openconnect/
> >  page?  I'm not sure where it would best fit; but I think it
> > would be invaluable to give users and potential users the knowledge that 
> > Cisco has all but formally
> > approved it.  It sure would have helped me, at least!
> 
> Hmmm. Remind me again why "the endorsement of Cisco" is an endorsement
> that OpenConnect would want…? 

We don't, necessarily — the reason I wrote OpenConnect in the first
place is because Cisco's own solution for Linux fell *so* far short of
even being barely acceptable. I don't care about their 'approval'
because I have such a low opinion of them it means nothing to me.

But IT departments using proprietary VPN products clearly *do* trust
the likes of Cisco far more than we do, and the endorsement *is*
meaningful to them. So it doesn't hurt to highlight it.

Especially for individual users who are seeking "permission" to use
OpenConnect against their corporate network, the endorsement could be
very useful.


> More seriously, I'm rather equivocal about encouraging corporate
> network IT departments to replace proprietary clients with
> OpenConnect.
> 
> Those corporate network IT folks are always asking us things like,
> "Hey, OpenConnect is great! We want to use it for our whole fleet. By
> the way, can you make it so OpenConnect will check a flag sent by the
> server and then disable access to other network devices?"…
> 
> … and that's the part where I have to tell them, "Look, I'm not your
> ally here, I'm your adversary. The reason I got involved in developing
> OpenConnect was to work around all of these network security policies,
> so that I could actually Get Stuff Done on the VPNs I was connecting
> to. My primary interest in such policies is documenting and explaining
> how to evade them."

I strongly disagree with this.

OpenConnect gives you *control*, sure. It *allows* you, as a user, to
override and bypass certain policies. Strictly speaking, so do the
proprietary clients if you try hard enough; we'd just a little more
honest about it. 

But overriding security policies is *not* its raison d'être, as you
seem to be implying above. If we don't yet support those "bar all local
network access and route to the VPN so users can't even print" or "Bar
all Legacy IP/IPv6 becaue the VPN only supports the other" features,
that is a bug/missing feature and we *do* aspire to do those things by
*default*, even if we know some users might disable them.

I *absolutely* want to be the ally of corporate IT departments who want
to use OpenConnect and want to know that it *can* meet their
requirements. And does so out of the box without having to be tweaked.

We are *also* the ally of individual users who want to have control of
what's on their box, and who want to use properly integrated open
source software. And where their desires mismatch with those of their
employers, that's none of our business.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: AW: OpenConnect does not take over MTU

[David Woodhouse]

On Wed, 2022-06-08 at 19:35 +, Schütz Dominik wrote:
> Hi,
> 
> sorry that the reply to the mail with the subject "Pulse with ESP has
> problems with Kerberos Tickets" and "OpenConnect does not take over
> MTU" took so long.
> 
> We have found out the following about MTU with OpenConnect and
> "protocol=pulse" (ESP):
> 
> With OpenConnect, the MTU of the virtual adapter (tun0) is always
> 1400, regardless of whether the MTU of the physical adapter is larger
> or smaller.
> 
> root@host1:~# ifconfig -a
> tun0: flags=4305  mtu 1400
> wlp110s0: flags=4163  mtu 1300
> 
> root@host1:~# ifconfig -a
> tun0: flags=4305  mtu 1400
> wlp110s0: flags=4163  mtu 1400
> 
> root@host1:~# ifconfig -a
> tun0: flags=4305  mtu 1400
> wlp110s0: flags=4163  mtu 1500
> 
> 
> The PulseUI (9.1.R14) dynamically adjusts the MTU of the tun0.


This is amazingly useful; thank you.

One thing is missing; we don't know how (or 'if') the client *tells*
the far end what the MTU should be.

If you could get a MITM capture and look for unknown attributes in what
their client sends to the server (or indeed in what the server sends
back), especially looking for those MTU values, it would be very much
appreciated.

Setting the MTU on *our* side is only half the equation.

We certainly *can* do that, of course, and we have the logic to fetch
the TCP MSS and subtract from it already for other protocols; we can
extend that to Pulse.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Aruba VIA VPN support

[David Woodhouse]

On Mon, 2022-06-06 at 11:00 -0500, Daniel Pou wrote:
> After a cursory inspection, I have not found any request to add
> support for Aruba VIA VPN protocol in issues or the mailing list. I am
> curious if anyone has considered or made any effort so far? I am
> trying to look through the links referenced on observing from the main
> site in the mean time.

I don't recall anyone talking about it. New protocols are generally
fairly easy to add — at least the connectivity part. Auth is often a
twisty maze of baroque hatred but with the SAML/SSO support merged I'm
hoping we can delegate more of that to web browsers in the future. 


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect does not take over MTU

[David Woodhouse]

On Mon, 2022-05-23 at 19:02 +, Schütz Dominik wrote:
> Hello,
> 
> By default, I have an MTU of 1400 with OpenConnect and
> "protocol=pulse" for tun0 (also with "protocol=nc").
> However, if I specify an MTU of 1360, nothing changes with tun0. What
> could be the reason for this?
> The PulseUI gets the MTU dynamically from the Pulse server.
> OpenConnect does not do this?

OpenConnect *should* get the MTU from the Pulse server. If you run with
'-vv' do you see the debug message from around line 370 of pulse.c:

vpn_progress(vpninfo, PRG_DEBUG,
 _("Received MTU %d from server\n"),
 new_ip_info->mtu);

I would *guess* so because AFAICT it'll *abort* if it doesn't receive
both an MTU *and* at least one of Legacy IP and/or IPv6 addresses.

Is the server giving you an MTU of 1400 in your examples, then? It's
interesting that it's giving the PulseUI client a different MTU.

Did you manage to set up MITM to watch the traffic? I wonder if there's
something we need to *send* in order to make the server calculate the
MTU differently? In the Cisco protocol we send our idea of the MSS over
the public network, as the 'base MTU'.

It looks like our `--mtu` argument doesn't actually do anything for
protocols other than AnyConnect; that's a bit of an oversight. I think
it should be imposed as a *minimum*; if the server offers anything
larger, we should clamp down to what is passed with the --mtu argument.
Although that's only really enforceable on the *uplink*; the server may
well send us packets however large it likes. 


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Pulse with ESP has problems with Kerberos Tickets

[David Woodhouse]

On Fri, 2022-05-20 at 12:38 +, Schütz Dominik wrote:
> Hi,
> 
> On some Ubuntu 20.04 clients with OpenConnect v9.01 and "--protocol=pulse" we 
> have the problem that with ESP the Kerberos tickets are not correct. If you 
> use the official Pulse UI for Ubuntu and ESP, the problems do not occur.
> 
> 
> We get the following messages on port 88:
> # tcpdump -i any -nn -q -e host xx.x.x.x
> ...
> 11:05:39.369009 Out xx.x.xxx.xxx.51144 > xx.x.x.xx.88: UDP, bad length 2007 > 
> 1368

Hm, which end is that capture from? Can you capture at *both* ends? And
is that port 51144 on the client side, sending to the KDC on the VPN?

I suspect a fragmentation issue. Can you reproduce with large ping
packets, e.g. 'ping -s 2000'? Perhaps you can reproduce to a host on
the VPN where you *can* do a packet capture, if capturing on/near the
KDC is hard.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Questions about OpenConnect with Pulse and a bug

[David Woodhouse]

On Thu, 2022-05-05 at 18:07 +, Schütz Dominik wrote:
> 
> 
> We would like to use OpenConnect (currently 9.01-0+9.1) productively
> as a VPN client (under Ubuntu 20.04 and 22.04) with Pulse as the
> backend (currently 9.1R14), but we still have the following open
> questions:
> 
> 1. Is "--protocol=nc" used for Pulse SSL VPN and "--protocol=pulse"
> used for Pulse ESP (IPsec) VPN?
> 

The former is the older Juniper 'Network Connect' protocol. It's
limited to Legacy IP and HMAC-SHA1 (as far as we can tell).

The latter is their next generation protocol which supports IPv6,
SHA256, etc. It's a horrid mess of nested binary protocols (IF-T/TLS,
EAP, EAP-TTLS, some of their own devising). I believe it was eventually
spun off from Juniper as a separate company, and is now called 'Pulse
Secure SSL VPN'... no wait, they've been acquired and the branding of
the VPN has changed again, but I think it's the same thing.

The Pulse appliances seamlessly still support the old protocol, and
it's hard to even find a setting to disable that. Last time I knew, the
"pulse" client for Linux was actually still using the older NC
protocol; we had to watch traffic from a Windows client to work out the
pulse protocol.

> 2. Does the "--protocol=pulse" fallback to SSL if the VPN connection
> with ESP doesn't work?

Yes. It will attempt to establish the ESP 'connection' by exchanging
probe packets, and send packets over ESP where it *can*, but fall back
to sending over SSL.

There's a catch here: the Pulse applicance can generally accept packets
in an ESP tunnel which match the protocol that the ESP is sent *ovER*.

So... if your connection from client to the VPN appliance over the
public Internet is IPv6, then you can tunnel IPv6 within ESP and all
Legacy IP has to go over TCP. Conversely if your connection over the
public Internet to the VPN appliance is Legacy IP, then you can only
tunnel Legacy IP over ESP and all IPv6 has to go over TCP.


> 3. Why can't OpenConnect always establish a VPN connection with "
> --protocol=pulse"?
> "Configured as xxx.xxx.xxx.xxx, with SSL connected and ESP in
> progress" is then displayed here, but sometimes "ESP session
> established with server" does not appear and consequently "ping
> domain" does not work, although the client has a company-internal IP
> address.
> Here you have to disconnect the VPN connection and re-establish it
> again until "ESP session established with server" is there, then the
> VPN works with "--protocol=pulse" without any problems.
> With "--protocl=nc" I don't have these problems, this is more
> reliable than "--protocol=pulse". Can it be a bug?

Sounds like more than one bug. Firstly... why doesn't the ESP session
manage to establish sometimes? Would be useful if you could capture the
traffic on the public wire (at both ends, even better) to compare good
and bad cases. With enough `-v` on the command line, openconnect will
dump the ESP keys that you need to put into a tool like Wireshark to
decrypt that traffic. 

Are the probes making it through? Are you afflicted by NAT? Is there
something different between the successful and failing cases? 

Secondly... if ESP isn't established, we ought to be passing data over
the TCP/TLS session. Don't go straight to testing DNS; make sure you're
attempting to ping a remote box on the VPN (that allows ICMP echo) by
*number*. And bear in mind that IPv6 and Legacy IP *might* behave
differently. Does it make any difference if you use --no-dtls? (Which
is misnamed now, and means --no-udp but we didn't actually make that
user interface change yet).

> Thanks.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect 9.01 does not work under Ubuntu 20.04

[David Woodhouse]

> > > It would have to be ran manually every time. 
> > 
> > I thought it could be automated as part of debian/rules? 
> 
> It makes sense to maintain a symbols file only if each version is
> annotated with the exact package version that first introduced it, so
> that dpkg can generate the minimal dependency required based on the
> subset of symbols used by the building package, picking the version
> of the most recent one. Otherwise it has no benefits, and only
> maintenance costs.

Yeah, understood. That script *does* build a symbols file with the
correct "first version" for each symbol, because that information is
there in text form in the changelog at the top of openconnect.h

It basically builds a file which is the same as the one you're doing by
hand, although you ought to be marking the @OPENCONNECT_PRIVATE symbols
as *new* in each release because they have no ABI guarantee; they
shouldn't be considered the same as the same named symbol in 6.0 as
your symbols file suggests.

> > For the Fedora packages we just ship the library and binary together in
> > the *same* package, and that means they are very much in lock-step
> > anyway. The binary uses private exports from the library that are very
> > much *not* API-managed. The normal library API hygiene doesn't help at
> > all there.
> 
> A symbols file wouldn't help with that, as it would make things more
> lax, not more strict.

Especially if you mark those symbols as being compatible with v6.0 :)

>  Forcing installations through dpkg is always
> possible - it is a user error in most cases. The OBS page clearly
> lists the repository and the instructions to use it first via apt,
> bypassing that should not be done unless one knows exactly what they
> are doing.

Agreed.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: AW: AW: OpenConnect v9.01 - "--protocol=pulse" does not work with TPM2

[David Woodhouse]

On Wed, 2022-05-04 at 18:26 +, Schütz Dominik wrote:
> Thank you for the guidance :)
> 
> I'll try to solve it myself first. I'll get back to you then.
> 

You can use a MITM proxy like http://david.woodhou.se/proxy.go to watch
all the TLS traffic; I found it really useful for Pulse.

Note the 'myrawcopy' function has the ability to do a search/replace on
the transferred data. Sometimes we've needed that because the server
sends its own certificate fingerprint and the client may abort the
connection if it doesn't match the *proxy's* cert.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect 9.01 does not work under Ubuntu 20.04

[David Woodhouse]

On Wed, 2022-05-04 at 19:19 +0100, Luca Boccassi wrote:
> On Wed, 2022-05-04 at 19:12 +0100, David Woodhouse wrote:
> > On Wed, 2022-05-04 at 18:59 +0100, Luca Boccassi wrote:
> > > The same can be done by maintaining a symbols file. I do that for the
> > > actual Debian/Ubuntu builds (
> > > https://salsa.debian.org/debian/openconnect/-/blob/master/debian/libopenconnect5.symbols
> > > 
> > > ), but it's a _lot_ of work and it would constantly break the builds
> > > as new things are added/removed, so I did not add it to the upstream
> > > builds.
> > 
> > It shouldn't break the build as things are added; surely that's the
> > point? 
> 
> I'm quite sure it's flagged as an error by Lintian if there's a symbol
> missing in the list.
> 
> > It *should* break the build if things are removed without bumping the
> > soname. Which is also the point :)
> > 
> > But I don't really understand why Debian lists each individual symbol.
> > The library *minor* version really ought to be enough for any even
> > semi-sanely-maintained library. And if the library is *so* badly
> > maintained that it isn't enough, all bets are off anyway; the developer
> > might even break binary ABI between versions *without* changing symbol
> > names or version, surely?
> 
> I'm not sure why the tooling works the way it does, maybe historical
> reasons, it's ancient stuff.
> 
> > Anyway, for OpenConnect this script ought to be able to build the
> > symbols file from openconnect.h, which does have a history of when each
> > symbol was added:
> > http://git.infradead.org/users/dwmw2/openconnect-deb.git/blob/HEAD:/gensyms.sh
> > 
> 
> It would have to be ran manually every time. 

I thought it could be automated as part of debian/rules? 


> I'm not sure it's worth
> the hassle, for this setup? Is there any issue with lock-step updates?

The only issue with the lock-step updates is that Dominik managed *not*
to update them in lock-step, it seems :)

For the Fedora packages we just ship the library and binary together in
the *same* package, and that means they are very much in lock-step
anyway. The binary uses private exports from the library that are very
much *not* API-managed. The normal library API hygiene doesn't help at
all there.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect 9.01 does not work under Ubuntu 20.04

[David Woodhouse]

On Wed, 2022-05-04 at 18:59 +0100, Luca Boccassi wrote:
> 
> The same can be done by maintaining a symbols file. I do that for the
> actual Debian/Ubuntu builds (
> https://salsa.debian.org/debian/openconnect/-/blob/master/debian/libopenconnect5.symbols
> ), but it's a _lot_ of work and it would constantly break the builds
> as new things are added/removed, so I did not add it to the upstream
> builds.

It shouldn't break the build as things are added; surely that's the
point? 

It *should* break the build if things are removed without bumping the
soname. Which is also the point :)

But I don't really understand why Debian lists each individual symbol.
The library *minor* version really ought to be enough for any even
semi-sanely-maintained library. And if the library is *so* badly
maintained that it isn't enough, all bets are off anyway; the developer
might even break binary ABI between versions *without* changing symbol
names or version, surely?

Anyway, for OpenConnect this script ought to be able to build the
symbols file from openconnect.h, which does have a history of when each
symbol was added:
http://git.infradead.org/users/dwmw2/openconnect-deb.git/blob/HEAD:/gensyms.sh


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: AW: OpenConnect v9.01 - "--protocol=pulse" does not work with TPM2

[David Woodhouse]

On Wed, 2022-05-04 at 16:54 +, Schütz Dominik wrote:
> unfortunately I can't send the output of "-vv --dump-http-traffic"
> because it contains company-specific information.

Fair enough, although that obviously makes it difficult to try to help.

Without even seeing the final offending EAP-TTLS (or not?) packet that
it didn't like, it's hard to even guess about what's happening.

Note that a public-facing VPN server will be receiving hundreds or more
likely thousands of *random* connection attempts per day. To reproduce
this and have a chance of helping you, I wouldn't need to get any
further than any of those random port scans do — I don't need a
username, a password, or a certificate or anything like that; just the
IP address that is receiving thousands of stray connections a day.

But OK, if you're not comfortable with that, then take a look at that
final packet and see what it is. Is it a *different* EAP type? Have
they changed to EAP-TLS or something else? Does it change if you vary
the user-agent you advertise (see the comments in the source about the
way that changes things).

Those are rhetorical questions, of course, intended to help guide you
if you want to try to solve this on your own. I don't *actually* have
any real insight into this other than having watched the Windows client
attempt to connect through a MITM proxy, and trying to work out what
the many levels of nested binary protocols actually were.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect 9.01 does not work under Ubuntu 20.04

[David Woodhouse]

On Wed, 2022-05-04 at 16:51 +, Schütz Dominik wrote:
> 
> when i install "openconnect_9.01-0+9.1_amd64.deb" from 
> "https://software.opensuse.org/download.html?project=home%3Abluca%3Aopenconnect%3Arelease&;package=openconnect;
> it doesn't work, see text below:

Make sure you also install the matching libopenconnect5 package from
https://download.opensuse.org/repositories/home:/bluca:/openconnect:/release/Ubuntu_20.04/amd64/libopenconnect5_9.01-0+9.1_amd64.deb

I just did that here, and those builds *don't* have PKSC support.

 $ openconnect --version
OpenConnect version v9.01-0+9.1
Using GnuTLS 3.6.13. Features present: TPMv2, PKCS#11, RSA software token, HOTP 
software token, TOTP software token, Yubikey OATH, System keys, DTLS, ESP
Supported protocols: anyconnect (default), nc, gp, pulse, f5, fortinet, array
Default vpnc-script (override with --script): 
/usr/share/vpnc-scripts/vpnc-script
 $ ldd /usr/sbin/openconnect | grep pskc
 $

It's not clear why you managed to install the openconnect binary
package without the corresponding library. In RPM packaging you get a
dependency on 'libopenconnect.so.5(OPENCONNECT_5_8)(64bit)' which is
handled automatically. You wouldn't be able to install a package which
*uses* new symbols from libopenconnect.so.5.8 without also installing
that package.

In Debian it's apparently different; I'm not sure if this is just
something that Debian packaging doesn't handle at all, or if it's an
issue with the way we build in OBS? Luca?




smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: AW: AW: How can I specify a realm with "--protocol=pulse"?

[David Woodhouse]

On Wed, 2022-05-04 at 11:11 +, Schütz Dominik wrote:
> With the hack and "pulse_realm_choice:realm_choice" it works fine:
> 
> But now I get a other output, when I authenticate with username +
> password:
> # The two "lookup" messages are new
> 

> Enter user credentials:
> lookup 'pulse_user:username'
> Username:dominik at domain
> lookup 'pulse_user:password'
> Password:


Yes, that's exactly the point of the hack. All it does is print the
'key' of every field it asks the user for, so that you know how to
identify it in the '-F' argument on the command line.

Now that you know what key to use for the realm choice, you can drop
the hack.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect v9.01 - "--protocol=pulse" does not work with TPM2

[David Woodhouse]

On Wed, 2022-05-04 at 10:23 +, Schütz Dominik wrote:
> dominik at host1:~$ sudo openconnect --script=/root/vpnc-script 
> --certificate=/var/lib/802.1x/host1.pem --sslkey=/usr/local/wlan/host1.key 
> --protocol=pulse "https://vpn-gateway/linux;
> Connected to xxx.xxx.xxx.xxx:443
> Using client certificate 'HOST1'
> SSL negotiation with vpn-gateway
> Connected to HTTPS on vpn-gateway with ciphersuite 
> (TLS1.2)-(RSA)-(AES-128-GCM)
> Got HTTP response: HTTP/1.1 101 Switching Protocols
> Bad EAP-TTLS packet (len 93, left 0)
> Failed to establish EAP-TTLS session
> Failed to complete authentication
> dominik at host1:~$

I suspect that isn't really related to TPMv2 but actually affects all
certificate authentication? Are you able to test with a certificate
from a plain file? Probably doesn't even matter if it's a *valid* one
since I don't think you're getting that far.

The Pulse protocol is kind of weird here. It tunnels a TLS negotiation
(EAP-TTLS) within multiple layers of binary protocols inside the
original TLS connection to the server. Depending on the client version
that we pretend to be, it might even attempt to tunnel EAP-TLS *within*
EAP-TTLS, which is entirely bizarre.

Can you run with '-vv --dump-http-traffic' and show me the full session
until it gets to that point please? Probably best to do that off-list.




smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: AW: How can I specify a realm with "--protocol=pulse"?

[David Woodhouse]

On Wed, 2022-05-04 at 11:44 +0100, David Woodhouse wrote:
> On Wed, 2022-05-04 at 10:42 +, Schütz Dominik wrote:
> > It does not work with '-F pulse_realm_entry:realm=REALM_xxx_Foo' -
> > see text below:
> > 
> 
> Hm, please can you try with the hack I put into
> https://gitlab.com/openconnect/openconnect/-/issues/421#note_934005457
> which will make it print the actual key it uses for that lookup?
> 

... which may well be 'pulse_realm_choice:realm_choice'.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: AW: How can I specify a realm with "--protocol=pulse"?

[David Woodhouse]

On Wed, 2022-05-04 at 10:42 +, Schütz Dominik wrote:
> It does not work with '-F pulse_realm_entry:realm=REALM_xxx_Foo' -
> see text below:
> 

Hm, please can you try with the hack I put into
https://gitlab.com/openconnect/openconnect/-/issues/421#note_934005457
which will make it print the actual key it uses for that lookup?



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: AW: OpenConnect v9.01 - output appears after "ESP session established with server"

[David Woodhouse]

On Wed, 2022-05-04 at 10:30 +, Schütz Dominik wrote:
> Yes, it keeps working. The output after "ESP session established with
> server" has no effect on the functionality. It just doesn't look
> nice.


Thanks. 

Fixed in https://gitlab.com/openconnect/openconnect/-/commit/e733fb2d99


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect v9.01 - output appears after "ESP session established with server"

[David Woodhouse]

On Wed, 2022-05-04 at 09:45 +, Schütz Dominik wrote:
> 
> I have installed the new OpenConnect version 9.01 on Ubuntu 22.04
> (packages from 
> https://launchpad.net/ubuntu/+source/openconnect/9.01-1/+build/23596572),
>  after a while I get an output after "ESP session established with
> server", what could be the reason?

Hm, I think that's just a stray debugging message from ESP rekeying.
Does it continue to work?


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: How can I specify a realm with "--protocol=pulse"?

[David Woodhouse]

On Wed, 2022-05-04 at 09:36 +, Schütz Dominik wrote:
> Hi,
> 
> how can I specify a realm with "--protocol=pulse"?
> # output without specify realm
> Choose Pulse user realm:
> Realm: 
> [REALM_xxx_Productive|REALM_xxx_Limited_Initial_Network|REALM_xxx_Limited_Machine_Network]:REALM_xxx_Limited_Machine_Network
> 
> 
> With "--protocol=nc" I specify the realm as follows:
> # output without specify realm
> frmLogin
> realm 
> [REALM_xxx_Productive|REALM_xxx_Limited_Initial_Network|REALM_xxx_Limited_Machine_Network]:REALM_xxx_Limited_Machine_Network
> 
> # command with realm
> dominik at host1:~$ sudo openconnect --script=/root/vpnc-script --protocol=nc 
> --form-entry=frmLogin:realm=REALM_xxx_Limited_Machine_Network 
> https://vpn-gateway/linux

For pulse I think you want '-F pulse_realm_entry:realm=REALM_xxx_Foo'




smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

OpenConnect 9.01 release

[David Woodhouse]

Oops, the library version should have been bumped to
libopenconnect.so.5.8 in the 9.00 release.

I thought the handling of the library versioning was all automated, but
apparently is's only *mostly* so. We'll be adding a test for that one…

https://www.infradead.org/openconnect/download/openconnect-9.01.tar.gz
https://www.infradead.org/openconnect/download/openconnect-9.01.tar.gz.asc

David Woodhouse (3):
  Bump OPENCONNECT_API_VERSION_MINOR
  Changelog for API minor fix
  Tag version 9.01


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

OpenConnect 9.00 release

[David Woodhouse]

This release finally contains the SAML/SSO support for AnyConnect and
GlobalProtect, and the multiple certificate support for AnyConnect.
These have been ourstanding for a long time, and I'd really like to thank 
Steven Walter and Tom Carroll for their work and especially their patience.

Thanks also to Luca Boccassi and Dimitri Papadopoulos for their notable
contributions, and to Daniel Lenski as usual.

https://www.infradead.org/openconnect/download/openconnect-9.00.tar.gz
https://www.infradead.org/openconnect/download/openconnect-9.00.tar.gz.asc

Ambroise Rosset (1):
  Implement a function openconnect_set_useragent

Daniel Lenski (25):
  Don't try to set MTU on tunnel interface within (lib)openconnect itself
  Re-enabling tests/auth-multicert
  Cleanup and simplify fake-cisco-server.py
  Cleanup and clarify lengthy comment on multiple certificate authentication
  Add openconnect_set_mca_{cert,key_password} to public API
  Add setMCACert and setMCAKeyPassword to Java API
  Add OC_PROTO_AUTH_MCA flag
  Describe --mca-{certificate,key,key-password} options in manual
  Remove repeated flexible array member which is confusing Coverity
  make .sso_detect_done a protocol-specific VFN, and use in 
openconnect_webview_load_changed
  openconnect_open_webview_vfn should return int, and accept callback data
  split OC_FORM_OPT_SSO into _TOKEN and _USER versions, and don't 
open_webview until after "normal" form processing
  start adding GP SSO support
  Add changelog entry
  Bugfix RSA SecurID token decryption and PIN entry forms
  Add changelog entry
  Fix GP fake server parameters so that gateway-interface 2FA is actually 
tested
  Handle Fortinet split-exclude routes
  Update changelog
  Factor out parse_split_routes for Fortinet
  Fix initial client request XML structure when announcing multicert 
capability
  GP: add 'internal=no' flag to the login and configuration requests
  Update changelog
  Merge branch 'GP_internal_no_flag_for_issue_246' into 'master'
  Do not ignore 0.0.0.0/0 specified as a "split"-{in,ex}clude route for oNCP

David Woodhouse (76):
  OpenSSL implementation of multicert challenge
  Support vhost on more than just x86_64
  Make buf_append_utf16le() robust against being passed NULL
  Fix Windows tun setup crash
  epoll: Handle EPOLLERR as 'readable'
  esp: Close socket on error
  stoken: Fix const warnings
  Merge branch 'master' into 'master'
  Merge branch 'reconnection_report_PRG_ERROR' into 'master'
  Merge branch 'man' into 'master'
  Merge branch 'dump_buf_hex_performance' into 'master'
  Merge branch 'obs' into 'master'
  Merge branch 'sigaction' into 'master'
  Merge branch 'gai_strerror' into 'master'
  Merge branch 'vpn_progress_wintun_version' into 'master'
  Merge branch 'free_const_char' into 'master'
  Merge branch 'cast_char' into 'master'
  Merge branch 'const_char' into 'master'
  Merge branch 'code_climate_deepsource' into 'master'
  Merge branch 'no_MTU_setting_in_openconnect_itself' into 'master'
  Merge branch 'remove_unnecessary_struct_member_to_quiet_Coverity' into 
'master'
  AnyConnect: Generate EC keys for X-AnyConnect-STRAP-{DH-,}Pubkey
  Add cancellable_accept(), make cancellable_send() take a const buffer
  Add OpenSSL crypto support for HKPE
  Add GnuTLS crypto support for HPKE
  AnyConnect: Add support for external browser SSO
  Add openconnect_set_external_browser_callback() and defaults
  Fix translated wintun version strings
  Update translations from GNOME
  Fix translations mangled by sed
  Merge branch 'obs' into 'master'
  Merge branch 'multicert' of gitlab.com:openconnect/openconnect
  fake-cisco-server.py: Disable check for `multiple-cert` support
  Merge branch 'errors' into 'master'
  Add xdg-utils for xdg-open (default external browser)
  Merge branch 'master' of gitlab.com:openconnect/openconnect
  Merge branch 'insecure-openssl' into 'master'
  Merge branch 'errors' into 'master'
  Merge branch 'obs' of gitlab.com:bluca/openconnect
  Increase server delay for fake server tests
  Reduce the 'bus factor' for translation sync a bit
  Import translations from GNOME
  Fix hogweed/gmp library linkage for HPKE by actually using $(HPKE_LIBS)
  Merge branch 'obs' into 'master'
  Attempt to make posix_spawn() work on OSX
  Merge branch 'vhost-portable' of gitlab.com:openconnect/openconnect
  Import translations from GNOME
  Merge branch 'master' of gitlab.com:openconnect/openconnect
  Use 'open' to spawn browser on OSX
  Merge branch 'align' into 'master'
  Merge branch 'field_precision_specifier_expects_int' into 'master'
  Merge branch 'DWORD_PRId32_PRIo32' into 'master'
  Fix lost translations for PRId64 → PRIu64

Re: Openconnect End of Life

[David Woodhouse]

On Mon, 2022-04-18 at 17:01 +, Harrison, Samantha R CIV (USA) wrote:
> Hello,
> 
> Do you have a webpage or chart that describes end-of-life dates for various
> versions of Openconnect? I am working to get Openconnect approved for my
> work environment, and doing so requires some proof of vendor support.

Hi,

OpenConnect development just isn't really that exciting, and it's
generally best to just use the latest version.

We strive for compatibility with various proprietary vendors' VPN
protocols, and most of the bugs we have are around that compatibility —
having to add new functionality as VPN servers get upgraded to new
versions, and users need to use new features especiallty for
authentication (for example, they're all upgrading to SAML these days).

Since those are *features* rather than strictly bug fixes, they
generally wouldn't be candidates for backporting to an older release
branch *anyway*. But they're just as important for users who can't
continue to use OpenConnect without the ugprade.

We also operate in an unprivileged mode when run in the recommended
integrated configuration — unlike many of the VPN vendors' own
proprietary third-party tools which run various parts as root. Which
means our security exposure for actual *bugs* of that kind is lower.

Overally this means that I think we've basically done a 'bugfix
release' that isn't from the master branch only *once* in OpenConnect's
history; the v5.03 release while we were working on a bunch of new
things in master which eventually became v6.00.

That said, OpenConnect is also packaged as an integrated part of most
major Linux distributions, and *they* have policies about not
"upgrading to a new major version" within the lifetime of a given
version of the distribution, regardless of the above reasons why they
probably ought to do so. So the distribution vendor generally does
backport any necessary fixes (and sometimes, if I can persuade them,
functionality improvements) to the packages that they ship.

So Fedora 34, for example, is still on OpenConnect 8.10 but has a
couple of patches on top:
https://src.fedoraproject.org/rpms/openconnect/tree/f34

Ultimately, the answer to your question is that OpenConnect as part of
a given Linux distribution is supported for as long as that
distribution is.

If your question was about OSX, Windows, Android, *BSD or other
supported platforms... let me know and I'll try to answer more usefully
:)


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

OpenConnect 8.20 release

[David Woodhouse]

Merge branch 'reject_bogus_OS_names' into 'master'
  Merge branch 'wintun-0.10.2-0.13' into 'master'
  .mailmap update
  dumb_socketpair(): try to use AF_UNIX socketpair on Windows 10 and newer
  dumb_socketpair(): generate named socket path more carefully
  dumb_socketpair(): fallback from AF_UNIX to AF_INET if AF_UNIX fails
  dumb_socketpair(): Try a whole series of plausible temporary/writable 
directories for AF_UNIX sockets
  Update changelog
  Merge branch 'Windows_10_has_AF_UNIX_socket' into 'master'
  Merge branch 'windows_ctrl_signal_handler' into 'master'
  Fix dumb_socketpair() comments
  Fix changelog links/labels
  Remove unnecessarily repeated IPv6-enablement in .gitlab-ci.yml
  Change library ordering when testing for library availability with 
autoconf
  Cleanup whitespace in all human-maintained files
  Build docs should mention that ./configure looks for vpnc-script in TWO 
places
  Update "Contributing" docs
  The GitLab repo is more than an "experiment" at this point
  Add new documentation on how to observe/MITM VPN clients
  Remove the 'verbose' global variable
  Pass verbosity level in vpnc-script environment as LOG_LEVEL
  Update changelog
  Mention other Windows vpnc-script improvement MRs in changelog
  Merge branch 'pass_LOG_LEVEL_to_vpnc_script' into 'master'
  Merge branch 'master' into 'master'
  Merge branch 'doc_updates' into 'master'
  Fix memory leak in pulse.c
  Update changelog
  Merge branch 'pulse-config-on-9.1' into 'master'
  Pulse IPv6 is now known to work on real-world servers
  Remove already-disabled code copied from oncp.c into pulse.c
  Mention that some Pulse VPNs need to spoof official UA/OS to make IPv6 
work
  Print Pulse server's IPv6 internal gateway address (in addition to Legacy 
IP)
  Mention support for DTLSv1.2 in F5 BIG-IP v16 or newer
  Print warning if Fortinet server doesn't indicate support/no-support for 
reconnect-after-drop
  Clarify Fortinet no-valid-cookie error paths
  Merge branch 'pulse_IPv6_docs' into 'master'
  In dumb_socketpair(), delete Unix-domain socket path once no longer needed
  Merge branch 'tmp-fedora35' into 'master'

David Overton (2):
  Bugfix Legacy IP split include/exclude routes for Pulse
  Pulse: handle 0x2e20f000 main configuration packet

David Woodhouse (221):
  Fix COPR release builds for mingw-openconnect
  Work around SoftHSM lockup in CI
  Remove Fedora updates-testing packages now pushed to stable
  Update packages documentation
  Run Coverity only in openconnect/openconnect repo
  Check for Signed-off-by: in CI
  Merge branch 'add_set_cookie' of gitlab.com:randymoss/openconnect
  Fix Signed-off-by CI check
  Add basic NSIS installer
  Drop web page handling
  Fix pfs test for out-of-tree builds
  Fix up string handling for ciphersuite_config
  Add obsolete-server-crypto to XFAIL tests in Fedora package
  Add makensis to mingw COPR builds
  Fix obsolete-server-crypto in the GnuTLS build not the OpenSSL one.
  Fix up NSIS ProductVersion for RPM version strings
  Actually create installer packages for MinGW builds
  Merge branch 'handle_GP_cookie_rejected_errors' of 
gitlab.com:openconnect/openconnect
  Fix Win32 build warnings about _putenv_s() redeclaration
  Fix Windows build warning: No %zd for size_t on Windows
  Merge branch 'no_more_X-AnyConnect-Platform_header' of 
gitlab.com:openconnect/openconnect
  Fix non-Windows compilation. I hate autoconf.
  Update translations from GNOME
  Resync translations with sources
  Cast GetVolumeInformationByHandleW to (void *)
  Fix printf types in stats output
  add support for PPP-based protocols
  First attempt at F5 support
  Add basic attempt at Fortinet support
  Turn off -Wdeclaration-after-statement and allow C99
  Fix handling of downloaded files
  Include wintun dll in installer
  Fix installer deps
  Merge branch 'pre_PPP_cross_protocol_bits' of 
gitlab.com:openconnect/openconnect
  Merge branch 'ppp_core' of gitlab.com:openconnect/openconnect
  Fix build warnings
  Merge branch 'add_f5_and_fortinet' of gitlab.com:openconnect/openconnect
  Merge branch 'master' of gitlab.com:openconnect/openconnect
  Add basic docs for (or at least admit the existence of) f5/fortinet
  Resync translations with sources
  Import translations from GNOME
  Add Wintun support
  Fix output redirection under Windows
  Fix stray close paren in changelog
  Fix key filename mangling in auth-certificate test
  Fix test paths for out-of-tree builds
  Use out-of-tree builds in CI
  Fix Juniper auth tests for out-of-tree builds
  Merge branch 'juniper-auth-tests' of gitlab.com:openconnect/openconnect
  Fix link t

Re: Gnome Desktop NetworkManager misses Fortinet SSL VPN

[David Woodhouse]

On Thu, 2021-09-23 at 10:40 +0200, tuxbenutzer wrote:
> Hi,
> 
> being more on the user desktop side, I'd like to use the NetworkManager in 
> the Gnome 
> desktop to turn on a VPN connetion to a site that requires Fortinet. But that 
> option is 
> not present in the protocol options. How to add this manually? Or do I have 
> to wait for a 
> new build?
> 

As long as you have a current build of OpenConnect, the new protocols
should turn up automatically in NetworkManager config.

If you're on Fedora, you can use the automatic package builds from 
https://copr.fedorainfracloud.org/coprs/dwmw2/openconnect/


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Available for support for F5 + MFA

[David Woodhouse]

On 4 August 2021 17:44:07 BST, Antonio Petrelli  
wrote:
>Il giorno mer 4 ago 2021 alle ore 18:08 Daniel Lenski
> ha scritto:
>>
>> Since you've already arrived at the "webtop" interface, you've already
>> completed the login process and you already have the credential (the
>> cookie named 'MRHSession') which OpenConnect requires to be able to
>> actually configure and connect to the VPN tunnel.
>>
>> I believe you should be able to simply capture the value of
>>  (using the browser dev tools), and then run
>> OpenConnect as follows:
>>
>> openconnect --dump - --prot=f5 \
>>   --cookie "MRHSession=" \
>>   
>>
>> (Important: do NOT close the browser window before running this
>> command; that may cause it to logoff the session and invalidate the
>> cookie)
>>
>> I'll wager 70% odds that this Just Works. If that doesn't work, then I
>> guess we'll have to figure out what the "token" and
>> "access-session-token" values mean, and how they get used by the f5vpn
>> binary.
>
>OK thanks, the part that I missed is how to send this cookie.
>About testing I have a few questions because the site is confusing to me:
>1. Are there any nightly pre-built binaries of the source code?
>2. If not, what is the repository, the one at infradead.org or the one
>at GitLab?
>3. What branch should I use, master?
>
>In the meantime I am cloning the GitLab repository at master, since it
>seems the most updated, but correct me if I am wrong!
>
>I will let you know about the tests, thanks again!

There are automatic builds for Fedora (and cross-builds for Windows in MinGW 
RPM packages) at https://copr.fedorainfracloud.org/coprs/dwmw2/openconnect/

Yes, the master branch is correct. Usually git.infradead.org and gitlab are in 
sync but not today.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: IP and User Based Access Rules

[David Woodhouse]

On Fri, 2021-06-18 at 11:15 +0300, Akın Kara wrote:
> Hello, 
> how do I create control rules like user-based and giving access based
> on destination IP? For example, a user only has access to one IP and
> port in my network. I use OpenBSD, As you probably know pf doesn't
> support user-based rules. I would appreciate any help. Thanks
> already.

Is this question about ocserv? Don't you get a tun device per user in
that case, which means that you can install that user's rules for
ingress packets on "their" device?


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: macOS Version

[David Woodhouse]

On Tue, 2021-06-15 at 18:27 +0200, Martin Pauly wrote:
> Hi,
> 
> to my surprise, I have found that
> https://github.com/openconnect/openconnect-gui/releases/download/v1.5.3/openconnect-gui-1.5.3.high_sierra.bottle.tar.gz
> still works on macOS 11.4 Big Sur -- my compliments :-))
> Now I have two questions:
> 1. Has anyone reviewed the source code in the mean time?
> Even with a minimalistic approach to using Apple's network/VPN API,
> some things _might_ have changed.


Is there anything in particular you think we should be looking for?

We've had OSX support since 2008 based on TunTapOSX, and added utun
support in 2014. Not a lot has really changed in all that time.

> 2. If we find this version is OK, could we have a signed version
> to satisfy the gatekeeper?

I'd like to start with automatic builds. We've recently fixed up the
OpenConnect-GUI makefiles and got automatic builds for Windows (both in
CI and cross-built using MinGW in the Fedora COPR). Doing something
similar for MacOS would be really useful, if there's someone who cares
enough to work on it.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Pre-shared key (PPK) for Post-Quantum resistance

[David Woodhouse]

On Mon, 2021-04-26 at 15:44 -0400, David Johnston wrote:
> Good Day OpenConnect/ocserv mailing list,
> 
> I have a client who has a requirement for an SSL VPN with an
> additional pre-shared key for post-quantum resistance. (Like PPKs in
> IPSec, or the additional symmetric key in Wireguard) We would rather
> not use OpenVPN.
> 
> Does anybody have any ideas of how we could accomplish this in
> OpenConnect? Is there some gnuTLS priority string we can use? If I was
> to mod the source code, where would I start?


I'm assuming you want to do this in conjunction with ocserv on the
server side, using the AnyConnect protocol?

Would it suffice to use DHE_PSK for the TLS connection? That
concatenates the PSK with the DH-generated "supposedly PFS" key, to
generate the Master Secret used for encrypting that session.

The DTLS connection is already using PSK; you could either mix in an
additional shared secret on both client and server side, or perhaps you
don't need to if the TLS connection is already secured?



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Where can I find older versions?

[David Woodhouse]

On 23 March 2021 21:30:47 GMT, Calvin Jones  wrote:
>Hello,
>
>I need an older version of openconnect for centos 6.   This is listed
>here.
>
>openconnect-7.07-2.el6.x86_64.rpm CentOS 6 Download
>
>Is it anywhere on the internet?   Thank you!

Why? The latest versions should build and work just fine, and if something's 
regressed then please report that and we'll fix it.

The original 7.07 source is available from the FTP site, tagged in git, and the 
RPM package you mention should also still be available...


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect GUI for Android and Windows

[David Woodhouse]

On 20 February 2021 20:17:18 GMT, "Ľubomír Carik"  
wrote:
>Hi Thomas, I'm keeping eye on windows gui; yes - fresh release in on
>plan.

We are building all the Windows libraries as part of the automatic Fedora COPR. 
It would be good to get OpenConnect-GUI building too as part of that. And/or 
part of the GitLab CI.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Connection to ftp.infradead.org refused

[David Woodhouse]

On Mon, 2021-01-04 at 16:05 +0200, Veselina Radeva wrote:
> Hi,
> 
> I'm trying to download a specific openconnect version using the ftp
> mentioned on https://www.infradead.org/openconnect/download.html, but
> I receive an error message
> 
> `Failed to connect to ftp.infradead.org port 21: Connection refused`
> 
> Is this expected and what can I do to download a version?
> 
> Thanks in advance for your cooperation,
> Veselina Radeva

I had upgraded the machine and not yet checked FTP service. Should be
working again now.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: AnyConnect vs OpenConnect

[David Woodhouse]

On Thu, 2020-10-08 at 13:57 +0300, hanoh haim wrote:
> Your client certificate will be used for authentication
...
> Server requested SSL client certificate; none was configured
...
> Certificate Validation Failure
...
> Failed to obtain WebVPN cookie
> 
> 
> Where can I find the Client Certificate of my AnyConnect?

That depends on where your AnyConnect is running. Is it Linux? In that
case I think it's bizarrely in your *Firefox* certificate store? If you
set it up correctly in p11-kit you could probably ask OpenConnect to
use it directly from there.

On Windows it might be in the Windows certificate store. I think
OpenConnect can use it from there if running on Windows, or if you want
to take it elsewhere you might need to use JailBreak to extract it.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: ocserv in VyOS

[David Woodhouse]

On Sun, 2020-09-06 at 10:21 -0700, Yuriy Andamasov wrote:
> Nikos. Basically several things we have in mind.
> 
> 1) we acquired and want to donate to the project next domains
> openconnectvpn.com(http://openconnectvpn.com),
> openconnectvpn.net(http://openconnectvpn.net),
> openconnectvpn.org(http://openconnectvpn.org)

Sounds good; thanks. If you set ns[0123].infradead.org as the
nameservers for those, I can point it at the existing web hosting for
now.

> we also happy to maintain them financially and technically if that
> needed

If it's easy for you to host a VM which will be part of the infradead
cluster, that would be useful — the VM hosting www/ftp is currently
temporarily living on an underpowered box on my home DSL line.

> 2) develop new design that combine common parts of old webs content
> but visually separates server and client subprojects

That would be much appreciated; we've been hoping to update the web
site for a while.

> 3) Optionally, improve social media presence and provide additional
> tools to the team.

This sounds good too. Looking forward to it!

As Nikos said, welcome to the OpenConnect world :)


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: ocserv in VyOS

[David Woodhouse]

On Thu, 2020-09-03 at 14:27 +0200, Nikos Mavrogiannopoulos wrote:
> What do you have in mind? Currently both sites are similar but
> independent, with server's pages being at:
> https://gitlab.com/ocserv/www
> and client pages at:
> https://gitlab.com/openconnect/openconnect/-/tree/master/www

Both are converted into HTML from the content XML files by a python
script. Updating that so that we produce 21st century mobile-friendly
HTML would be extremely useful.





smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: How to get or Build Openconnect for Windows

[David Woodhouse]

On Tue, 2020-08-11 at 10:21 +0100, Andrew Hogg wrote:
> I have been trying to figure out how to get openconnect for windows -
> and I really do apologise, but I cannot for the life of me figure out
> how to get it.
> 
> Do I have to build it? or can I just download it from somewhere?
> 
> I'm just really looking for the command line version of openconnect -
> I would install the graphical one, but it hasn't been updated since
> 2017 and all I really need is the command line utility to build the
> tunnel to my work VPN so I can control the routes in my routing table
> and have split tunneling.
> 
> On your website I have found the bit that says:
> 
> "Windows
> 
> The Fedora dwmw2/openconnect COPR mentioned above contains
> mingw-openconnect packages built for 32-bit and 64-bit Windows."
> 
> And I got to the following place:
> 
> https://copr-be.cloud.fedoraproject.org/results/dwmw2/openconnect/fedora-32-x86_64/01392924-mingw-openconnect/
> 
> And I think I might be on the right track, but honestly have no idea -
> that location appears to only have linux stuff in it - do I need to
> build the Windows exe etc from Linux?
> 
> Please can you point me in the right direction as I really don't want
> to be tied to the official anyconnect client as it hijacks my computer
> and forces everything through the VPN - I want to choose what goes
> through.
> 
> I'm not an idiot - but I'm lost - please help me.

MinGW gives us a way to build Windows DLLs and executables on a proper
computer. The Fedora packages are really supposed to be for DLLs, so
that you can cross-build your application on Fedora. In the COPR we
abuse that slightly because we build the actual openconnect.exe too, in
the mingw-openconnect package.

You can extract the openconnect.exe and libopenconnect-5.dll from the
mingw64-openconnect package, as well as the other required DLLs from
other packages. The easiest way to get them all is just to install
mingw64-openconnect on a Fedora system, and it'll pull in all the other
DLL packages you need as dependencies.

Obviously this would be nicer if we made an *installer* which included
in the DLLs you need, and you didn't need to pull them out of the
packages that are intended for building your own stuff.

It probably wouldn't be hard to put together a simple NSIS installer
script for that. Then we can automate the process and always have
installers for the latest version. Volunteers welcome :)



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

lists.infradead.org restored from backup, git.infradead.org down.

[David Woodhouse]

The machine hosting lists.infradead.org and git.infradead.org suffered
a complete disk failure over the weekend; sadly the last backup of the
mailman config was fairly old (May 2018) so the subscriber lists and
archives have been reset to that date, but the lists should be running
again.

I've recreated the new lists which had been created since then.

The lists should be up and running again on a new host; we can recreate
archives if anyone can provide the mailboxes.

Users will have to resubscribe (and in some cases, unsubscribe again).
Apologies for the inconvenience.

If you had personal email hosted on, or going through,
bombadil.infradead.org then please let me know and we can move you to
another box.

The dead box was also git.infradead.org; I'll be fixing that next... if
you had an account and want it reinstated then please let me know.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: openconnect with SAML and GlobalProtect

[David Woodhouse]

On Thu, 2020-05-21 at 16:32 -0400, Michel van der List wrote:
>  > If *that* doesn't work, try building with @yuezk's recent patch
>  > (https://gitlab.com/openconnect/openconnect/-/merge_requests/109),
>  > which will let you authenticate to the portal and then pass whatever
>  > cookies it gets through to the gateway. This appears to work on *some
>  > GP servers* with SAML, but not others.
> 
> OK, that will take a bit. I was just using the 'bog standard' Fedora
> delivered openconnect :-).

If I merge that MR, it'll show up in the COPR at 
https://copr.fedorainfracloud.org/coprs/dwmw2/openconnect/

I've been waiting for less mixed signals like "doesn't work for all
cases" from Dan... :)


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

OpenConnect 8.10 release

[David Woodhouse]

This release is brought to you by CVE-2020-12823; a buffer overflow
when obtaining a pretty name to describe local certificates, when built
against GnuTLS. Note that this isn't used for remote certificates; this
is all local (client cert and supporting CAs provided locally) so not
easily remotely triggerable.

Thanks to Sergei Trofimovich and Mike Gilbert for reporting and fixing
that.

Also some minor fixes, including fixing the path of the openconnect
executable in the bash completion script and updating the Android
build.

ftp://ftp.infradead.org/pub/openconnect/openconnect-8.10.tar.gz
ftp://ftp.infradead.org/pub/openconnect/openconnect-8.10.tar.gz.asc

Daniel Lenski (8):
  add and fix a few changelog entries
  fix wrong string in error message
  stop asking users to report unexpected GP login argument arg[19]="4"
  some ASAs are confused by stripping newlines from CSD response
  Also disable cURL's use of HTTP/1.1 expect logic
  Juniper frmNextToken: recognize secidactionEnter as submit button
  stop asking users to report unexpected GP login argument arg[20]="unknown"
  get rid of a bunch of casts

David Woodhouse (25):
  No SoftHSM for EPEL8 for now
  Add DLL requires for mingw package
  Fix up changelog confusion a bit more
  Update translations from GNOME
  Import wine fix for CI
  Attempt to fix EPEL8 build
  Revert "Add DLL requires for mingw package"
  The sigterm test is actually passing on CentOS8/GnuTLS
  No, the sigterm test is just unreliable, like it always has been.
  More debug for sigterm
  Fix sigterm test at last
  Fix path to openconnect in bash completion
  Use shorter pathname for COPR RPM build
  Merge branch 'bash-completion' of gitlab.com:bluca/openconnect
  Fix up COPR specfiles for bash-completion script location
  Fix name of tpm2-tss-engine
  Disable OpenSSL RDRAND in COPR tests to work around SoftHSM deadlock
  Merge branch 'do_not_strip_newlines_in_CSD_response' of 
gitlab.com:dlenski/openconnect
  Merge branch 'GP_stop_asking_to_report_unexpected_arg19=4' of 
gitlab.com:openconnect/openconnect
  Merge branch 'Juniper_frmNextToken_submit_button' of 
gitlab.com:openconnect/openconnect
  Update Android dependencies
  Bump Android API level to 23 to allow it to run on Android 10
  Merge branch 'bug721570' of gitlab.com:floppym/openconnect
  Update changelog
  Tag version 8.10

Luca Boccassi (3):
  Bash completion: install as 
/usr/share/bash-completion/completions/openconnect
  Fix typo in autocomplete test log message
  Install tncc-emulate.py too

Sergei Trofimovich (1):
  gnutls: prevent buffer overflow in get_cert_name


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: using networkmanager nmcli with globalprotect

[David Woodhouse]

On Fri, 2020-05-01 at 18:39 +0100, Dave Love wrote:
> David Woodhouse  writes:
> 
> > The three secrets it's looking for there are the *result* of
> > authentication. Whatever you have to do with certificates, passwords,
> > SAML and 2FA aren't relevant; it just wants three things:
> > 
> >  • The host you ended up authenticating to (after redirects, etc.).
> >  • Hash of *its* SSL certificate.
> >  • The 'cookie' that was the result of successful authentication.
> 
> Thanks, rather late, for this.  Should that have been obvious from the
> doc somewhere I didn't find?

I don't think so. I try to be quite good at documenting OpenConnect
itself, but documentation on the NetworkManager-openconnect interaction
has been somewhat lacking. Users *mostly* shouldn't have to care about
that.


> > Those are the things you get if you run 'openconnect --authenticate'.
> > 
> > Here's a script which will provide them to NetworkManager for you:
> 
> I adapted that, using "--protocol gp -q --usergroup=gateway" in the
> authN step and extracting the gateway from the named VPN config.  It
> brings up the VPN, so I'm happy, but somewhat uncleanly.  First, the
> authentication command produces
> 
>   GlobalProtect login returned unexpected argument value arg[19]=4
>   Please report 1 unexpected values above (of which 0 fatal) to 
> 

I think Dan's seen a few of those, and is on the verge of making not
print that message for that particular argument.

> Then nmcli produces
> 
>   Connected to HTTPS on ***
>   Got HTTP response: HTTP/1.1 502 Bad Gateway
>   Unexpected 502 result from server
>   Failed to obtain WebVPN cookie
>   Error: openconnect failed with status 1
>   Connection successfully activated (D-Bus active path: 
> /org/freedesktop/NetworkManager/ActiveConnection/18)
> 
> Obviously I can take suggestions to investigate if it's useful.

Hm, it does that and then connects successfully? That's interesting;
probably worth filing a bug with NetworkManager. It shouldn't be doing
that if it was *given* the secrets it needs.

> > The COPR has been unreliable recently. Broken versions of http-parser,
> > ocserv, wine in Fedora updates have been a pain, and recently a lot of
> > builds seem to die when running out of disk space.
> 
> OK.  I think I concluded that ocserv just wouldn't run in copr for some
> reason -- as opposed to koji and maybe plain mock.
> 
> > But there is a build of 8.09 for both el6 and el7.
> > https://copr-be.cloud.fedoraproject.org/results/dwmw2/openconnect/epel-6-x86_64/01356430-openconnect/
> > https://copr-be.cloud.fedoraproject.org/results/dwmw2/openconnect/epel-7-x86_64/01356430-openconnect/
> 
> Apologies.  I don't know how I missed them, apart from the builds in
> copr being confusing.  Is there a good reason not just to update the
> EPEL7 package (rhbz #1765111)?

No, I don't think there is a good reason. We should probably update the
EPEL packages.

> > >  The rpms and dpkgs are built with the trojan in the same
> > > place for ease of documentation rather than using the dwmw2 PPA, but
> > > that make contravene Debian rules which I'm not up-to-date with.  The
> > > PPA also doesn't have a recent enough network-manager-openconnect.)
> > 
> > Hm, is that just for EPEL or also for Fedora? Let's fix that in my COPR
> > too. What's missing?
> 
> If you mean fix the location, I think I just modified just the dpkg
> trojan location to agree with the rpm's for ease of local documentation
> as I was rebuilding, and that might be wrong for Debian, though I think
> it was in an arch-specific directory as just a script.  I don't think
> anything needs changing in your copr as I see it's now gained an EPEL7
> NetworkManager-openconnect 1.2.6, and mine can be scrapped.

Yeah, I pulled in your build fix for the 'without libnm-glib' thing and
pushed it to the main Fedora repository so that the latest will also
build on EPEL7. That isn't always the right thing to do, but where it's
trivial enough, we might as well. Thanks.




smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: --protocol=pulse and smb access

[David Woodhouse]

On Thu, 2020-04-30 at 21:24 +0200, Thierry de Coulon wrote:
> On Thursday 30 April 2020 21.05:27 Daniel Lenski wrote:
> 
> > Compare your routing table (`ip route`) and DNS servers (`cat
> > /etc/resolv.conf`) after connecting to the Pulse and Juniper versions.
> > What are the differences?
> 
> I can see no difference:

What is the MTU in each case? ifconfig will tell you.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: using networkmanager nmcli with globalprotect

[David Woodhouse]

On Thu, 2020-04-30 at 10:54 +0100, Dave Love wrote:
> I don't know if this should really be a networkmaneger question or
> not,
> but this seems the most likely place to ask for a recipe.
> 
> I've built backported packages for network-manager-openconnect to
> support use with globalprotect (and Duo 2fa); see below.  They work
> under network-manager-gnome configured to use the GP gateway
> straightforwardly via the GUI:  authenticate with , code>
> and connect.
> 
> However I'd like to use the command line (nmcli), rather than raw
> openconnect (which works), on remote systems.  I'm used to doing that
> with a less-reliable tcp-over-tcp openvpn service just by doing
>   nmcli --ask c up 
> and authenticating.  However, I can't get it working with
> openconnect/GP.  The doc isn't clear to me about the prompts I'm
> seeing
> and how to configure out what I don't need -- at least the a
> certificate.  I get this output, assuming the first prompt is for
> ,:
> 
>   Connected to HTTPS on ***
>   Got HTTP response: HTTP/1.1 502 Bad Gateway
>   Unexpected 502 result from server
>   Failed to obtain WebVPN cookie
>   Error: openconnect failed with status 1
>   A password is required to connect to 'GP'.
>   Gateway (vpn.secrets.gateway): 
>   A password is required to connect to 'GP'.
>   Cookie (vpn.secrets.cookie): 
>   A password is required to connect to 'GP'.
>   Gateway certificate hash (vpn.secrets.gwcert): 
>   Error: Connection activation failed: No valid secrets
> 
> Can anyone advise?

The three secrets it's looking for there are the *result* of
authentication. Whatever you have to do with certificates, passwords,
SAML and 2FA aren't relevant; it just wants three things:

 • The host you ended up authenticating to (after redirects, etc.).
 • Hash of *its* SSL certificate.
 • The 'cookie' that was the result of successful authentication.

Those are the things you get if you run 'openconnect --authenticate'.

Here's a script which will provide them to NetworkManager for you:

#!/bin/sh

HOST="$1"
if [ -z "$HOST" ]; then
HOST=vpn.example.com
fi
COOKIE=
eval `openconnect --user $LOGNAME $HOST --authenticate`

if [ -z "$COOKIE" ]; then
exit 1
fi

nmcli con up 'Example VPN' passwd-file /proc/self/fd/5 5< If the backported packages are useful, Debian/Ubuntu is at
>  and EL6/EL7 is at
> .  (The
> dwmw2 copr doesn't have recent versions for el6/7; there are many build
> attempts which are failing after a day, I think just because the tests
> won't run. 

The COPR has been unreliable recently. Broken versions of http-parser,
ocserv, wine in Fedora updates have been a pain, and recently a lot of
builds seem to die when running out of disk space.

But there is a build of 8.09 for both el6 and el7.
https://copr-be.cloud.fedoraproject.org/results/dwmw2/openconnect/epel-6-x86_64/01356430-openconnect/
https://copr-be.cloud.fedoraproject.org/results/dwmw2/openconnect/epel-7-x86_64/01356430-openconnect/


>  The rpms and dpkgs are built with the trojan in the same
> place for ease of documentation rather than using the dwmw2 PPA, but
> that make contravene Debian rules which I'm not up-to-date with.  The
> PPA also doesn't have a recent enough network-manager-openconnect.)

Hm, is that just for EPEL or also for Fedora? Let's fix that in my COPR
too. What's missing?



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Request /robots.txt

[David Woodhouse]

On 29 April 2020 18:33:18 BST, cool...@gmail.com wrote:
>Can ocserv serve up a simple /robots.txt?  I'd like to stop
>(well-behaved) web spiders from visiting /auth/ and generating log
>noise.  That would help to put the focus on the misbehaved bots and/or
>malicious requests.
>
>ocserv is great software, BTW.  I only wish the OpenConnect-GUI client
>actually said "OTP" when prompting for the 2fa token, and not just
>"Password" again... That's much too confusing for users.


I've just added mingw-openconnect to the Fedora COPR package archive, giving us 
automatic builds of OpenConnect for Windows as well as for Fedora. That's just 
the command line openconnect.exe and libraries.

Adding OpenConnect-GUI builds to that would be good, if I can find Windows 
users to help test...

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

OpenConnect 8.09 release

[David Woodhouse]

This release fixes a problem with the OpenSSL build validating
hostnames against server certificates, which is CVE-2020-12015. A
server with an invalid (yet genuinely issued by a trusted CA)
certificate could bypass the hostname check and use that certificate
for *any* server.

The GnuTLS build is not affected.

Also some fixes for the Juniper Host Checker (TNCC), cleaning up non-
canonical include/exclude subnet masks for exporting to vpnc-script,
and added bash autocompletion support.


ftp://ftp.infradead.org/pub/openconnect/openconnect-8.09.tar.gz
ftp://ftp.infradead.org/pub/openconnect/openconnect-8.09.tar.gz.asc

Daniel Lenski (23):
  convert tncc-wrapper.py to Python 3.6
  we can be a *little* more user-friendly
  Try blithely ignoring lack of IcedTea plugin.jar and/or tncc_preload.so
  recent tncc.jar looks for files in ~/.pulse_secure rather than 
~/.juniper_networks
  pass TNCC_SHA256 and TNCC_HOSTNAME environment variables to wrapper 
script (just like for CSD)
  Include tncc-emulate.py
  Add copyright and license notice, and update TNCC docs
  tncc-emulate.py: update to modernized Python 3.x version
  Add a comment explaining required Python3 modules and potentially 
customizable environment variables
  tested that Ubuntu 18.04's python3-asn1crypto version works (v0.24.0)
  remove vestigial bit
  periodic TNCC
  GP auth: give challenge/2FA forms a constant auth_id/name of "_challenge"
  better heuristic for determining where to fill in a token in GP forms
  Fix print_supported_protocols and print_supported_protocols_usage
  periodic HIP fix: ping /ssl-vpn/hipreportcheck.esp at specified interval 
no matter what
  GP: run HIP report 60 seconds in advance of the server's interval (just 
as we rekey 60 seconds in advance)
  trigger periodic TNCC even if we have no packets to receive from oNCP, 
and don't use server's interval if zero
  URL-decode GlobalProtect login response fields
  Changelog entry for GP changes (covers !90, !93, !95)
  set TCP_NODELAY unconditionally on TCP/TLS sockets
  changelog
  fix IPv4 split-{in,ex}clude routes with misspecified host bits

David Woodhouse (25):
  Add bash completion
  Fix autocompletion a bit more, add tests
  More helpful error when Pulse server asks for TNCC
  No autocompletion test for mingw build
  Fix uninitialised 'matcher' in autocompletion
  Clean up autocompletion a little
  Check for localtime_s() only on Windows.
  Add AC_DEFINE description for LIBPROXY_HDR in non-pkgconfig case
  Merge branch 'potential_HIP_fix' of gitlab.com:openconnect/openconnect
  Merge branch 'fix_print_supported_protocols' of 
gitlab.com:openconnect/openconnect
  Merge branch 'modify_GP_challenge_2FA_form_handling' of 
gitlab.com:openconnect/openconnect
  Merge branch 'GP_urldecode_login_arguments' of 
gitlab.com:dlenski/openconnect
  Merge branch 'tncc_wrapper_Py3k' of gitlab.com:dlenski/openconnect
  Merge branch 'use_TCP_NODELAY_when_tunnel_running_over_TCP' of 
gitlab.com:openconnect/openconnect
  Update SoftHSM token import scripting and reimport
  Reimport with SoftHSM v2.2
  Log in slots with CKF_USER_PIN_INITIALIZED and not CKF_LOGIN_REQUIRED
  Add CentOS8 CI
  Add commands for creating server-cert
  Fix dependencies and tests/configs/server-cert.prm to dist
  Add mingw build in copr
  Drop wine-common for now, openconnect.exe in bindir
  Build mingw with lz4 and stoken
  Update translations from GNOME
  Tag version 8.09

Jordy Zomer (1):
  Use OpenSSL X509_check_host() and X509_check_ip() correctly.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Error when executing ./autogen.sh

[David Woodhouse]

On Sun, 2020-04-19 at 18:13 +0200, videoclocknet wrote:
> Guys, with Ubuntu Server 18.04 I've got the following message when
> executing ./autogen.sh:
> 
> # ./autogen.sh
> autoheader: warning: missing template: LIBPROXY_HDR
> autoheader: Use AC_DEFINE([LIBPROXY_HDR], [], [Description])
> 
> So the configure file is not finally generated. I had pkg-config
> package installed in its last version
> 
> It seems that's happening to more people in other distros:
> https://github.com/dlenski/openconnect/issues/3
> https://github.com/dlenski/openconnect/issues/37
> 
> I've got to solve it by passing the description argument when defining
> the LIBPROXY_HDR library. So if you've got:
> 
> AC_DEFINE([LIBPROXY_HDR], ["proxy.h"])
> 
> You need to change it to:
> AC_DEFINE([LIBPROXY_HDR], ["proxy.h"], [libproxy header file])
> 
> This is at lines 729 and 735 of  configure.ac file.

Thanks for the report.

> - Is there any reason to not pass the description argument in these 2 cases?

No reason. I just failed to add it when I added the description to most
other AC_DEFINE macros, when autoconf started whining about it a few
years ago.

> - Would it be appropriate to make this change on master?

Yes, I've done so. Thanks.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: OpenConnect prebuild version requested

[David Woodhouse]

On Mon, 2020-04-20 at 10:51 -0700, Daniel Lenski wrote:
> On Mon, Apr 20, 2020 at 2:22 AM Martin Moche 
> wrote:
> > Can you build one for me that I can install easily? or do I need to
> > build OpenConnect from source code?
> > 
> > I prefer not to update my entire OS from Scientific Linux 7.7
> > (Nitrogen) into something later...
> 
> There are lots of Linux distributions out there, and we can't keep up
> with them all. I, for one, had never even heard of Scientific Linux.
> It appears to be based on RHEL, so you *may* be able to install
> OpenConnect RPM packages built for corresponding version of RHEL or
> CentOS….

In fact the EPEL7 build is one of the few builds that *is* working in
the COPR at https://copr.fedorainfracloud.org/coprs/dwmw2/openconnect


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: openconnect-8.0[568] on Solaris dumps core in print_supported_protocols_usage (main.c:674)

[David Woodhouse]

On Mon, 2020-04-20 at 10:22 -0700, Daniel Lenski wrote:
> Good catch. It appears this broke in
> https://gitlab.com/openconnect/openconnect/-/commit/7cb8996e21b442c4ec60ce25c87e8a69516fac17#05d8493af0b3a0d467325299d974b0949981595d_189_189,
> when David cleaned up the protocol-enumerating code and removed the
> empty/null protocol definition from the end of the list. The problem
> is that the `print_supported_protocols` function *wasn't* modified
> here… urk.
> 
> I'm a little bit mystified about why this appears to *continue to
> work* on Linux, which is why we haven't noticed it, even though it
> causes the expected SIGSEGV on Solaris. My guess is that Linux's
> `calloc` allocates more zero bytes than requested, silently hiding the
> problem.

Shows up if you run in valgrind though:

  --protocol=pulseCompatible with Pulse Connect Secure SSL VPN
==30263== Invalid read of size 8
==30263==at 0x10FD76: print_supported_protocols_usage (main.c:680)
==30263==by 0x10FD76: usage (main.c:807)
==30263==by 0x10C05C: main (main.c:1810)
==30263==  Address 0xc049f90 is 0 bytes after a block of size 128 alloc'd
==30263==at 0x4C31B25: calloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30263==by 0x4E4D00B: openconnect_get_supported_protocols (library.c:198)
==30263==by 0x10FD04: print_supported_protocols_usage (main.c:678)
==30263==by 0x10FD04: usage (main.c:807)
==30263==by 0x10C05C: main (main.c:1810)
==30263== 

> I've created a MR to properly fix this:
> https://gitlab.com/openconnect/openconnect/-/merge_requests/94

Nah, if openconnect_get_supported_protocols() originally returned an
array with the sentinel included, then that is its ABI. We broke that.

Fixing up our own usage of that ABI doesn't actually excuse changing
the ABI. And yes, one of the two callers in NetworkManager-openconnect
does depend on the sentinel. We have to put it back.

I think we *can* get away with returning the correct value (e.g. 4 now)
rather than the 5 we used to return before commit 7cb8996e21. Even
though that's strictly an ABI change it shoujld be OK.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Option for endpoint.anyconnect.deviceuniqueid of Cisco/ASA DAP

[David Woodhouse]

On Thu, 2020-04-16 at 22:46 +0200, yesi wrote:
> Hi,
> 
> Thank you for your works.
> 
> 
> I was given a windows laptop with Anyconnect client to connect to
> the 
> VPN server.
> 
> There is an registered unique ID (i suppose 
> endpoint.anyconnect.deviceuniqueid) that was made when the windows 
> client was connected for the first time.
> 
> So before that the filter was applied, using Openconnect on Linux to 
> connect to Cisco/ASA SSL VPN does work.
> 
> 
> But today, the admin to secure better uses DAP of Cisco/ASA, to
> filter 
> by that unique ID. I have that ID.
> 
> It seems that it uses |%ASA-7-734003|.
> 
>  From [1], there are various options that can be given.
> 
> Openconnect does not give some options when connecting into the ASA
> logs 
> : it does not give that ID when logging. i do not see these
> informations 
> into the ASA logs.
> 
> But AnyConnect client on a Windows station give to ASA logs some 
> endpoint options as :
> 
> - endpoint.anyconnect.deviceuniqueid
> 
> - endpoint.anyconnect.macaddress
> 
> - endpoint.anyconnect.address
> 
> - etc
> 
> 
> What i would like to use is to give the option of 
> endpoint.anyconnect.deviceuniqueid when running openconnect.
> 
> I am not it is implemented, isn't it ?
> 
> If yes, which option could i use ?
> 
> If not, do you think that option could later be added ?
> 
> Actually, i can use the 8.05, 8.06 and Git version.
> 
> 
> Thank you in advance for return.

I think you can set at least the unique ID with the
openconnect_set_mobile_info() function, which isn't exposed on the
command line. Do you want to try using that and let us know if it does
what you expect?

There was a patch at
http://lists.infradead.org/pipermail/openconnect-devel/2016-July/003808.html
which attempted to add support for it for non-mobile platforms but it
needed a little more work. We should probably revisit that.


I note modern AnyConnect also sends a 'unique-id-global' as well as the
'unique-id' field.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Possible problem with checking compliance

[David Woodhouse]

On Tue, 2020-04-14 at 09:10 -0400, Emanuele Bardelli wrote:
> Hi Folks!
> 
> I am running into an error when trying to connect to a vpn that has a grid 
> challenge.
> 
> This is the error I get:
> 
> Unexpected IF-T/TLS authentication challenge:
> < :  00 00 55 97 00 00 00 05  00 00 00 18 00 00 01 fa  |..U�|
> < 0010:  00 0a 4c 01 04 04 00 04   |..L.|
> Failed to obtain WebVPN cookie
> 
> When I connect with the pulse connect client, it cycles through a
> “checking compliance” stage. Is there a setting that I missing? I am
> calling openconnect with only the pulse option.

Hm, that's an EAP failure. Which suggests something went wrong earlier.
Can you run with -vv --dump-http-traffic and show the whole connection?

Are you able to use a MITM proxy and see what the pulse connect client
actually does here? 



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: [E] Re: openconnect vpn for linux machine

[David Woodhouse]

On 13 April 2020 07:49:07 BST, "Nb, Midhunlal"  
wrote:
>Hi,
>If open VPN is work in juniper srx for ubuntu, can you please share an
>open VPN configuration guide?

No. Not with the SRX. You could set up a Linux VPN server running ocserv (or 
OpenVPN) alongside your SRX, to serve the Linux users.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: [E] Re: openconnect vpn for linux machine

[David Woodhouse]

On 9 April 2020 09:56:10 BST, "Nb, Midhunlal"  
wrote:
>Ok, thanks for the clarification.

You aren't the first person asking about IKE support recently. It would be a 
very welcome addition and we can certainly give development pointers — and 
there's existing code for a lot of the pieces which will make life easier.

But it's definitely a development task, not a quick fix. Maybe 2-3 weeks?

In the short term I'd suggest using ocserv.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: [E] Re: openconnect vpn for linux machine

[David Woodhouse]

On 9 April 2020 07:52:23 BST, "Nb, Midhunlal"  
wrote:
>Hi,
>we are using IPsec VPN using IKE  in our juniper srx. I want to know
>that any option is there to connect the openconnect VPN  in SRX?.

That isn't supported at the moment although we would like to add it. The client 
that supports IKE is vpnc, but its development has basically stopped and I 
don't believe it supports Juniper.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: [E] Re: openconnect vpn for linux machine

[David Woodhouse]

On Tue, 2020-04-07 at 17:05 +0530, Nb, Midhunlal wrote:
> Hi,
> please go through the below details
> 
> >  we are using juniper srx 345 firewall
> >  Junos version:15.1X49-D60.7
> >  For VPN we are using pulse secure (windows: pulse 5.1.5(61437),
> > MacBook:91.2(1181))
> 
> Now we need a VPN for LINUX (we are using UBUNTU OS)
> > for Linux which pulse client version we need to use and which
> > openconnect version I need to install in my Linux?

Use the latest version of OpenConnect. For Ubuntu there is a PPA at 
https://launchpad.net/~dwmw2/+archive/ubuntu/openconnect


> > which version (pulse version and open connect version)is compatible
> > with srx and Linux?
> > I need a configuration guide

As it says in the documentation at 
http://www.infradead.org/openconnect/pulse.html you just need to try
connecting to your existing server using --protocol=pulse.

If that doesn't work, then also try --protocol=nc which is the older
Juniper Network Connect protocol. Most Pulse servers still support that
too.

> > Any extra configuration (eg: self-signed certificate, key pair
> > generation) needs in juniper firewall for Linux VPN?

Are you asking me about the configuration of *your* VPN server?

If you give me the root password for it perhaps I can answer those
questions... ?

> We are facing a lot of pressure due to this VPN issue in Linux.due to
> work from home every user needs VPN connectivity in their Linux
> machine. Please help on this issue.

Have you actually *tried* pointing OpenConnect at the existing
server...?


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: openconnect vpn for linux machine

[David Woodhouse]

On Tue, 2020-04-07 at 12:01 +0530, Nb, Midhunlal wrote:
> Hi team,
> 
> We are using juniper srx 345 in our lab for vpn we are using
> pulsesecure.my problem is some of our users need VPN connectivity in
> their linux machine.but officially juniper is not supporting linux for
> vpn through pulse secure.Now we are in a big trouble.can you please
> suggest a solution for this issue using openconnect VPN?

Hi,

OpenConnect supports the Pulse Secure servers, using either the legacy
Juniper mode with --protocol=nc (which is limited to Legacy IP), or the
newer Pulse protocol with --protocol=pulse.

The latter doesn't work with the Host Checker yet.

I'd suggest giving it a try and letting us know with some more details
if it isn't working for you.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Trying to connect Pulse Secure VPN: XML response has no "auth" node

[David Woodhouse]

On Mon, 2020-04-06 at 21:19 +0200, videoclocknet wrote:
> I've tried with 3 different commands, which are:
> 1.- openconnect https://vpnserver.com/path -c mycertificate.p12
> --dump-http-traffic -
> 2.- openconnect


That's trying Cisco AnyConnect (the default).

> https://vpnserver.com/dana-na/auth/url_132/login.cgi?realm=SARA3%20Realm
> -c mycertificate.p12 --dump-http-traffic -

So is that.

> 3.- openconnect
> https://vpnserver.com/dana-na/auth/url_132/login.cgi?realm=SARA3%20Realm
> -c mycertificate.p12 --dump-http-traffic - --protocol=gp

And that one is trying GlobalProtect.

Try --protocol=pulse or --protocol=nc.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

OpenConnect 8.08 release

[David Woodhouse]

Third release in a week. I'm going to try really hard not to make
another one for a while... although not *too* long because we're
working on the webview support which will improve the authentication
capability and add proper SAML support. We want to work out a stable
interface for that before it makes it into a release though.

What *is* in this release is a fix for case sensitivity of pin-sha256
hashes in the --servercert option, a fix for a crash when OIDC mode was
select but no token provided, and some more improvements to the CSD
trojan handling when there's no stderr.

ftp://ftp.infradead.org/pub/openconnect/openconnect-8.08.tar.gz
ftp://ftp.infradead.org/pub/openconnect/openconnect-8.08.tar.gz.asc

David Woodhouse (12):
  Disable GnuTLS version check for COPR build
  Disable GnuTLS version check for CI builds
  Make csd-post.sh cope with not being able to write to stdout
  Open /dev/null instead of passing non-functional stderr to CSD trojans
  Fix matching of pin-sha256: public key hashes to be case-sensitive
  Update translations from GNOME
  Check for failure opening /dev/null
  Fix SEGV on empty OIDC token
  Add tests for --servercert matching
  Changelog for OIDC NULL fix
  Import pending Fedora 31 updates to fix CI
  Tag version 8.08


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Certificate Validation Failure when using smartcard

[David Woodhouse]

On Sun, 2020-04-05 at 23:08 +0200, Kai G wrote:
> On Sun, 5 Apr 2020 at 23:03, David Woodhouse  wrote:
> > 
> > On Sun, 2020-04-05 at 22:49 +0200, Kai G wrote:
> > > After Client Hello and Server Hello the server sends a certificate
> > > request and this is the answer sent by the anyconnect client.
> > > Should't there be certificates visible? When the server sends its cert
> > > it has a length of 1709 but here in the clients response the
> > > certificates length is 0.
> > 
> > Yeah, I'd expect to see it there, if you have the right part of the
> > exchange.
> > 
> > Can you try OpenConnect 8.07? There's a possibility this was fixed by
> > https://gitlab.com/openconnect/openconnect/-/merge_requests/76
> 
> Thanks, I will try that. Any chance to even get that running on that
> Ubuntu 18.04 machine regarding dependencies
> or will I need something newer?

https://launchpad.net/~dwmw2/+archive/ubuntu/openconnect


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Certificate Validation Failure when using smartcard

[David Woodhouse]

On Sun, 2020-04-05 at 22:49 +0200, Kai G wrote:
> After Client Hello and Server Hello the server sends a certificate
> request and this is the answer sent by the anyconnect client.
> Should't there be certificates visible? When the server sends its cert
> it has a length of 1709 but here in the clients response the
> certificates length is 0.

Yeah, I'd expect to see it there, if you have the right part of the
exchange.

Can you try OpenConnect 8.07? There's a possibility this was fixed by
https://gitlab.com/openconnect/openconnect/-/merge_requests/76


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: NetworkManager-openconnect multiple VPN Hosts

[David Woodhouse]

On Thu, 2020-04-02 at 15:20 +0200, Grant Williamson wrote:
> Is there a way to specify multiple VPN hosts in the
> NetworkManager-openconnect system-connections profile?
> 
> I can see there is a drop down menu option in the connection dialog,
> wondering how to add multiple hosts(if possible)?

It gets them out of the XML profile which is provided from the
AnyConnect server.

The xmlconfig key in the VPN date contains that XML, base64-encoded.
Make it look like an AnyConnect profile file. So something like...


  

  My First Server
  vpn1.example.com


  My Second Server
  vpn2.example.com

  


...would base64-encode to:

PEFueUNvbm5lY3RQcm9maWxlPgogIDxTZXJ2ZXJMaXN0PgogICAgPEhvc3RFbnRyeT4KICAgICAg
PEhvc3ROYW1lPk15IEZpcnN0IFNlcnZlcjwvSG9zdE5hbWU+CiAgICAgIDxIb3N0QWRkcmVzcz52
cG4xLmV4YW1wbGUuY29tPC9Ib3N0QWRkcmVzcz4KICAgIDwvSG9zdEVudHJ5PgogICAgPEhvc3RF
bnRyeT4KICAgICAgPEhvc3ROYW1lPk15IFNlY29uZCBTZXJ2ZXI8L0hvc3ROYW1lPgogICAgICA8
SG9zdEFkZHJlc3M+dnBuMi5leGFtcGxlLmNvbTwvSG9zdEFkZHJlc3M+CiAgICA8L0hvc3RFbnRy
eT4KICA8L1NlcnZlckxpc3Q+CjwvQW55Q29ubmVjdFByb2ZpbGU+Cg==

So if I change one of my test connections...

nmcli con modify 'Pulse' vpn.secrets 
"xmlconfig=PEFueUNvbm5lY3RQcm9maWxlPgogIDxTZXJ2ZXJMaXN0PgogICAgPEhvc3RFbnRyeT4KICAgICAgPEhvc3ROYW1lPk15IEZpcnN0IFNlcnZlcjwvSG9zdE5hbWU+CiAgICAgIDxIb3N0QWRkcmVzcz52cG4xLmV4YW1wbGUuY29tPC9Ib3N0QWRkcmVzcz4KICAgIDwvSG9zdEVudHJ5PgogICAgPEhvc3RFbnRyeT4KICAgICAgPEhvc3ROYW1lPk15IFNlY29uZCBTZXJ2ZXI8L0hvc3ROYW1lPgogICAgICA8SG9zdEFkZHJlc3M+dnBuMi5leGFtcGxlLmNvbTwvSG9zdEFkZHJlc3M+CiAgICA8L0hvc3RFbnRyeT4KICA8L1NlcnZlckxpc3Q+CjwvQW55Q29ubmVjdFByb2ZpbGU+Cg=="


... and try to connect it it...

Yep, that works.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Connection successful but can't reach any resources on the Remote Network

[David Woodhouse]

On Wed, 2020-04-01 at 11:35 -0400, Darren Fuller wrote:
> Hey Daniel,
> 
> Quick question...   i installed GNUTLS 3.6.13, the most recent
> version...   and when i ./configure the openconnect bits...  i see
> this:
> 
> ...
> checking for known-broken versions of GnuTLS... yes
> configure: error: DTLS is insecure in GnuTLS v3.6.3 through v3.6.12.
> see https://gitlab.com/gnutls/gnutls/issues/960
> Add --without-gnutls-version-check to configure args to avoid this
> check (DTLS
> will still be disabled at runtime), or build with another version.
> 
> Do you know if the DTLS issue still exists in 3.6.13 (as the warning
> says v3.6.3 through v3.6.12, which i should be outside of).. or is
> there a problem with the test?

Can you pull and try again please?



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Pulse connect to workstation

[David Woodhouse]

On Tue, 2020-03-31 at 11:01 -0400, Tim Howard wrote:
> On Sun, Mar 29, 2020 at 1:34 PM Tim Howard 
> wrote:
> > 
> > Thank you both for your replies. Here's the result with just using
> > the hostname:
> > 
> > $ openconnect -C "DSID=aLongStringOfChars" --protocol=pulse
> > myWorkplace.server.serv -v --os=win
> > Attempting to connect to server 123.123.123.233:443
> > Connected to 123.123.123.233:443
> > SSL negotiation with myWorkplace.server.serv
> > Connected to HTTPS on myWorkplace.server.serv
> > Got HTTP response: HTTP/1.1 404 Not Found
> > Transfer-Encoding: chunked
> > Strict-Transport-Security: max-age=31536000
> > HTTP body chunked (-2)
> > Unexpected 404 result from server
> > Creating SSL connection failed
> > 
> > 
> > ..so it looks like I get the same result doing it that way. Daniel,
> > I
> > don't have much hope that the network admins will enable legacy
> > mode,
> > but sometimes they surprise me. So if I continue to be roadblocked
> > with pulse, I'll try to reach out to them.
> > Tim
> 
> Is there anything I can do/provide to help further along your work on
> the pulse connection protocol? Or, perhaps, anything else I should
> try?


Can you stick a MITM proxy like http://david.woodhou.se/proxy.go in themiddle 
and watch what happens when the 'real' client connects? 

I think you don't have proper VPN here; you essentially only have port
forwarding. We *do* have an idea how that works, and it would be
possible to build a client for it but it doesn't fit well into the
"VPN" model. It'd end up being a different application that just
happens to use libopenconnect, I think. 




smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

OpenConnect 8.06 release

[David Woodhouse]

GnuTLS from 3.6.3 to 3.6.12 sends DTLS ClientHello with all zeroes in
the client random. This slightly unplanned release of OpenConnect
blacklists those versions for DTLS. Upgrade to GnuTLS 3.6.13 ASAP.

Some other stuff made it in before the release, including RFC6750
Bearer token support, support for a custom stoken file, and various
other fixes.

Other patches are being worked on and missed the boat; I'll probably do
another release relatively soon.

ftp://ftp.infradead.org/pub/openconnect/openconnect-8.06.tar.gz
ftp://ftp.infradead.org/pub/openconnect/openconnect-8.06.tar.gz.asc


Alan Jowett (1):
  Add support to OpenConnect client to use RFC6750 style Bearer tokens to 
authenticate to the server.

Corey Wright (6):
  GlobalProtect: Refactor HIP functionality into separate function
  Add framework to execute trojan periodically
  GlobalProtect: Add HIP check timeout separate from (re)connecting
  Allow user of application or API to override trojan interval
  GlobalProtect: Allow overriding trojan interval
  GlobalProtect: Ensure timeout is less than DPD when DTLS connecting

Daniel Lenski (57):
  Set correct mimetype and charset for XML post
  GlobalProtect login bugfix: reversed condition where portal form should 
be retried on gateway
  GlobalProtect: try to connect to portal interface before gateway
  explain GlobalProtect portals vs. gateways in the docs
  Fix double-free when client repeatedly fails to pull GlobalProtect client 
config
  another GP error string that tells the client to stop trying to reconnect
  clarify in manual how to use --cafile with --no-system-trust (ping issue 
#80)
  Try harder to explain unknown values in GP /ssl-vpn/login.esp response
  pass IDLE_TIMEOUT to configuration script
  don't show SAML login details in banner when alt-secret was specified 
(implying SAML login already done)
  log message should distinguish when SAML authentication is needed, vs. 
SAML authentication complete
  Don't show SAML details in banner, and don't show SAML “path” when it's 
actually a complete HTML page
  more possible login.esp arguments
  periodic HIP checking works fine with HTTPS tunnel as long as we 
pause-and-reconnect the tunnel
  simplify
  move dtls_state checks into gpst_connect() itself, to avoid repetition
  HIP timing nitpicks
  nitpick docs: --force-trojan option placement and description
  don't tell Windows/Java users to use --csd-wrapper since it doesn't work 
yet
  cleanup parse_portal_xml()
  fewer hardcoded constants, fewer problems
  Always openconnect_close_https() before intermittent HIP check
  Add undocumented --gnutls-priority command line option
  fail if GP portal config contains no gateways (rather than simply 
attempting to continue with same server)
  Merge branch 'improve_HIP_check'
  Merge branch 
'gitlab/more_careful_highlighting_of_unknown_GP_login_return_values'
  Merge branch 'less_confusing_GP_SAML_output'
  Merge 'gitlab/pass_IDLE_TIMEOUT_to_script'
  add long-sought README.md
  couple other touch-ups to the docs
  show exact GnuTLS/OpenSSL version in --version/--help text
  allow cipher list overrides with OpenSSL as well
  log ciphersuite on every new HTTPS connection, not just AnyConnect 
protocol
  include negotiated [D]TLS version in ciphersuite string for OpenSSL 
(GnuTLS already does this)
  Remove checks for no-longer supported GnuTLS versions
  don't try to describe "DTLS" cipher if protocol's "DTLS" is actually ESP
  add comments on confusing TLS/DTLS cipher description fields
  mention test suite in Getting Started / Building docs
  ignore failure in downloading CSD stub if CSD wrapper is specified
  Merge branch 'origin/ignore_missing_CSD_stub_if_wrapper_specified'
  Don't prevent compilation on GnuTLS <3.5.0, and add comment on 
OpenSSL/GnuTLS difference
  Merge branch 'github_PR_164'
  use run-time version numbers (per dwmw)
  windows read_stdin should strip either "\r\n" or "\n" as line ending 
(#113)
  Merge branch 'windows_read_stdin_line_ending'
  Merge branch 'gnutls_priority_override_option'
  missing defines (IPPROTO_ICMP and ICMP_ECHOREPLY) for Windows
  oNCP: explain likely meaning of long-puzzling 'error 0x08'
  add some clarifications about Pulse vs. NC to the documentation
  Merge branch 'origin/explain_server_0x08'
  remove README.TESTS from Makefile.am
  Merge branch 'upstream/master'
  Run Cisco CSD script as child, not daemonized grandchild
  Update changelog.xml
  add Java wrapper function for setTrojanInterval()
  add OC_PROTO_PERIODIC_TROJAN feature flag
  Merge branch 'periodic_Trojan_touch_up'

David Woodhouse (93):
  Explicitly link libtss2-mu for tss2-esys build
  Use localtime_s where available to fix MS

Re: Pulse connect to workstation

[David Woodhouse]

On Sun, 2020-03-29 at 08:32 -0400, Tim Howard wrote:
> D. My connection attempts (url and IP addresses obscured):
> $ openconnect -C "DSID=aLongStringOfChars" --protocol=pulse
> myWorkplace.server.serv/dana/home/index.cgi# -v --os=win
> Attempting to connect to server 123.123.123.233:443
> Connected to 123.123.123.233:443
> SSL negotiation with myWorkplace.server.serv
> Connected to HTTPS on myWorkplace.server.serv
> Got HTTP response: HTTP/1.1 404 Not Found

Try that without the path; just the server hostname.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Machine keeps dying with OpenConnect

[David Woodhouse]

On Wed, 2020-03-25 at 20:05 +, Chester, Dean wrote:
> Hi, 
> 
> By dying I mean the machine completely locks up and is unresponsive
> to pings or new SSH connections. 
> 
> There version I believe is the latest on Gitlab; I don’t know why he
> hasn’t been installing the version from the Debian repositories. 
> 
> I am unfortunately unable to check the system logs currently as I
> can’t access the system. 

Are you running ./configure as root? If so, it *does* create and delete
an empty network namespace to see if it can use those for testing. But
those really shouldn't affect connectivity.

What is the last output you see from the configure script?

You said, "after he's done with his tunnel we seem to bne unable to
access the machine again via SSH"... but if he's still only running
./configure and hasn't got to the point of even *building* openconnect,
then he hasn't got a tunnel. Am I missing something?


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Does openconnect support IPSec with EAP-MSCHAPv2 authentication?

[David Woodhouse]

On Mon, 2020-03-23 at 18:02 -0700, Daniel Lenski wrote:
> On Mon, Mar 23, 2020 at 4:43 PM dan.m...@gmail.com  wrote:
> > 
> > As much as I would like the share the capture, I'm not really sure I
> > have the liberty of sharing it? As there could be private information
> > contained within it. I know that makes this more difficult for me.

It should be easy enough to edit out usernames and passwords. Any
session key that is obtained through authorisation is going to be tied
to the life of that session so won't be useful any more.

Send it to Daniel and me in private if you prefer.

> One approach is to try to put together an anonymized document that
> describes the protocol abstractly, like I did here for GlobalProtect
> as I was studying it:
> https://github.com/dlenski/openconnect/blob/master/PAN_GlobalProtect_protocol_doc.md
> 
> The good news is that a lot of the information needed to add support
> for Cisco IPSEC is probably right there in the headers of the CSTP
> connection request/response which we already understand very well. Try
> connect to your server with `openconnect --dump -`, and start
> looking for HTTP headers that mention IPSEC or ESP.
>
> It's all plain text at that point, so it should be quite
> straightforward to identify and obfuscate anything that may be
> sensitive (e.g. username, password, cookies, secret values).

Isn't this the IKE-based one that is partly supported by vpnc?


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Openconnect and smartcards

[David Woodhouse]

On Sun, 2020-03-22 at 19:37 +, Nikos Mavrogiannopoulos wrote:
> I'd suggest to use the openconnect-gui windows application as it can
> use smart cards supported in windows natively.
> 
> https://openconnect.github.io/openconnect-gui/

Yeah, that's what Benoît did.

I should probably add support for listing system keys to the
openconnect command line. PKCS#11 too. 


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: [PATCH v2] Add ability to import PKCS12 keys

[David Woodhouse]

On Fri, 2020-03-13 at 12:31 +0100, Grant Williamson wrote:
> With this method I can create a wrapped private key and connect to our vpn.
> 
> However I still need to extract the certificates to connect.

Right. 

> With my original p12(not wrapped) I can connect to our vpn gateway
> without specifying the certificates.
> 
> I am wondering if there is a way to repack the tpm wrapped private key
> and certs into a new p12 file .
>
> i.e.
> create_tpm2_key -w private.pem private-key-tpm-wrapped.pem

Not into a PKCS#12 file but you can put the cert and the TPM-wrapped
key into the same PEM file.

$ cat private-key-tpm-wrapped.pem user_cart.crt > cert-and-key.pem

And perhaps append your ca_cert.crt if that is the one that issued your
user_cert and you want to include it on the wire.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Sudden seg fault on openconnect after system updates

[David Woodhouse]

On Sat, 2020-02-29 at 15:12 -0500, Randall Sindlinger wrote:
> I have been happily using OpenConnect to access my VPN via a smartcard up 
> until this morning.  I
> dropped my linux laptop off with IT for some updates, and I now am suddenly 
> getting seg
> faults.  I've tried troubleshooting a few things with IT to no avail, and am 
> hoping you might have a
> suggestion of what to try.

Can you repeat that in gdb and try to get a backtrace?



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: openconnect and tpm2

[David Woodhouse]

On Tue, 2020-03-03 at 09:02 +0100, Grant Williamson wrote:
> In our use case. We are provided a p12 file.
> We are testing om RHEL 8.
> Where improvement could take place, my thoughts.
> 
> - instructions on how to extract the private key and the certs from
> the p12(see below)

I'm definitely going for the "if it needs documenting, fix it first"
approach on that one.

I don't want to tell users how to convert between different file
formats. I want software just to silently *accept* the sensible file
formats instead.

So this really ends up being a feature request for James: the
create_tpm2_key tool ought to support importing keys from PKCS#12
files.

> - offer openssl_tpm2_engine ibmtss(ibmtss-devel, libibmtss0) packages in epel 
> 8
> - build the openconnect epel package against ibmtss for TPMv2 support.

Those are distro-specific requests; please could you file them in Red
Hat bugzilla and Cc me?

We could do with SoftHSM in EPEL8 too, as the tests currently require
it.

Note that there is an open feature request against the TCG engine to
support wrapping existing keys:
https://github.com/tpm2-software/tpm2-tss-engine/issues/39

> The steps I am using are as follows. Password etc have been removed.
> 
> PKCS="file.p12"
> MY_P12_PASSWORD="MyPassw0rd!!"
> TPM_LOCK_PASSWORD="MyPassw0rd!!"
> VPN_SERVER="myserver.ibm.com"
> #
> openssl pkcs12 -in ${PKCS}  -nocerts -nodes -passin
> pass:${MY_P12_PASSWORD} | openssl rsa -out private.pem
> openssl pkcs12 -in ${PKCS} -clcerts -nokeys -chain -passin
> pass:${MY_P12_PASSWORD} | sed -ne '/-BEGIN CERTIFICATE-/,/-END
> CERTIFICATE-/p' > user_cert.crt
> openssl pkcs12 -in ${PKCS} -cacerts -nokeys -chain -passin
> pass:${MY_P12_PASSWORD} | sed -ne '/-BEGIN CERTIFICATE-/,/-END
> CERTIFICATE-/p' > ca_cert.crt
> #
> create_tpm2_key -w private.pem private-key-tpm-wrapped.pem
> #
> sudo openconnect
> --csd-wrapper=/usr/share/ibm-config-NetworkManager-openconnect/csd.sh
> --sslkey=private-key-tpm-wrapped.pem --certificate=user_cert.crt
> --cafile=ca_cert.crt https://${VPN_SERVER} -v

> We are also using the following csd wrapper.

Hm, is that notably different to the one in trojans/csd-wrapper.sh ? 

I'd also be interested to know if the one in trojans/csd-post.sh (in
git master; it's been updated) works for you.

> On Tue, Mar 3, 2020 at 8:29 AM David Woodhouse  wrote:
> > 
> > On Mon, 2020-03-02 at 18:26 +0100, Grant Williamson wrote:
> > > Thank you. Sorry I intended to reply sooner.
> > 
> > That's good to know; thanks.
> > 
> > Next question: Now you've worked it out, could the documentation be
> > improved in any way? What was missing?
> > 
> > Better still, what should be fixed in the code (or tools/helpers
> > provided) so that we don't *have* to document it?
> > 
> 
> ___
> openconnect-devel mailing list
> openconnect-devel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: openconnect and tpm2

[David Woodhouse]

On Tue, 2020-02-18 at 15:49 +0100, Grant Williamson wrote:
> Hi, looking for guidance on how to use openconnect in conjunction
> with
> a private key stored in the tpm.
> 
> - RHEL 8.1
> - UEFI and Secure Boot are enabled.
> - Upstream packages:-
> tpm2-abrmd-2.3.1-1.el8.x86_64.rpm
> tpm2-abrmd-selinux-2.3.1-2.el8.noarch.rpm
> tpm2-tools-4.1-2.el8.x86_64.rpm
> tpm2-tss-2.3.2-2.el8.x86_64.rpm
> (tpm2_import was not part of what was shipped in el8 tpm-tools)
> - openconnect-8.05-3.el8.x86_64.rpm has been rebuilt with tpm2
> support.
> 
> 
> 1) extract private key
> openssl pkcs12 -in vpn.p12  -nocerts -nodes -passin pass:MYPASSWORD |
> openssl rsa -out private.pem
> 
> 2) Import private key to tpm.
> tpm2_createprimary -C o -c parent.ctx -G rsa2048:null:aes128cfb
> tpm2_evictcontrol -c parent.ctx
> 
> tpm2_import -i private.pem -r private_key.tss -u public_key.tss -Grsa
> -C parent.ctx
> tpm2_load -C parent.ctx -u public_key.tss -r private_key.tss -c
> key.ctx
> tpm2_evictcontrol -c key.ctx
> 
> 3) Using tpm2-asn-packer-master to create TSS2 PRIVATE KEY
> (https://github.com/rpofuk/tpm2-asn-packer/blob/master/README.md).
> Perhaps there is a different/better approach.
> npx @rpofuk/tpm2-asn-packer p 8181 private_key.tss public_key.tss
> out.key
> 
> 4) Use openconnect with "-k out.key" to connect?
> 
> Is this the correct approach, or am I totally off track?

Did you get this working?



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: openconnect and tpm2

[David Woodhouse]

On 18 February 2020 15:49:41 CET, Grant Williamson  wrote:
>Hi, looking for guidance on how to use openconnect in conjunction with
>a private key stored in the tpm.
>
>- RHEL 8.1
>- UEFI and Secure Boot are enabled.
>- Upstream packages:-
>tpm2-abrmd-2.3.1-1.el8.x86_64.rpm
>tpm2-abrmd-selinux-2.3.1-2.el8.noarch.rpm
>tpm2-tools-4.1-2.el8.x86_64.rpm
>tpm2-tss-2.3.2-2.el8.x86_64.rpm
>(tpm2_import was not part of what was shipped in el8 tpm-tools)
>- openconnect-8.05-3.el8.x86_64.rpm has been rebuilt with tpm2 support.
>
>
>1) extract private key
>openssl pkcs12 -in vpn.p12  -nocerts -nodes -passin pass:MYPASSWORD |
>openssl rsa -out private.pem
>
>2) Import private key to tpm.
>tpm2_createprimary -C o -c parent.ctx -G rsa2048:null:aes128cfb
>tpm2_evictcontrol -c parent.ctx
>
>tpm2_import -i private.pem -r private_key.tss -u public_key.tss -Grsa
>-C parent.ctx
>tpm2_load -C parent.ctx -u public_key.tss -r private_key.tss -c key.ctx
>tpm2_evictcontrol -c key.ctx
>
>3) Using tpm2-asn-packer-master to create TSS2 PRIVATE KEY
>(https://github.com/rpofuk/tpm2-asn-packer/blob/master/README.md).
>Perhaps there is a different/better approach.
>npx @rpofuk/tpm2-asn-packer p 8181 private_key.tss public_key.tss
>out.key
>
>4) Use openconnect with "-k out.key" to connect?
>
>Is this the correct approach, or am I totally off track?


Ditch steps 2 and 3, and instead use the "wrap" operation from James 
Bottomley's openssl_tpm2_engine. Not sure if tpm2-tss-engine supports that yet.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Patch to add support to the OpenConnect client to send RFC6750 style bearer tokens during establishment of the TLS tunnel.

[David Woodhouse]

On Wed, 2020-01-22 at 20:05 +, Alan Jowett wrote:
> OpenConnect folks,
> 
> Patch to add support to the OpenConnect client to send RFC6750 style bearer 
> tokens during establishment of the TLS tunnel.
> 
> Background:
> My team is working on a feature to support using OpenID Connect
> tokens (https://openid.net/specs/openid-connect-core-1_0.html) to
> authenticate and authorize clients connecting to an OpenConnect
> server. There are growing list of OpenID Connect providers that this
> should work with, making this change fairly broadly applicable.
> 
> Overall flow would be along the following lines:
> Client authenticates to the OpenID Connect provider based on their
> policy (potentially including MFA or other options) and obtains a
> OIDC token. 
> Client then includes that token in the HTTP header when connecting to
> the OpenConnect server. 
> OpenConnect server verifies claims in the OIDC token and then allows
> or denies the connection. 
> 
> My team is also working on the server side changes, but writing the
> tests would be easier if we can use the stock OpenConnect client.
> 
> Please let me know if there are any questions about this.

Hi Alan, thanks for the patch. In general it looks sensible so far.

A couple of minor tech review points:

Please could you make sure that the new ->proxy_bearer_token and
->bearer_token fields are freed in openconnect_vpninfo_free() in
library.c.

Does this even make sense for proxy auth? Is the 'Proxy-Bearer:' form
actually defined and will it ever be implemented? Not that I have much
objection to the way you've done things if the answer is no; we already
support Basic and NTLM-with-password support *only* for proxies and not
for the real HTTP connection and this would just be the converse.

Moving on to the more high-level review what is the expected user
experience here?

Looking at Figure 1 of RFC6750:

 ++   +---+
 ||--(A)- Authorization Request ->|   Resource|
 ||   | Owner |
 ||<-(B)-- Authorization Grant ---|   |
 ||   +---+
 ||
 ||   +---+
 ||--(C)-- Authorization Grant -->| Authorization |
 | Client |   | Server|
 ||<-(D)- Access Token ---|   |
 ||   +---+
 ||
 ||   +---+
 ||--(E)- Access Token -->|Resource   |
 ||   | Server|
 ||<-(F)--- Protected Resource ---|   |
 ++   +---+

 Figure 1: Abstract Protocol Flow

What you're implementing in OpenConnect is purely part (E), right?
An external wrapper or something is expected to obtain the Access Token
for us, and indeed also to *renew* it when necessary? Or is it a one-
use token?

Shouldn't we be implementing the whole protocol, so OpenConnect can
obtain the token for itself? We already need to extend OpenConnect so
that at least the GUI authentication tools (using libopenconnect) can
spawn a WebView for various types of VPN, and let it run until it wins
a certain cookie or redirects to a certain URL/scheme.

Do we want to use that same mechanism to *obtain* (or renew) the bearer
token?

Even if not, if the bearer token is persistent and just stored
alongside the VPN configuration, we need a way for libopenconnect to
provide it; please either add an API for it in addition to the command-
line option you add in main.c, or let's see if we can work it into the
generic form handling as a specific thing that gets requested.

For example, if we see an 'Authorization: Bearer' challenge and we
*don't* already have a token, we could present the user with a form
asking for the token? You still need a wrapper or something to provide
it, but it fits into the NetworkManager secret storage model without
any changes that way.





smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: speed, CPU

[David Woodhouse]

Let's benchmark with netperf UDP to start with, to eliminate TCP effects and 
packet loss. Test with different packet sizes.

On 30 December 2019 10:48:19 GMT, Nikos Mavrogiannopoulos 
 wrote:
>It wouldn't matter benchmarking it. It will not be significantly
>different. From what you describe the crypto capacity of cpu is at
>least 10-fold what you see on the wire. So the issue is somewhere else.
>
>
>On December 30, 2019 10:08:28 AM UTC, Carles Pina i Estany
> wrote:
>>
>>Hi,
>>
>>On Dec/30/2019, David Woodhouse wrote:
>>> On Sat, 2019-12-28 at 22:53 +0100, Carles Pina i Estany wrote:
>>> > Hi openconnect,
>>> > 
>>> > I have a question regarding CPU usage, network speed and
>>openconnect.
>>> > 
>>> > I'm using openconnect from Debian (Debian package version 8.02-1)
>>> > connecting to a Cisco AnyConnect. I'm using NetworkManager but I'm
>>happy
>>> > to use the command line if this would help.
>>> 
>>> A few months ago we had a similar thread, and some performance
>>> improvements went into the 8.03 release. Please could you update to
>>git
>>> master and try?
>>
>>on Saturday I tried with v8.05. I couldn't see any big improvement.
>>Since then I reverted back to use the Debian package (v8.02-1)
>>integrated with the NetworkManager.
>>
>>> There's also an experimental perfhacks branch:
>>>
>>http://git.infradead.org/users/dwmw2/openconnect.git/shortlog/refs/heads/perfhacks
>>> 
>>> Most of that is for ESP support, not DTLS, but the 'reuse packets
>>> instead of free/malloc' bought us a few percent and I'd like to
>>> eventually fix up all the buffer sizing inconsistencies and merge it
>>> (or just move to using rings).
>>
>>I'll try to test the perfhack branch today.
>>
>>> > I see that openconnect uses about 35 to 40% of CPU (measured with
>>top)
>>> > in my 4 cores laptop. 
>>> > 
>>> > When using openconnect the connection is about 5 to 8 MB/s
>>otherwise
>>> > more than twice this speed.
>>> > 
>>> > The system administrators on the other side don't seem to be aware
>>of
>>> > any speed limitation or throttling.
>>> > 
>>> > The internet connection or even the upload speed to the other side
>>is
>>> > higher if no OpenConnect is used.
>>> > 
>>> > My question is: do you know of any way to make the VPN faster?
>>> > 
>>> > Any experience compiling openconnect (I might try this anyway)
>>instead
>>> > of using the Debian precompiled version? Any parameters that could
>>be
>>> > used, faster cyphering, etc.?
>>> 
>>> You can try forcing it to use different ciphers with the
>>--dtls-ciphers 
>>> option.
>>
>>I haven't succeeded forcing gnutls-cli to do benchmarks for
>>AES-256-CBC.
>>I've tried:
>>gnutls-cli --benchmark-ciphers --priority=PERFORMANCE
>>gnutls-cli --benchmark-ciphers --priority=SECURE256
>>
>>--dtls-ciphers is not an option on my gnutls-cli (version 3.6.7)
>>
>>> Please could you set it running, then use 'perf record -a
>>netperf'
>>> to record the *full* system activity (including kernel and
>>openconnect)
>>> for each of a large upload, and a large download. Use your own
>>existing
>>> benchmark or workload if that's easier than netperf.
>>> 
>>> Let's see where it's actually spending the time, and what we can do
>>> about it.
>>
>>I'll do it.
>>
>>Thanks!
>
>-- 
>Sent from my mobile. Please excuse my brevity.
>
>___
>openconnect-devel mailing list
>openconnect-devel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/openconnect-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: speed, CPU

[David Woodhouse]

On 30 December 2019 10:08:28 GMT, Carles Pina i Estany  wrote:
>
>Hi,
>
>On Dec/30/2019, David Woodhouse wrote:
>> 
>> You can try forcing it to use different ciphers with the
>--dtls-ciphers 
>> option.
>
>I haven't succeeded forcing gnutls-cli to do benchmarks for
>AES-256-CBC.
>I've tried:
>gnutls-cli --benchmark-ciphers --priority=PERFORMANCE
>gnutls-cli --benchmark-ciphers --priority=SECURE256
>
>--dtls-ciphers is not an option on my gnutls-cli (version 3.6.7)

That was for openconnect, sorry.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: speed, CPU

[David Woodhouse]

On Sat, 2019-12-28 at 22:53 +0100, Carles Pina i Estany wrote:
> Hi openconnect,
> 
> I have a question regarding CPU usage, network speed and openconnect.
> 
> I'm using openconnect from Debian (Debian package version 8.02-1)
> connecting to a Cisco AnyConnect. I'm using NetworkManager but I'm happy
> to use the command line if this would help.

A few months ago we had a similar thread, and some performance
improvements went into the 8.03 release. Please could you update to git
master and try?

There's also an experimental perfhacks branch:
http://git.infradead.org/users/dwmw2/openconnect.git/shortlog/refs/heads/perfhacks

Most of that is for ESP support, not DTLS, but the 'reuse packets
instead of free/malloc' bought us a few percent and I'd like to
eventually fix up all the buffer sizing inconsistencies and merge it
(or just move to using rings).

> I see that openconnect uses about 35 to 40% of CPU (measured with top)
> in my 4 cores laptop. 
> 
> When using openconnect the connection is about 5 to 8 MB/s otherwise
> more than twice this speed.
> 
> The system administrators on the other side don't seem to be aware of
> any speed limitation or throttling.
> 
> The internet connection or even the upload speed to the other side is
> higher if no OpenConnect is used.
> 
> My question is: do you know of any way to make the VPN faster?
> 
> Any experience compiling openconnect (I might try this anyway) instead
> of using the Debian precompiled version? Any parameters that could be
> used, faster cyphering, etc.?

You can try forcing it to use different ciphers with the --dtls-ciphers 
option.

Please could you set it running, then use 'perf record -a netperf'
to record the *full* system activity (including kernel and openconnect)
for each of a large upload, and a large download. Use your own existing
benchmark or workload if that's easier than netperf.

Let's see where it's actually spending the time, and what we can do
about it.



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: Pulse Secure 9.1R3 - protocol=pulse - "Bad EAP-TTLS packet"

[David Woodhouse]

On Fri, 2019-12-27 at 19:21 +, David Woodhouse wrote:
> Read 3580 bytes of IF-T/TLS EAP-TTLS record
> < : 00 00 55 97 00 00 00 05 00 00 0d fc 00 00 01 f8 |..U.|
> < 0010: 00 0a 4c 01 01 03 0d e8 15 c0 00 00 0e 35 16 03 |..L..5..|
> 
> 
> From the c0 00 00 0e 35 ... on the second line is the EAP-TTLS. 
> 
> See https://tools.ietf.org/html/rfc5281#section-9.1 — that first byte
> has the L and M bits set indicating that the TLS frame is (entirely
> gratuitously) fragmented. I haven't implemented fragmentation yet as
> I hadn't seen it in the wild and there's no point in it. Should be
> simple enough...

First, somewhat rushed, attempt at
https://gitlab.com/openconnect/openconnect/commits/ttlsfrag

Please let me know if it works.


smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel

Re: VPN seems to connect but fails to get a response from the peer

[David Woodhouse]

On Mon, 2019-12-16 at 15:08 -0500, Adam Allgood wrote:
> Hi again David,
> 
> I am currently in the office where the procedure to connect to the VPN
> is slightly different (because the head end is on the same network as
> the VPN gateway), so I'm going to wait until I'm home again before
> doing the --dump-http-traffic tests. However, after thinking more
> about the problem, I realized something interesting. When on xubuntu
> at home and connecting to the VPN for the first time, I get a warning
> on the command line that the certificate has problems, and I can enter
> 'yes' to add an exception and continue the connection. I never got
> this warning in the crouton chroot. I tried connecting to the VPN in a
> fresh Ubuntu chroot with the --servercert X option, and got the
> following:
> 
> Server certificate verify failed: signer not found
> Server SSL certificate didn't match: sha256:[LALALACANTHEARYOU]
> SSL connection failure: Error in the certificate.

Perhaps the server is in a round-robin DNS and you really are getting
different servers (hence difference certificate fingerprints) every
time. You'd do better to *fix* the certificate problem. Can't you
install the appropriate SSL CA so that they're properly trusted?

> Unlike examples of that option I found on the Internet, openconnect
> did not suggest that I use that fingerprint to connect. Nevertheless,
> I tried connecting with sudo openconnect -v --servercert
> sha256:[LALALACANTHEARYOU] [etc], and saw these lines several times in
> the output:
> 
> SSL negotiation with noaaguestvpn.ncep.noaa.gov
> Server certificate verify failed: signer not found
> Connected to HTTPS on noaaguestvpn.ncep.noaa.gov

Right. If the verification fails, it still reports that but if you have
the *matching* --servercert fingerprint on the command line then it'll
make an exception and allow the connection to continue anyway.

> The SSH connection to the head end seemed successfully made, but
> again, no traffic whatsoever in the tunnel. I wonder if ChromeOS
> upgraded security in v77, and that is doing something to block the
> traffic. Is there a way through openconnect (or in general) to work
> around this?

Or maybe it's something going wrong with the routing setup. Maybe your
*outbound* packets aren't actually reaching the VPN server? Or the
inbound packets on the public network are being firewalled locally and
not reaching openconnect?

Can you get a packet capture on your local network to correlate with a
DTLS send/receive debug log like the ones you showed before? And can
you show the output of 'ip route' before and after connecting?



smime.p7s
Description: S/MIME cryptographic signature
___
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel