Open omajid opened 2 years ago
Tagging subscribers to this area: @dotnet/ncl See info in area-owners.md if you want to be subscribed.
Author: | omajid |
---|---|
Assignees: | - |
Labels: | `area-System.Net.Http`, `untriaged` |
Milestone: | - |
Triage: Likely related to new image Ubuntu 22.04 (we do not have a queue yet). Seems to fail reliably. We should investigate.
do you know @omajid if the image has the gss-ntlm package? Generally, I would think the OpenSSL is independent from Kerberos and GSS.
Actually, you may be right about OpenSSL. It seems like md4
is no longer available from crypto
helixbot@9d96aeaca4ba:/$ openssl md4
Error setting digest
4037123E367F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (MD4 : 88), Properties ()
4037123E367F0000:error:03000086:digital envelope routines:evp_md_init_internal:initialization error:../crypto/evp/digest.c:237:
and
https://github.com/gssapi/gss-ntlmssp/blob/734e522c14a9821d7c03f2ce1691706d3d8131ad/src/crypto.c#L149-L153
While the gss-ntlmssp
builds it is probably completely useless. (something to report ditto vendors..?)
For now, I think we detect presence of the page and we would skip tests as needed. Short term fix may be removing the ntlm package from docker image. That of course leaves NTLM auth broken.
The options would be to report/fix the package so it works with OpenSSL 3.x (e.g. add private fall-back implementation of md4) or switch to managed implementation #66879
cc: @filipnavara @bartonjs
Let's report upstream and see. Long term I am keen on making the Managed NTLM an option either through an app context switch, or as a fallback if gss-ntlmssp is not installed.
Should we flag this as part of Ubuntu 22.04 support? Looking at https://github.com/dotnet/core/issues/7038 it seems like everything is 100% functional?
I'm not sure. This looks like distribution bug to me @omajid as the package they provide does not work.
It seems like md4 is no longer available from crypto
You need to load the legacy provider for that to work in OpenSSL 3. You can either do that in openssl.cnf
, or from the command line, this should work:
echo hi | openssl md4 -provider legacy
However for the runtime, we explicitly load the "legacy" provider, so MD4 should be available.
One way to tell is to change openssl.cnf
to have the following provider_sect
:
[provider_sect]
default = default_sect
legacy = legacy_sect
[default_sect]
activate = 1
[legacy_sect]
activate = 1
However for the runtime, we explicitly load the "legacy" provider, so MD4 should be available.
...but only after you use some crypto that initializes the OpenSSL native shim, right?
Ah, you're right. I thought we always loaded the legacy provider, but we only do it when you use an algorithm that is in the legacy provider:
Changing the openssl.cnf
to load the legacy provider however would work, assuming the problem is the lack of the legacy provider's availability.
This was fixed in gss-ntlm package. It is up to Ubuntu to pick up the fix. Big thanks to @simo5 who did the fix.
@wfurt why did you send it back to triage? If it is external (and addressed there already), I would recommend to close it with details which version of library is needed to make it work.
We can (should?) improve platform detection and skip the tests as needed instead of failing. This will bite us once #67345 is merged. We may also choose to solve it via manage NTLM.
Triage: Platform detection needs to be improved to handle the case as well.
Note: This will be addressed once we have managed NTLM implementation - but there is no guarantee when it will happen.
This isn't just a test-related issue. I just upgraded a system from Ubuntu 20.04 to Ubuntu 22.04 and a .NET 6 application could no longer use NTLM auth until I applied the workaround mentioned in https://github.com/dotnet/runtime/issues/67353#issuecomment-1085003764.
Should this be documented somewhere as a compatibility issue for developers / end-users?
We could but it is really difficult to trace and keep in sync all Linux distributions and versions. We could add note that the functionality depends on underlying OS capabilities. But as I mentioned above it is really up to Ubuntu to pick up the package fixes. Perhaps you can open issue with them.
One way to tell is to change
openssl.cnf
to have the followingprovider_sect
:[provider_sect] default = default_sect legacy = legacy_sect [default_sect] activate = 1 [legacy_sect] activate = 1
This helped. Thanks! :)
Hi,
We are planning to upgrade our .Net core MVC application from .Net 6 to .Net 8 version. It is written in C#. To prepare for that upgrade we first upgraded from ubuntu 20.04 to ubuntu 22.04. We target ubuntu 22.04 version jammy tag with amd64 architecture.
This is our base image in the Docker file and the following line updates our package list.
FROM artifactory.xyz.com/dockerhub-microsoft/dotnet/aspnet:6.0-jammy-amd64 AS base
&& apt-get update && apt-get install -y --no-install-recommends curl gss-ntlmssp tzdata \
When our application tries to authenticate and open SSRS reports we get "GSSAPI operation failed with error - Unspecified GSS failure. Minor code may provide more information (Crypto routine failure)"
We were previously using focal base image in 20.04 version and was able to render SSRS reports. Did something change with gss-ntlmssp package in 22.04 version? I was reading some other posts where it says this issue is related to incompatibilities between OpenSSL 3.0 and the older cryptographic algorithms involved in NTLM authentication. Any thoughts on how to fix this issue? Appreciate your kind response.
Any thoughts on how to fix this issue?
One of the fixes is literally the comment right above yours (enable the legacy crypto in OpenSSL). The other one is to get newer version of the gss-ntlmssp package or compile it yourself.
One of the fixes is literally the comment right above yours (enable the legacy crypto in OpenSSL). The other one is to get newer version of the gss-ntlmssp package or compile it yourself.
there seems to be updated binaries in never Ubuntu. You may be able to get binaries from there with little bit of trickery (but I did not test it)
and in .NET 8 they could force the managed implementation, right @filipnavara if all they need is NTLM?
https://packages.ubuntu.com/search?keywords=gss-ntlmssp you want the 1.2.xxx version @SaravanakumBalach
Thanks @wfurt . I looked at it but it appears like 1.2.xxx version is available only with ubuntu 23.x and above. But we are targeting ubuntu 22.04 which only supports GSSAPI 0.7.0 version. @filipnavara How can I enable the legacy crypto in OpenSSL? Any other thoughts pls?
right, but
curl -LO http://mirrors.kernel.org/ubuntu/pool/universe/g/gss-ntlmssp/gss-ntlmssp_1.2.0-1_amd64.deb
sudo dpkg -i gss-ntlmssp_1.2.0-1_amd64.deb
works because all dependencies are met
furt@ubu22:/tmp$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
Description
Running runtime tests on Ubuntu 22.04 (which adds OpenSSL 3.0 resulting in a number of changes under the hood), leads to a bunch of tests failing: https://dev.azure.com/dnceng/public/_build/results?buildId=1690650&view=ms.vss-test-web.build-test-results-tab&runId=46193442&resultId=189361&paneView=dotnet-dnceng.dnceng-anon-build-release-tasks.helix-anon-test-information-tab
Some examples:
Reproduction Steps
From helix:
Expected behavior
All tests pass
Actual behavior
Tests fail with GSS exceptions.
Regression?
Yes, the tests pass on older versions of Ubuntu currently running in CI
Known Workarounds
No response
Configuration
5a0564b01442f8ea9247e27c4fab85ee0d457265
Other information
No response