Error: SecureChannelFailure (The authentication or decryption has failed.)

Hello,

I’m using duplicati 2.0.4.23_beta_2019-07-14 within a Jail running on FreeNas (based on FreeBSD).
I’m doing the backup into JottaCloud since more than 1 year in unchanged environment.
The last successful backup was on Monday. But since Tuesday I get the error message within the topic and the log contains the following.

I tested a restore via a restore of one file within a fresh Windows instalation of duplicati that worked. So it’s no general issue with duplicati or JottaCloud.

What could be the issue and how can I solve it.

/Oliver

System.Net.WebException: Error: SecureChannelFailure (The authentication or decryption has failed.) ---> System.IO.IOException: The authentication or decryption has failed. ---> System.IO.IOException: The authentication or decryption has failed. ---> Mono.Security.Protocol.Tls.TlsException: The authentication or decryption has failed.
  at Mono.Security.Protocol.Tls.RecordProtocol.EndReceiveRecord (System.IAsyncResult asyncResult) [0x00037] in <fb76ee468de246ca98b18301a125c185>:0 
  at Mono.Security.Protocol.Tls.SslClientStream.SafeEndReceiveRecord (System.IAsyncResult ar, System.Boolean ignoreEmpty) [0x00000] in <fb76ee468de246ca98b18301a125c185>:0 
  at Mono.Security.Protocol.Tls.SslClientStream.NegotiateAsyncWorker (System.IAsyncResult result) [0x00071] in <fb76ee468de246ca98b18301a125c185>:0 
   --- End of inner exception stack trace ---
  at Mono.Security.Protocol.Tls.SslClientStream.EndNegotiateHandshake (System.IAsyncResult result) [0x00032] in <fb76ee468de246ca98b18301a125c185>:0 
  at Mono.Security.Protocol.Tls.SslStreamBase.AsyncHandshakeCallback (System.IAsyncResult asyncResult) [0x0000c] in <fb76ee468de246ca98b18301a125c185>:0 
   --- End of inner exception stack trace ---
  at Mono.Security.Protocol.Tls.SslStreamBase.EndRead (System.IAsyncResult asyncResult) [0x0004b] in <fb76ee468de246ca98b18301a125c185>:0 
  at Mono.Net.Security.Private.LegacySslStream.EndAuthenticateAsClient (System.IAsyncResult asyncResult) [0x0000e] in <cc62094645e2448f88c8135e6f498de3>:0 
  at Mono.Net.Security.Private.LegacySslStream.AuthenticateAsClient (System.String targetHost, System.Security.Cryptography.X509Certificates.X509CertificateCollection clientCertificates, System.Security.Authentication.SslProtocols enabledSslProtocols, System.Boolean checkCertificateRevocation) [0x0000e] in <cc62094645e2448f88c8135e6f498de3>:0 
  at Mono.Net.Security.MonoTlsStream.CreateStream (System.Byte[] buffer) [0x0007b] in <cc62094645e2448f88c8135e6f498de3>:0 
  at System.Net.WebConnection.CreateStream (System.Net.HttpWebRequest request) [0x00073] in <cc62094645e2448f88c8135e6f498de3>:0 
   --- End of inner exception stack trace ---
  at Duplicati.Library.Main.BackendManager.List () [0x00049] in <e2da9713f0974e76879d9f9aa7ce0e36>:0 
  at Duplicati.Library.Main.Operation.FilelistProcessor.RemoteListAnalysis (Duplicati.Library.Main.BackendManager backend, Duplicati.Library.Main.Options options, Duplicati.Library.Main.Database.LocalDatabase database, Duplicati.Library.Main.IBackendWriter log, System.String protectedfile) [0x0000d] in <e2da9713f0974e76879d9f9aa7ce0e36>:0 
  at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList (Duplicati.Library.Main.BackendManager backend, Duplicati.Library.Main.Options options, Duplicati.Library.Main.Database.LocalDatabase database, Duplicati.Library.Main.IBackendWriter log, System.String protectedfile) [0x00000] in <e2da9713f0974e76879d9f9aa7ce0e36>:0 
  at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify (Duplicati.Library.Main.BackendManager backend, System.String protectedfile) [0x0010d] in <e2da9713f0974e76879d9f9aa7ce0e36>:0 
  at Duplicati.Library.Main.Operation.BackupHandler+<RunAsync>d__19.MoveNext () [0x01031] in <e2da9713f0974e76879d9f9aa7ce0e36>:0 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <c5bcd0ec45b240acb20cfcfa5eee2246>:0 
  at CoCoL.ChannelExtensions.WaitForTaskOrThrow (System.Threading.Tasks.Task task) [0x00050] in <6973ce2780de4b28aaa2c5ffc59993b1>:0 
  at Duplicati.Library.Main.Operation.BackupHandler.Run (System.String[] sources, Duplicati.Library.Utility.IFilter filter) [0x00008] in <e2da9713f0974e76879d9f9aa7ce0e36>:0 
  at Duplicati.Library.Main.Controller+<>c__DisplayClass13_0.<Backup>b__0 (Duplicati.Library.Main.BackupResults result) [0x00035] in <e2da9713f0974e76879d9f9aa7ce0e36>:0 
  at Duplicati.Library.Main.Controller.RunAction[T] (T result, System.String[]& paths, Duplicati.Library.Utility.IFilter& filter, System.Action`1[T] method) [0x00271] in <e2da9713f0974e76879d9f9aa7ce0e36>:0 
  at Duplicati.Library.Main.Controller.Backup (System.String[] inputsources, Duplicati.Library.Utility.IFilter filter) [0x00068] in <e2da9713f0974e76879d9f9aa7ce0e36>:0 
  at Duplicati.Server.Runner.Run (Duplicati.Server.Runner+IRunnerData data, System.Boolean fromQueue) [0x00307] in <be73c239d77d4180b5147067144fc237>:0

Error: SecureChannelFailure (The authentication or decryption has failed.) #2672 has some guesses.

Unless you used –no-local-blocks, the restore might have gotten all its data from its original source file unless the fresh Windows didn’t have it. Another possibility is I get TLS issues on only the upload URL.

It seems that jotta cloud has stopped to accept TLS 1.0 connections.
And my mono instalation only supports TLS 1.0 but not the required version TLS 1.2.

I have testes with the TLS connection

works:
mono TlsTest.exe  https://google.com
fails
mono TlsTest.exe  https://jottacloud.com
mono TlsTest.exe  https://heise.de

The mono version is 5.10 so it should support TLS 1.2 but it seems that it does not.

TlsTest from mono-project.com doesn’t support beyond TLS 1.0 because newer mono’s TLS changed.

Duplicati should probably follow in mono’s footsteps some time, as TlsTest gets increasingly irrelevant.

[Mono.Security]: Remove some obsolete test tools. #12542

These tools were using the obsolete Mono.Security.Protocol.Tls code (Legacy TLS), which is scheduled for removal.

Figure outdated documentation from http://www.mono-project.com/docs/ #8214

tlstest.c always uses the Managed TLS implementation and so it’s stuck with TLS 1.0. There’s a bug open on it in Bugzilla, but no one fixed it so far. Essentially it could lead people to try it and fail since TLS 1.0 is slowly getting deprecated.

Update TlsTest #4601

The code in the Mono.Security.Protocol.Tls namespace is the old legacy implementation, which only supports TLS 1.0. You need to replace its SslClientStream class with System.Net.Security.SslStream to use TLS 1.1 and TLS 1.2.

Technical details from the above, compared to Duplicati TlsTest code look to me like that’s the problem.

Secure Socket Layer (SSL) / Transport Layer Security (TLS) has new advice for a troubleshooting tool, however their usage doesn’t seem to allow the fine-grained control that TlsTest used to provide testers.

Here’s my attempt at an adaptation, where you can see that at least my mono connects to get its error:

$ csharp -e 'System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12; new System.Net.WebClient ().DownloadString ("https://jfs.jottacloud.com/jfs")'
System.Net.WebException: The remote server returned an error: (400) Bad Request.
  at System.Net.HttpWebRequest.GetResponseFromData (System.Net.WebResponseStream stream, System.Threading.CancellationToken cancellationToken) [0x00146] in <2703bbaa0a6e4686b6033c2dddb1a363>:0 
  at System.Net.HttpWebRequest.RunWithTimeoutWorker[T] (System.Threading.Tasks.Task`1[TResult] workerTask, System.Int32 timeout, System.Action abort, System.Func`1[TResult] aborted, System.Threading.CancellationTokenSource cts) [0x000f8] in <2703bbaa0a6e4686b6033c2dddb1a363>:0 
  at System.Net.HttpWebRequest.GetResponse () [0x00016] in <2703bbaa0a6e4686b6033c2dddb1a363>:0 
  at System.Net.WebClient.GetWebResponse (System.Net.WebRequest request) [0x00000] in <2703bbaa0a6e4686b6033c2dddb1a363>:0 
  at System.Net.WebClient.DownloadBits (System.Net.WebRequest request, System.IO.Stream writeStream) [0x000e6] in <2703bbaa0a6e4686b6033c2dddb1a363>:0 
  at System.Net.WebClient.DownloadDataInternal (System.Uri address, System.Net.WebRequest& request) [0x00061] in <2703bbaa0a6e4686b6033c2dddb1a363>:0 
  at System.Net.WebClient.DownloadString (System.Uri address) [0x00011] in <2703bbaa0a6e4686b6033c2dddb1a363>:0 
  at System.Net.WebClient.DownloadString (System.String address) [0x00008] in <2703bbaa0a6e4686b6033c2dddb1a363>:0 
  at <InteractiveExpressionClass>.Host (System.Object& $retval) [0x00010] in <ec05ab9f50ee49cc91c73cb05044f57d>:0 
  at Mono.CSharp.Evaluator.Evaluate (System.String input, System.Object& result, System.Boolean& result_set) [0x00038] in <0d152378608d403c93cdd2bf52f259d3>:0 
  at Mono.CSharpShell.Evaluate (System.String input) [0x00000] in <b302e50c0d1a4e6ab9d80adb91e4372b>:0 
$ 

Similar SSL/TLS controls come with Duplicati. I’m not sure what SystemDefault is, but try setting Tls12

$ duplicati-cli 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, Tls13
    * default value: SystemDefault
$ 

The issue is that the mono shipped with FreeBSD is not compiled with the BoringSSL support.
For example the Ubuntu binary has the support and also the “TlsTest.exe” is working in Ubuntu.

But I stuck at FreeBSD as I run duplicati in a Jail under FreeNAS.
Has anyone an idea how to compile mono under FreeBSD or how to update to a version with BoringSSL support?

Might I suggest a different approach? I’m not familiar with FreeNAS, but if it supports docker containers, you could run Duplicati that way. The container will be isolated from the host (similar to jail) but the container will contain all dependencies needed for Duplicati to work properly (Mono, etc). So you won’t need to worry about Mono at the FreeNAS level.

Just a thought…

Docker on FreeBSD looks like that path, but mono also looks like it’s had TLS 1.2 since about July 2018.

Bug 229247 - lang/mono BoringSSL support not enabled

Log of /head/lang/mono gives a detailed log of its history.

It looks to me like FreeBSD (and maybe FreeNAS) give you choice of building source, or getting a binary.

http://pkg.freebsd.org/ could be browsed, or 4.4. Using pkg for Binary Package Management might apply.