BackBlaze connection: “Failed to connect: The underlying connection was closed: An unexpected error occurred on a receive.”

Attempting to connect during backup set-up garners me the error message,

Failed to connect: The underlying connection was closed: An unexpected error occurred on a receive.

After a very long (10+ min) wait time.

Duplicati was working just fine until its DB crapped out in mid-December and I tried to do a rebuild. Rebuild would never finish, so I eventually killed the rebuild and deleted the backup (including files on BackBlaze). When I tried to re-create the backup, I ran into this error.

Duplicati is running in Service mode. Nothing has changed on the server aside from Windows Updates. Server is a Windows Server 2012 Standard system with two Intel Xeon X5355 CPUs and 16Gb of RAM. I have confirmed that all settings for BackBlaze are correct (I have a second system running the same credentials, I updated its backup with the same credentials but different bucket and connected successfully).

The Log page gave me this:

• Jan 24, 2019 12:29 AM: Request for http://localhost:8200/api/v1/remoteoperation/test gave error

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. —> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc)
at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential)
at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte& thumbPrint)
at System.Net.Security.SecureChannel.GenerateToken(Byte input, Int32 offset, Int32 count, Byte& output)
at System.Net.Security.SecureChannel.NextMessage(Byte incoming, Int32 offset, Int32 count)
at System.Net.Security.SslState.StartSendBlob(Byte incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
at System.Net.TlsStream.BeginWrite(Byte buffer, Int32 offset, Int32 size, AsyncCallback asyncCallback, Object asyncState)
at System.Net.ConnectStream.WriteHeaders(Boolean async)
— End of inner exception stack trace —
at Duplicati.Library.Utility.AsyncHttpRequest.AsyncWrapper.GetResponseOrStream()
at Duplicati.Library.Utility.AsyncHttpRequest.GetResponse()
at Duplicati.Library.Backend.Backblaze.B2AuthHelper.get_Config()
at Duplicati.Library.Backend.Backblaze.B2.List()
at Duplicati.Library.Interface.BackendExtensions.TestList(IBackend backend)
at Duplicati.Server.WebServer.RESTMethods.RemoteOperation.TestConnection(String url, RequestInfo info)
at Duplicati.Server.WebServer.RESTHandler.DoProcess(RequestInfo info, String method, String module, String key)

Suggestions?

Sometimes odd SSL/TLS failures can be improved with –allowed-ssl-versions=Tls12 in case Windows’ default operation is not cooperating. Duplicati does not do its own SSL/TLS, and the message seems to reflect Windows not offering any encryption algorithm acceptable to server. Maybe it’s on an old version.

C:\Program Files\Duplicati 2>Duplicati.CommandLine.exe help allowed-ssl-versions
  --allowed-ssl-versions (Flags): Sets allowed SSL versions
    This option changes the default SSL versions allowed. This is an advanced
    option and should only be used if you want to enhance security or work
    around an issue with a particular SSL protocol.
    * values: Ssl3, Tls, Tls11, Tls12, SystemDefault
    * default value: SystemDefault,Ssl3,Tls

C:\Program Files\Duplicati 2>

If you’re interested in what happens to that value, it goes to .NET Framework, as described on this page.
Cipher negotiation is easy to see if you’re willing and able to run Wireshark on port 443, to open packets. The problem the message refers to would probably mean Client Hello had few Cipher Suites (I have 21), and instead of Server Hello picking one of them, it refuses them all so you get a failure (not Server Hello).

SSL Introduction with Sample Transaction and Packet Exchange

Alternatively, Internet Explorer uses Windows for its SSL/TLS use too, however its version configuration uses a different interface which I think is per-user, or at least its checkboxes seem to set independently.
Still, it’d be worth having IE get https://www.backblaze.com, to view right-click → Properties encryption.

image