Bug 17356 - Mono.Security.Protocol.Tls.TlsException: The authentication or decryption has failed.
Summary: Mono.Security.Protocol.Tls.TlsException: The authentication or decryption has...
Status: RESOLVED NORESPONSE
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: master
Hardware: Other Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-01-21 16:03 UTC by Michael Ayvazyan
Modified: 2017-09-06 16:51 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED NORESPONSE

Description Michael Ayvazyan 2014-01-21 16:03:03 UTC
Our application uses SSL as a communication channel.
It's working fine under .Net.

On mono it's able to open connection and it's working for some time.
Unfortunatally from time to time we see the following error in logs.
  Mono.Security.Protocol.Tls.TlsException: The authentication or decryption has failed.

Mono Runtime Engine version 3.2.7 (master/f18648d Wed Jan  8 05:41:21 UTC 2014)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+hard
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
Comment 1 Michael Ayvazyan 2014-01-22 15:37:36 UTC
I was able to reproduce it on the latest Mono code base.

Mono.Security.Protocol.Tls.TlsException: The authentication or decryption has failed.
  at Mono.Security.Protocol.Tls.RecordProtocol.ReadRecordBuffer (Int32 contentType, System.IO.Stream record) [0x00000] in <filename unknown>:0 
  at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0 



Mono JIT compiler version 3.2.7 (master/c6bd624 Wed Jan 22 01:47:15 UTC 2014)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+hard
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
Comment 2 Sebastien Pouliot 2014-01-22 16:56:53 UTC
Sadly, by design (security consideration), SSL/TLS is not very verbose in it's errors.

Au such it is not possible to know what's going on with out a test case and knowing which site/server is being used (this is a negotiated protocol).

A wireshark trace might also help.
Comment 3 Michael Ayvazyan 2014-03-12 10:40:54 UTC
Sebastien, thank you for the response!

We found a cause of the issue.
Our application is sending some data using SSL Stream and other data using NetworkStream. So only valuable data gets encrypted.
It's working like a charm on .NET.
Do you think it will be supported on Mono?

For now we changed our application to send all the data using SSL Stream.
We are concerned about bandwidth usage. Hence it would be nice to be able to switch back to the initial approach.
Comment 4 Sebastien Pouliot 2014-03-12 16:47:14 UTC
Not sure I understand. Are you talking about:

1. Having two separate connections, one on HTTP (e.g. NetworkStream on port 80) and one on HTTPS (e.g. SslStream on port 443) ?

That should work without any issue.


2. Having a single connection (single port/stream) ?

In that case no, it's not supported. I'm not even sure it's fully possible. Being synchronized between client and server (so one send and the other receive in the expected protocol) cannot deal properly with out of band alerts (which would quickly break the SSL state and connection).
Comment 5 Marek Safar 2017-09-06 16:51:50 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and reopen the bug report.

Thank you!