EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Renegotiate of Ciphers fails with error 75789

Posted: 09/20/2010 04:58:59
by Adam Shaw (Priority Standard support level)
Joined: 09/08/2010
Posts: 10

I have managed to implement SSL BlackBox into our existing application and successfully connected a client and exchanged messages.

However if the client issues a Renegotiate the serverside (which implements blackbox) throws a SocketError.

The server side socket is created like this.

elServerSSLSocket = new ElServerSSLSocket(this.socket, true);
TElMemoryCertStorage certStore = new TElMemoryCertStorage();
certStore.Add(this.certificate, true);
elServerSSLSocket.CertStorage = certStore;
elServerSSLSocket.OnCertificateValidate += new SBSSLCommon.TSBCertificateValidateEvent(ValidateServerCertificate);
elServerSSLSocket.OnError += new SBSSLCommon.TSBErrorEvent(elServerSSLSocket_OnError);
elServerSSLSocket.OnCiphersNegotiated += new SBUtils.TNotifyEvent(elServerSSLSocket_OnCiphersNegotiated);
elServerSSLSocket.SSLEnabled = true;
elServerSSLSocket.ClientAuthentication = true;

I then implemented the OnCertificateValidate event like this.

private void ValidateServerCertificate(object sender, TElX509Certificate certificate, ref bool validate)
if (!hasAuthenticated)
// todo this needs to deal with errors other than chain errors.
TElMemoryCertStorage certStore = new TElMemoryCertStorage();
certStore.Add(certificate, true);
elServerSSLSocket.ClientCertStorage = certStore;
hasAuthenticated = true;

validate = true;

I can see this event fired when renegotiation is initiated. But imediately after this the OnSocketError event is fired.

This is the stack trace

at Trax.Sockets.Ssl.ClientSslSocket.elServerSSLSocket_OnError(Object Sender, Int32 ErrorCode, Boolean Fatal, Boolean Remote) in C:\Appserver\Gateway\Trax.Communications\ClientSslSocket.cs:line 189
at SecureBlackbox.SSLSocket.Server.ElServerSSLSocket.OnSecureServerError(Object sender, Int32 errorCode, Boolean fatal, Boolean remote)
at SBServer.TElSecureServer.DoError(Int32 Code, Boolean Fatal, Boolean Remote)
at SBServer.TElSecureServer.SSL3ParseCertificateVerify(Byte[] Buffer)
at SBServer.TElSecureServer.SSL3ParseOnHandshakeLayer(Byte[] Buffer)
at SBServer.TElSecureServer.SSL3ParseOnRecordLayer(Byte[] Buffer, Int32 Size)
at SBServer.TElSecureServer.SSL3AnalyzeBuffer()
at SBServer.TElSecureServer.AnalyzeBuffer()
at SBServer.TElSecureServer.DataAvailable()
at SecureBlackbox.SSLSocket.Server.ElServerSSLSocket.DataAvailable()
at SecureBlackbox.SSLSocket.ElSSLSocket.OnSocketReceiveCallback(IAsyncResult asyncResult)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.ContextAwareResult.CompleteCallback(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)


Remote = false

Any help on this would be appreciated. I have had a demo app working using your code and the same certificates.
Posted: 09/20/2010 07:50:55
by Ken Ivanov (Team)

Thank you for contacting us.

Does the same issue occur if the server-side part of the sample application we've provided to you via Helpdesk is used?
Posted: 09/20/2010 08:13:13
by Adam Shaw (Priority Standard support level)
Joined: 09/08/2010
Posts: 10

The sample application provided is a single winform that does both client and server processing. I can't see how I could prove this without changing the sample app.

I could try setting up a simple client/server example, but as you can see from my supplied code snippet we are forcing client side authentication but the sample doesn't validate the client cert.
Posted: 09/20/2010 08:23:59
by Ken Ivanov (Team)

Yes, the sample will need slight modifications to be introduced. I've got a better idea though -- please try to modify the sample in the following way to make it only act as a server and check if it exposes the same issue if your client connects to it and requests renegotiation (let's assume that synchronous mode is used for testing):
        private void Start()
            if (!cbAsyncMode.Checked)
                m_Terminate = false;
                Log("Starting server listening thread");
                Thread listeningThread = new Thread(new ThreadStart(ListeningThreadFunc));
                // waiting for the server to start listening
                [B]return;[/B] // <-- add this line to suppress client side
                Log("Starting client thread");
                Thread clientThread = new Thread(new ThreadStart(ClientConnThreadFunc));
                Log("Starting asynchronous listening");
                Socket listeningSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
                listeningSocket.Blocking = false;
                listeningSocket.Bind(new IPEndPoint(IPAddress.Loopback, Convert.ToInt32(tbPort.Text)));
                listeningSocket.BeginAccept(new AsyncCallback(ListeningSocketAcceptCallback), listeningSocket);
                Log("Initiating client connection");
                Socket clientSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
                clientSocket.Blocking = false;
                clientSocket.BeginConnect(new IPEndPoint(IPAddress.Loopback, Convert.ToInt32(tbPort.Text)), new AsyncCallback(ClientSocketConnectCallback), clientSocket);

        private void ServerConnThreadFunc(object o)
            Socket tcpSocket = (Socket)o;
            ElServerSSLSocket serverSslSocket = new ElServerSSLSocket(tcpSocket, true);
            serverSslSocket.OnError += new SBSSLCommon.TSBErrorEvent(serverSslSocket_OnError);
            serverSslSocket.OnCiphersNegotiated += new SBUtils.TNotifyEvent(serverSslSocket_OnCiphersNegotiated);
            serverSslSocket.OnCertificateValidate += new SBSSLCommon.TSBCertificateValidateEvent(serverSslSocket_OnCertificateValidate);
            serverSslSocket.ClientAuthentication = true;[/B]

        void serverSslSocket_OnCertificateValidate(object Sender, TElX509Certificate X509Certificate, ref bool Validate)
            Log("(server) Client's certificate received");
            Validate = true;

        void serverSslSocket_OnCiphersNegotiated(object Sender)
            Log("(server) New ciphers negotiated");
Posted: 09/20/2010 08:40:06
by Adam Shaw (Priority Standard support level)
Joined: 09/08/2010
Posts: 10

I have done this but get the same error.

[14:46:10] Starting server listening thread
[14:47:08] (server) New connection accepted
[14:47:09] (server) Calling OpenSSLSession()
[14:47:11] (server) Client's certificate received
[14:47:11] (server) SSL session established. Running mirroring loop
[14:47:11] (server) 10 bytes received: HelloWorld
[14:47:11] (server) Sending them back
[14:47:18] (server) Client's certificate received
[14:47:18] (server) SSL error 75789
[14:47:18] (server) Remote side has closed the connection
Posted: 09/20/2010 08:53:15
by Ken Ivanov (Team)

Thank you for checking.

It seems to me that the client application you use sends incorrect signature during client verification routine. Can this application be downloaded from somewhere, so that we could investigate the issue in our environment?
Posted: 09/20/2010 09:00:23
by Adam Shaw (Priority Standard support level)
Joined: 09/08/2010
Posts: 10

Thats strange as I used your sample client and replaced the blackbox components with the implementation we use to prove the concept of renegotiation would work.

The only difference now is using the code you sent me on Friday.

We currently use the free Mentalis implementation (http://www.mentalis.org/).

I can send you the client code that we used.
Posted: 09/20/2010 09:09:00
by Ken Ivanov (Team)

Hmm, do you mean that the SBB-driven client application also makes the server expose 75789 error?

Thank you, having the client code would speed up the investigation much. Could you please post it either here or to the Helpdesk?
Posted: 09/20/2010 09:17:34
by Adam Shaw (Priority Standard support level)
Joined: 09/08/2010
Posts: 10

I used your sample applications for both client and server.

I replaced the SBB implementation in the Client with the Mentalis implementation.

Renegotiation worked fine.

I'll upload the client code and Mentalis DLL using the helpdesk
Posted: 06/30/2012 01:58:34
by Eugene Mayevski (Team)

Turned out to be Mentalis bug.

Sincerely yours
Eugene Mayevski



Topic viewed 3065 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!