Bugzilla – Bug 457120
System.Net.Security.SslStream's AuthenticateAsServer hangs
Last modified: 2012-06-25 05:10:16 UTC
Client -> Server connection. In the tested environment the initial connection is made using plaintext communication (NetworkStream), when specific message is received SslStream is created on the top of the existing stream and further communication is done via secured channel. The authentication process requires both server and client to authenticate with their certificates. Call to the AuthenticateAsServer on the server side hangs and doesn't exit. Tested framework combinations: Client(.Net) -> Server(.Net) - works Client(Mono) -> Server(.Net) - works Client(Mono) -> Server(Mono) - doesn't work Client(.NET) -> Server(Mono) - doesn't work The issue is present on Windows Vista as well as out production environment, which is Debian.
Created attachment 258496 [details] Server's code Code that works on the server side (only part of the original code is attached - but it exposes the issue)
Created attachment 258497 [details] Client code Client code
Created attachment 258498 [details] Example client certificate
Created attachment 258499 [details] Example server certificate Example server certificate
Quick guess: the stream is not flushed prior to switching into SSL
Doing input.Flush() in server code prior to creating SslStream doesn't help
Yesterday my friend pointed about behavior that is exposed by SslServerStream - authentication process is triggered as soon as something is sent through the connection. I've altered my test case and put the following code in Client's Program.cs around line no. 50 : m_sslClient.Write(new byte[] { 0 }); After this modification, server code finally exits from call to AuthenticateAsServer. This behavior is different than the one exposed by .NET framework.
Created attachment 325492 [details] Suggested fix for SslStream My friend Maciej Kowalewski prepared a simple patch that resolves the issue. This patch is somehow a workaround for how a SslServerStream works (there is no direct method to authenticate server/client contrary to SslStream).
Any news on the issue? I suppose that this bug also mentioned here: https://bugzilla.novell.com/show_bug.cgi?id=528508
The suggested patch on this bug targets the same line of code on the suggested patch on this page. https://bugzilla.novell.com/show_bug.cgi?id=430504
So this bug is now almost 4 years old, and still hasn't been patched in the latest source, I'm mystified, this bug prevents mono being used for some applications, the patch is a simple one line change that works (for me). But I can't distribute a product which requires users to download mono, patch the source and rebuild it. I don't mean to complain, I'm just curious how to get this fix applied, I'm happy to help if I can...
I was in the same situation regarding my software. I finally decided to embed the source code of SslStream from Mono into my application, patch it and use it to provide compatibility with .NETs implementation. Since the code is under MIT X11 license, there is no problem as long as you comply with its requirement and include a copy of the license in your software.
(In reply to comment #11) > ... the patch is a simple one line change that works (for me). The patch is more likely to get accepted if it adds a unit test that passes on .NET and fails in current Mono (but which doesn't fail after applying the fix).
Created attachment 495106 [details] Test case Provided test case (NUnit) that fails on Mono but succeeds on .NET and patched version of Mono.
Fixed with pull request 343: https://github.com/mono/mono/pull/343