WinHttp buffer supplied to the function was too small error should not be exposed #17005

stephentoub · 2016-04-17T15:25:13Z

http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_release_prtest/80/consoleFull

07:27:26      System.Net.Http.Functional.Tests.HttpClientHandler_ServerCertificates_Test.UseCallback_BadCertificate_ExpectedPolicyErrors(url: "https://wrong.host.badssl.com/", expectedErrors: RemoteCertificateNameMismatch) [FAIL]
07:27:26         System.Net.Http.HttpRequestException : An error occurred while sending the request.
07:27:26         ---- System.Net.Http.WinHttpException : A security error occurred
07:27:26         Stack Trace:
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
07:27:26            D:\j\workspace\windows_nt_re---37265eab\src\System.Net.Http\src\System\Net\Http\HttpClient.cs(392,0): at System.Net.Http.HttpClient.<FinishSendAsync>d__58.MoveNext()
07:27:26            --- End of stack trace from previous location where exception was thrown ---
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
07:27:26            D:\j\workspace\windows_nt_re---37265eab\src\System.Net.Http\tests\FunctionalTests\HttpClientHandlerTest.ServerCertificates.cs(174,0): at System.Net.Http.Functional.Tests.HttpClientHandler_ServerCertificates_Test.<UseCallback_BadCertificate_ExpectedPolicyErrors>d__9.MoveNext()
07:27:26            --- End of stack trace from previous location where exception was thrown ---
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
07:27:26            --- End of stack trace from previous location where exception was thrown ---
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
07:27:26            --- End of stack trace from previous location where exception was thrown ---
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
07:27:26            ----- Inner Stack Trace -----
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
07:27:26               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
07:27:26            D:\j\workspace\windows_nt_re---37265eab\src\System.Net.Http.WinHttpHandler\src\System\Net\Http\WinHttpHandler.cs(843,0): at System.Net.Http.WinHttpHandler.<StartRequest>d__102.MoveNext()

The text was updated successfully, but these errors were encountered:

stephentoub · 2016-04-17T15:25:57Z

Also here:
http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_release_prtest/74/console

stephentoub · 2016-04-18T11:57:44Z

Failed again, but this time with a different exception message:
"The buffers supplied to a function was too small"
http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_release_prtest/92/consoleFull

04:25:45      System.Net.Http.Functional.Tests.HttpClientHandler_ServerCertificates_Test.UseCallback_BadCertificate_ExpectedPolicyErrors(url: "https://wrong.host.badssl.com/", expectedErrors: RemoteCertificateNameMismatch) [FAIL]
04:25:45         System.Net.Http.HttpRequestException : An error occurred while sending the request.
04:25:45         ---- System.Net.Http.WinHttpException : The buffers supplied to a function was too small
04:25:45         Stack Trace:
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
04:25:45            D:\j\workspace\windows_nt_re---37265eab\src\System.Net.Http\src\System\Net\Http\HttpClient.cs(392,0): at System.Net.Http.HttpClient.<FinishSendAsync>d__58.MoveNext()
04:25:45            --- End of stack trace from previous location where exception was thrown ---
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
04:25:45            D:\j\workspace\windows_nt_re---37265eab\src\System.Net.Http\tests\FunctionalTests\HttpClientHandlerTest.ServerCertificates.cs(174,0): at System.Net.Http.Functional.Tests.HttpClientHandler_ServerCertificates_Test.<UseCallback_BadCertificate_ExpectedPolicyErrors>d__9.MoveNext()
04:25:45            --- End of stack trace from previous location where exception was thrown ---
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
04:25:45            --- End of stack trace from previous location where exception was thrown ---
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
04:25:45            --- End of stack trace from previous location where exception was thrown ---
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
04:25:45            ----- Inner Stack Trace -----
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
04:25:45               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
04:25:45            D:\j\workspace\windows_nt_re---37265eab\src\System.Net.Http.WinHttpHandler\src\System\Net\Http\WinHttpHandler.cs(843,0): at System.Net.Http.WinHttpHandler.<StartRequest>d__102.MoveNext()

stephentoub · 2016-04-25T11:24:06Z

From https://github.com/dotnet/corefx/issues/8038:

The exception of "The buffers supplied to a function was too small" doesn't seem like something due to just network vagaries.

http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_debug_prtest/408/

stephentoub · 2016-04-26T22:01:26Z

Again:
http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_debug_prtest/517/consoleText

"The buffers supplied to a function was too small"

davidsh · 2016-04-26T22:41:10Z

---- System.Net.Http.WinHttpException : The buffers supplied to a function was too small

That particular WinHTTP error is never supposed to bubble out. It means that we called WinHTTP and didn't give it a buffer big enough to return information. That would mean there is a bug in our code.

We didn't start seeing these errors until we added HttpClientHandler properties to expose server certificate validation callbacks. While this error doesn't repro very often, that is the area of code I'll start looking at.

stephentoub · 2016-05-09T14:58:14Z

Again here:
http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_debug_prtest/1026/consoleText

stephentoub · 2016-05-09T17:40:34Z

Again here:
http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_release_prtest/1025/consoleText

stephentoub · 2016-05-09T17:58:57Z

Again here:
http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_release_prtest/998/

stephentoub · 2016-05-09T18:12:10Z

Again here:
http://dotnet-ci.cloudapp.net/job/dotnet_corefx/job/master/job/windows_nt_release_prtest/1021/consoleText

tmds · 2016-06-15T07:18:50Z

I also occasionally get this error using System.Net.Http 4.1.0 on Windows with a custom ServerCertificateCustomValidationCallback.

jacksontbryan · 2016-11-01T19:33:08Z

This error is happening to me in a production environment. Packet capture shows the error happens during key exchange. The certificate is valid. I am doing no custom validation. When it happens it is intermittent with ~30% of requests failing for approx. hour period of time.

HttpClient client = new HttpClient();
client.BaseAddress = new Uri(baseUri);
client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
var response = await client.PostAsJsonAsync("LabelService.svc/generateLabel", labelRequest);
--exception is blown here while sending the http request
An error occurred while sending the request -- The buffers supplied to a function was too small

davidsh · 2016-11-01T19:54:17Z

Packet capture shows the error happens during key exchange. The certificate is valid. I am doing no custom validation. When it happens it is intermittent with ~30% of requests failing for approx. hour period of time.

Thanks for the updated info. It sounds like this is a problem with the low-level windows WinHTTP component.

Do you have a stack trace for where the error "The buffers supplied to a function was too small" is coming from? It would be useful to catch this bug in a debugger since that is the only way to get actionable information to diagnose.

jacksontbryan · 2016-11-01T20:16:21Z

How would you advise setting up the debugger? This happens once every 2-3 days at seemly random times of day.

Stack:

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
at System.Net.Http.HttpClient.<FinishSendAsync>d__58.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Newgistics.Shipping.Service.Repositories.IntellicoreRepository.<CallIntellicoreApi>d__2.MoveNext() in C:\\Users\\Bjackson\\source\\newgistics.shipping.service\\src\\Newgistics.Shipping.Service\\Repositories\\IntellicoreRepository.cs:line 142
inner exception >>    
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
at System.Net.Http.WinHttpHandler.<StartRequest>d__101.MoveNext()",
"error":"An error occurred while sending the request.
inner exception >> The buffers supplied to a function was too small

[EDIT] Format call stack by @karelz

davidsh · 2016-11-03T18:49:06Z

If the exception is unhandled,then normally your process was crash. If so, you can use "windbg /I" to set up post-mortem debugging. When the process crashes, Windbg will launch automatically and you'll be able to debug and see threads, stack, etc.

davidsh · 2017-02-16T19:19:47Z

Could be a product bug....need more investigation.

clement911 · 2017-02-27T08:39:52Z

I'm encountering these same errors in an azure production environment. I run asp.net core on top of the full .net 4.6.1 so I suspect it's not specific to .net core.
It happens as the code is trying to send an email using the SendGrid nuget package, which internally seems to use HttpClient.
Usually the error is 'A security error occurred' (it happened 5 times so far), but there is also 1 occurrence of 'The buffers supplied to a function was too small'.
Here is the top of the stack:

System.AggregateException: One or more errors occurred. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.Http.WinHttpException: A security error occurred at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Net.Http.WinHttpHandler.<StartRequest>d__103.MoveNext() --- End of inner exception stack trace --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Net.Http.HttpClient.<FinishSendAsync>d__58.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()
at SendGrid.Web.d__7.MoveNext()`

karelz · 2017-02-27T22:40:59Z

@davidsh any reason for moving it to Future?

davidsh · 2017-02-27T22:46:20Z

I believe this is a real product bug. Getting this exception, for example, surfaced "the buffers supplied to a function was too small" should never occur. That particular exception is usually caught internally and we have logic to do the right thing with WinHTTP (which is to resize our buffer and call WinHTTP again).

We haven't seen this a lot, though. So, in terms of prioritizing all the other important 2.0 bugs, we could probably defer it to Future.

karelz · 2017-02-27T23:21:53Z

Thanks! That makes sense, moving back to Future.

karelz · 2017-03-10T19:48:19Z

After re-reading the thread, it actually looks that 2 people hit it in the wild. That's concerning. I think we should look into it in 2.0.

wapxmas · 2017-03-22T16:53:52Z

Also this issue happens to me randomly, along with "WinHttpException: A security error" sometimes, and only if I using https protocol.

germanmarky · 2017-03-27T14:45:38Z

I am as well seeing this error in production. My code is posting a SOAP request to an HTTPS endpoint. The request does have an embedded encoded document, but the specific document that last caused the error was only 1.1MB. The additional data is less than 1K. As with others, another error received is "An error occurred in the secure channel support" on the same code block. The server is using TLS 1.2, AES with 256 bit encryption; DH with 2048 bit exchange.

	Public Function HTTPRequest(PostURL)
		
		Set objHTTP = CreateObject("MSXML2.ServerXMLHttp.6.0")
		
		objHTTP.open "POST", strURLProduction, False
		
		objHTTP.setRequestHeader "Content-Type", "text/xml;charset-UTF-8"
		objHTTP.setRequestHeader "SOAPAction", """"""
		
		objHTTP.send objXMLRequest.xml
		
		HTTPRequest = objHTTP.responseText
		
		Set objHTTP = Nothing
	End Function

germanmarky · 2017-03-27T15:20:35Z

I have implemented the workaround provided as the first solution on StackOverflow to use a MSXML2.XMLHttp.6.0 object instead of MSXML2.ServerXMLHttp.6.0. As this was just implemented, I do not know if this will resolve the error but will post back accordingly.

karelz · 2017-04-18T19:37:04Z

@steveharter can you please try to repro this issue? It will help us triage it. If we don't have repro, it is likely not actionable in 2.0.

germanmarky · 2017-04-18T20:14:40Z

The MSXML2.XMLHttp.6.0 object did not resolve the issue. I have since created and implemented a different module using the endpoint WSDL and a COM-Visible DLL in the customers production environment, so unable to revert or reproduce.

karelz · 2017-04-24T20:44:16Z

@steveharter ping?

steveharter · 2017-04-24T21:02:50Z

I will kick off a test soon and report back tomorrow. A previous mass-run of Http.Functional tests with all ActiveIssue tests disabled was not successful (or trustworthy) due to certain re-enabled tests to cause hangs, thus requiring selective re-enablement of tests going forward.

KristinXie1 · 2017-09-28T02:34:23Z

release/2.0.0 failure

https://mc.dot.net/#/product/netcore/200/source/official~2Fcorefx~2Frelease~2F2.0.0~2F/type/test~2Ffunctional~2Fcli~2F/build/20170927.01/workItem/System.Net.Http.Functional.Tests/analysis/xunit/System.Net.Http.Functional.Tests.HttpClientHandler_DangerousAcceptAllCertificatesValidator_Test~2FInvalidCertificateServers_CertificateValidationDisabled_Succeeds(url:%20%5C%22https:~2F~2Fwrong.host.badss...

The test System.Net.Http.Functional.Tests.HttpClientHandler_DangerousAcceptAllCertificatesValidator_Test/InvalidCertificateServers_CertificateValidationDisabled_Succeeds(url: \"https://wrong.host.badss... has failed.

System.Net.Http.HttpRequestException : An error occurred while sending the request.\r
    ---- System.Net.Http.WinHttpException : The buffers supplied to a function was too small

        Stack Trace:

           at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Net.Http.HttpClient.<FinishSendAsyncBuffered>d__58.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Net.Http.Functional.Tests.HttpClientHandler_DangerousAcceptAllCertificatesValidator_Test.<InvalidCertificateServers_CertificateValidationDisabled_Succeeds>d__3.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
    ----- Inner Stack Trace -----
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Threading.Tasks.RendezvousAwaitable`1.GetResult()
       at System.Net.Http.WinHttpHandler.<StartRequest>d__105.MoveNext()

Build : 2.0.0 - 20170927.01 (Core Tests)
Failing configurations:

Windows.81.Amd64-x86
- Release

Porting the same logic from master branch to disable these tests on systems that don't have the fix to SCHANNEL regarding DHE cipher suites. Addresses #23822

karelz · 2018-01-17T22:24:02Z

Triage: We need to disable the test only on older OS's (Win7, Win8.1, Win10 before build - see above https://github.com/dotnet/corefx/issues/7812#issuecomment-313154522).
@pjanotti can you please help with this one?

The root cause issue was already fixed in Windows but old versions still hit this issue. This change makes the failing test to ignore the known issue on these old Windows versions. Fixes #7812 (just so GH closes the issue at merge time, the actual issue was fixed in Windows).

karelz · 2018-01-19T18:55:35Z

@pjanotti there is still one test disabled against this bug:
https://github.com/dotnet/corefx/blob/0fd3d2c5bcb1a83e7ebd8025e4810e11e231ce03/src/System.Net.Security/tests/FunctionalTests/SslStreamSystemDefaultsTest.cs#L34

Is that on purpose? Can it be re-enabled? Or do we need to track more work? (Maybe there was mix up of multiple problem here?)

pjanotti · 2018-01-19T19:04:43Z

Somehow I missed that one... re-opening...

pjanotti · 2018-01-19T21:09:18Z

/cc @Priya91 @wfurt @davidsh (area owners)
When trying to re-enable https://github.com/dotnet/corefx/blob/0fd3d2c5bcb1a83e7ebd8025e4810e11e231ce03/src/System.Net.Security/tests/FunctionalTests/SslStreamSystemDefaultsTest.cs#L46

The test fails when

        [InlineData(null, SslProtocols.Tls11)]
        [InlineData(SslProtocols.Tls11, null)]

Since _clientStream.HashAlgorithm becomes Sha1 which is not expected by:

            if (PlatformDetection.IsWindows && PlatformDetection.WindowsVersion >= 10)
            {
                Assert.True(_clientStream.HashAlgorithm == HashAlgorithmType.Sha256 ||
                            _clientStream.HashAlgorithm == HashAlgorithmType.Sha384 ||
                            _clientStream.HashAlgorithm == HashAlgorithmType.Sha512);
            }

Is this a product bug? The test implies that we shouldn't be going back to Sha1.

Priya91 · 2018-01-19T21:41:33Z

@bartonjs Do you know if the above test is valid, that on Windows 10, the hashalgorithm cannot be Sha1?

bartonjs · 2018-01-19T21:47:52Z

That claim probably holds when the protocol is 1.2; but 1.1 didn't have any SHA256/SHA384/SHA512 options.

If you look at all of the entries marked as "TLS 1.1" on https://msdn.microsoft.com/en-us/library/windows/desktop/mt808163(v=vs.85).aspx you'll see that they just say "SHA" (except for the couple that say "MD5").

Protected against error in old versions of Windows and updated assert to include the case when hash algorithm can be Sha1. Fixes #7812 (actual fix done on Windows, just re-enabling affected tests with proper guard)

* Enable ClientAndServer_OneOrBothUseDefault_Ok test Protected against error in old versions of Windows and updated assert to include the case when hash algorithm can be Sha1. Fixes #7812 (actual fix done on Windows, just re-enabling affected tests with proper guard) * Waiting for tasks w/ test cfg wrapper * Skip test on Windows 7 On Windows 7 only Tls is supported OOB, so only few test cases can actually pass. Others fail with: ``` System.Security.Authentication.AuthenticationException : A call to SSPI failed, see inner exception. ---- System.ComponentModel.Win32Exception : The client and server cannot communicate, because they do not possess a common algorithm ```

pvasek · 2018-01-29T11:05:00Z

@davidsh Is there any KB for that issue? I am curious about updates for older systems.

davidsh · 2018-01-29T18:16:54Z

This issue was fixed in Windows 10 releases:

In terms of which Windows 10 / Windows Server 2016 build numbers have the fix:
This was fixed in 10.0.14393. That means it is fixed in Windows Server 2016 since the RTM release of that server SKU was build 14393. For Windows 10, it means "Windows 10 Version 1607 (Anniversary Update)" which is build 14393. See: https://en.wikipedia.org/wiki/Windows_10_version_history

I am not aware if there are KB articles directly addressing this.

Our CI builds have intermittent failures in our online tests, e.g. with the message "A provided buffer was too small". This is not a programming error in libgit2 but rather an error in the SChannel component of Windows. Under certain circumstances involving Diffie-Hellman key exchange, SChannel is unable to correctly handle input from the server. This bug has already been fixed in recent patches for Windows 10 and Windows Server 2016, but they are not yet available for AppVeyor. Manually pamper over that issue by disabling all ciphersuites using DHE via the registry. While this disables more ciphers than necessary, we really don't care for that at all but just want to avoid build failures due to that bug. See [1], [2] or [3] for additional information. 1: aws/aws-sdk-cpp#671 2: https://github.com/dotnet/corefx/issues/7812 3: https://support.microsoft.com/en-us/help/2992611/ms14-066-vulnerability-in-schannel-could-allow-remote-code-execution-n

Our CI builds have intermittent failures in our online tests, e.g. with the message "A provided buffer was too small". This is not a programming error in libgit2 but rather an error in the SChannel component of Windows. Under certain circumstances involving Diffie-Hellman key exchange, SChannel is unable to correctly handle input from the server. This bug has already been fixed in recent patches for Windows 10 and Windows Server 2016, but they are not yet available for AppVeyor. Manually pamper over that issue by disabling all ciphersuites using DHE via the registry. While this disables more ciphers than necessary, we really don't care for that at all but just want to avoid build failures due to that bug. See [1], [2] or [3] for additional information. 1: aws/aws-sdk-cpp#671 2: https://github.com/dotnet/corefx/issues/7812 3: https://support.microsoft.com/en-us/help/2992611/ms14-066-vulnerability-in-schannel-could-allow-remote-code-execution-n (cherry picked from commit 723e1e9)

nickjags · 2018-10-26T14:34:25Z

We had issues related to our https .NET application (F5 BIGIP Load balanced) where it used to break intermittently for 1 hour window. and then started working again by itself after an hour. The server event logs showed "Schannel Error - The TLS protocol defined fatal alert code is 40, while the application logs showed the error "HttpRequestException: The buffers supplied to a function was too small ". The issue was due to what is mentioned in the BIGIP F5 article https://support.f5.com/csp/article/K40424522 and was resolved when we disabled the DHE/EDH cypher on the impacted application VIP.

MgSam · 2020-10-26T20:00:51Z

We're seeing this today on a production server Windows Server 2012 R2, .NET Core 3.1.

My understanding based on reading this thread was that it was supposed to be have been fixed in .NET Core 2.1?

Is the SSL workaround still the best way to handle this?

stephentoub assigned davidsh Apr 17, 2016

davidsh removed their assignment Nov 18, 2016

Priya91 changed the title ~~HttpClientHandler_ServerCertificates_Test.UseCallback_BadCertificate_ExpectedPolicyErrors failed in CI on Windows~~ WinHttp buffer supplied to the function was too small error should not be exposed Mar 2, 2017

Petermarcu referenced this issue in dotnet/corefx Oct 30, 2017

Disable System.Net.Http tests due to #7812 (#24455)

f095edc

Porting the same logic from master branch to disable these tests on systems that don't have the fix to SCHANNEL regarding DHE cipher suites. Addresses #23822

karelz assigned pjanotti and unassigned davidsh Jan 17, 2018

pjanotti closed this as completed in dotnet/corefx#26428 Jan 19, 2018

pjanotti reopened this Jan 19, 2018

pjanotti closed this as completed in dotnet/corefx#26463 Jan 20, 2018

nickjags unassigned pjanotti Oct 26, 2018

msftgits transferred this issue from dotnet/corefx Jan 31, 2020

msftgits added this to the 2.1.0 milestone Jan 31, 2020

ghost locked as resolved and limited conversation to collaborators Jan 1, 2021

WinHttp buffer supplied to the function was too small error should not be exposed #17005

WinHttp buffer supplied to the function was too small error should not be exposed #17005

Comments

stephentoub commented Apr 17, 2016

stephentoub commented Apr 17, 2016

stephentoub commented Apr 18, 2016

stephentoub commented Apr 25, 2016

stephentoub commented Apr 26, 2016

davidsh commented Apr 26, 2016

stephentoub commented May 9, 2016

stephentoub commented May 9, 2016

stephentoub commented May 9, 2016

stephentoub commented May 9, 2016

tmds commented Jun 15, 2016 • edited Loading

jacksontbryan commented Nov 1, 2016

davidsh commented Nov 1, 2016

jacksontbryan commented Nov 1, 2016 • edited by karelz Loading

davidsh commented Nov 3, 2016

davidsh commented Feb 16, 2017

clement911 commented Feb 27, 2017

karelz commented Feb 27, 2017

davidsh commented Feb 27, 2017 • edited Loading

karelz commented Feb 27, 2017

karelz commented Mar 10, 2017

wapxmas commented Mar 22, 2017 • edited Loading

germanmarky commented Mar 27, 2017 • edited by karelz Loading

germanmarky commented Mar 27, 2017

karelz commented Apr 18, 2017

germanmarky commented Apr 18, 2017

karelz commented Apr 24, 2017

steveharter commented Apr 24, 2017 • edited Loading

KristinXie1 commented Sep 28, 2017 • edited by karelz Loading

karelz commented Jan 17, 2018 • edited Loading

karelz commented Jan 19, 2018 • edited Loading

pjanotti commented Jan 19, 2018

pjanotti commented Jan 19, 2018

Priya91 commented Jan 19, 2018

bartonjs commented Jan 19, 2018

pvasek commented Jan 29, 2018

davidsh commented Jan 29, 2018

nickjags commented Oct 26, 2018 • edited Loading

MgSam commented Oct 26, 2020 • edited Loading

tmds commented Jun 15, 2016 •

edited

Loading

jacksontbryan commented Nov 1, 2016 •

edited by karelz

Loading

davidsh commented Feb 27, 2017 •

edited

Loading

wapxmas commented Mar 22, 2017 •

edited

Loading

germanmarky commented Mar 27, 2017 •

edited by karelz

Loading

steveharter commented Apr 24, 2017 •

edited

Loading

KristinXie1 commented Sep 28, 2017 •

edited by karelz

Loading

karelz commented Jan 17, 2018 •

edited

Loading

karelz commented Jan 19, 2018 •

edited

Loading

nickjags commented Oct 26, 2018 •

edited

Loading

MgSam commented Oct 26, 2020 •

edited

Loading