[Mono-list] linux+mono and windows client sslstream communication failure

[Chirag Patel]

I have added bug with code and certificates to novell bugzilla.
https://bugzilla.novell.com/show_bug.cgi?id=698674

Since now I was working on the same ubuntu Linux VM for both client
and server, and also using certificates generated on the same machine
using makecert, I thought there is a reason to believe the attached
code may not have problem or I have to do something differently for
linux+mono.

Thank you

On Fri, Jun 3, 2011 at 11:02 AM, Chirag Patel <patel.chirag.d at gmail.com> wrote:
> Inline...
>
> Briefly, it works without SSL. But doesn't work with SSL.
>
> On Tue, May 31, 2011 at 11:09 AM, Sebastien Pouliot
> <sebastien.pouliot at gmail.com> wrote:
>> On Tue, 2011-05-31 at 10:47 -0700, Chirag Patel wrote:
>>> Hi,
>>>
>>> I need to debug a client server communication failure, while I'm
>>> trying to migrate my windows .net framework code to linux mono.
>>>
>>> Here is some code on the client:
>>>       _sslstream = new SslStream(_tcpclient.GetStream(), false,
>>>                      callback, null);
>>>         _sslstream.AuthenticateAsClient("", _certs, SslProtocols.Ssl3,
>>>                      false);
>>
>> First you should try to shrink your app into a smaller test case. E.g.
>> does it work without client certificates (which you seems to be
>> supplying here). Once you have something small then open a bug report
>> and attach your code on it.
>>
> I rewrite the server to not use SslStream, but use NetworkStream. That worked.
>
> I wrote a totally different code for client and server to try it
> across windows and linux.
> Both client and server were communicating over NetworkStream worked,
> but SslStream did not work.
>
> I tried original client-server code with newly generated certificates
> (using makecert in mono/linux), but that also did not work.
> (I was very hopeful on this attempt)
> _sslStream.AuthenticateAsClient results into BeginWrite Failure at
> NetworkStream::BeginWrite called by
> Mono.Security.Protocol.Tls.SslStreamBase.AsyncHandshakeCallback.
>
> At this point, I have also minimized the problem by bringing client
> code into Linux VM itself, where server is. So now client and server
> both are running on the same Linux VM.
>
> I have also made the machine name same as certificate subject.
> abc.xyz.com, and I also have a host entry for the same when I try
> across windows & linux.
>
> In windows, this line of code used to work.
>  _sslstream.AuthenticateAsClient("", _certs, SslProtocols.Ssl3,  false);
> Now, with linux/mono, I had to change it to:
>  _sslstream.AuthenticateAsClient("abc.xyz.com", _certs,
> SslProtocols.Ssl3,  false); where abc.xyz.com is the server machine
> name.
>
>> Also try other variations, like Tls1 instead of Ssl3. Actually there is
>> no good reason to use SSL3 if you control both the client and server.
> I gave it a quick try by indicating use SslProtocols.Tls, But I would
> not have ability to do it forever. Currently, I control the client and
> server. But, client is just for internal testing. There are going to
> be actual third party clients.
>
>>
>>> After this point, the following code fails:
>>>       _sslstream.Read(buffer, offset, size);
>>>
>>> It looks like this one doesn't move forward for quite a while.
>>>
>>> The last thing server did was BeginHandshake call.
>>>                  SslStream :: BeginAuthenticateAsServer(serverCert, true,
>>>  SslProtocols.Ssl3, true, callback, this);
>>>
>>> After server authenticate is finished, server is supposed to send a
>>> greeting, but that doesn't seem to happen, as that part of code is not
>>> hit yet.
>>>
>>> On top of that, when I 'stop' the client, server's EndHandshake (viz.
>>> EndAuthenticateAsServer) is called.
>>>
>>> Setup details:
>>> Client side: Physical Machine -  Windows + Microsoft .NET 3.5
>>> Server side: Virtual Machine hosted on above - Linux + Mono 2.6
>>> (latest stable release)
>>>
>>> I have full access to code on both sides, as both are written
>>> in-house. And the setup has been running fine on Windows for 1 year.
>>>
>>> I have ignored client side errors about server certificate for now,
>>> with the ValidateServerCertificateCallback.
>>> (I have one error here - RemoteCertificateNameMismatch for the server
>>> certificate on client side)
>>>
>>> Once it hits that _sssstream.Read, I can't figure out what's going on
>>> and why isn't it moving forward?
>>
>> Try writing to the stream before reading (even if writing an empty
>> byte[] array) since this is the most common case of a client starting an
>> SSL session.
>>
>> Sebastien
>>
>>
>