-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update SSL tests to deal better with disabled protocols #65120
Conversation
Tagging subscribers to this area: @dotnet/ncl, @vcsjones Issue Detailscontributes to #65098 I will keep the issue open as I feel we should do more exploration and perhaps PlatformDetection tweaks but I did not want to keep main with failing tests. It is also big question to me what would happen if somebody would disable Tls 1.0 and 1.1 on Linux - in way similar to the Azure image configuration.
|
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
test failures are related. Seems like Linux behaves different way, I'll need to make more updates. |
src/libraries/System.Net.Security/tests/FunctionalTests/ClientAsyncAuthenticateTest.cs
Outdated
Show resolved
Hide resolved
|
||
if ((serverProtocol & SslProtocolSupport.SupportedSslProtocols) == 0) | ||
{ | ||
throw new SkipTestException($"None of '{serverProtocol}' requested versions is available"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind the check, but this shouldn't happen should it? Based on the checks in ProtocolMismatchData
. I'm just trying to make sure I understand this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two parts. The one side is guarded but the other is not. So we would not start server on unsupported version but the client can be anything.
We could possibly change that as well. We have tests where the client part is set of allowed protocols and the test would work as far as any of them is available. It is also somewhat more complicated as the protocol may not be supported by the SSL stack but on this case the server does support but it is disabled in registry. And when it does, some of the call fail with WIn32Exception. There is also some variations I run into on Linux: The protocols may not be disabled explicitly but all the ciphers suites used by it may - as deemed weak. In that case the API calls succeed but then the negotiation fails with protocol mismatch.
Perhaps we should construct this automatically e.g. create disjoined sets from all supported protocols.
src/libraries/System.Net.Security/tests/FunctionalTests/TestConfiguration.cs
Outdated
Show resolved
Hide resolved
Assert.IsType<PlatformNotSupportedException>(ae.InnerException); | ||
if (!OperatingSystem.IsWindows()) | ||
{ | ||
Assert.IsType<PlatformNotSupportedException>(ae.InnerException); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this correlates anyhow with the new check for IsWindows10Version20348OrGreater
in s_supportsNullEncryption
?
If so, should it be the same check here as well? Or is this unrelated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not necessarily. I'm not sure where the expected PlatformNotSupportedException
would come from. On windows when the protocol are disabled in registry we get API failure. I mostly disabled this to pass the test so we have time to investigate. My intention is to stabilize the tests but leave #65098 open so we can investigate more.
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
src/libraries/System.Net.Security/tests/FunctionalTests/ServerAsyncAuthenticateTest.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks okay, but I suggest small verbosity fixes.
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
there is no failure in System.Net.Security. Failures looks like infrastructure or text processing issues. |
contributes to #65098
With #64966 I focused on hanging and duration off the run. Since other changes were still in flux I did not get clean test run. This will hopefully produce it on all platforms.
I will keep the issue open as I feel we should do more exploration and perhaps PlatformDetection tweaks but I did not want to keep main with failing tests.
It is also big question to me what would happen if somebody would disable Tls 1.0 and 1.1 on Linux - in way similar to the Azure image configuration.