I’m one of the upstream OpenConnect developers. Thanks for bringing this to our attention. This is one of a seemingly-endless stream of issues (e.g. https://gitlab.com/openconnect/openconnect/-/issues/211) that OpenConnect users have encountered as a result of distros’ recent mania for enforcing “minimum TLS security levels” on a system-wide level.
It’s a frustrating situation for OpenConnect because users often have to connect to ancient unpatched VPNs to do their work, can’t do anything about the server configuration, and have no real expectation of “security” anyway.
> My feeling is that curl should set the SSL option when -k is used. openconnect itself sets this option already, it was fixed in commit c8dcf10
If you replace the cURL invocation in the CSD/Trojan script with…
I’m one of the upstream OpenConnect developers. Thanks for bringing this to our attention. This is one of a seemingly-endless stream of issues (e.g. https:/ /gitlab. com/openconnect /openconnect/ -/issues/ 211) that OpenConnect users have encountered as a result of distros’ recent mania for enforcing “minimum TLS security levels” on a system-wide level.
It’s a frustrating situation for OpenConnect because users often have to connect to ancient unpatched VPNs to do their work, can’t do anything about the server configuration, and have no real expectation of “security” anyway.
> My feeling is that curl should set the SSL option when -k is used. openconnect itself sets this option already, it was fixed in commit c8dcf10
If you replace the cURL invocation in the CSD/Trojan script with…
``` CONF=/dev/ null curl <usual options>
OPENSSL_
```
… does this make it work? (For some hints about how/why it should work, start with https:/ /gitlab. com/openconnect /openconnect/ -/commit/ 7e862f2f0352409 357fa7a4762481f de49909eb8# 406e031b8824ea2 6ae0bf4d7579a1d 89e3fb5906)