none
Wcf client .net cf leaks memory when using mutual certificate authentication

    Dotaz

  • When I configure a wcf service to use mutual certificate authentication the client leaks native memory with every call to the service. I already found the bug in the serializers, where a new serializer is added each time a new call is done. When I configure the service to use no authentication at all then the native memory leak does not happen.

    Below follows the configuration of the client

      public static System.ServiceModel.Channels.Binding CreateDefaultBinding()
        {
            System.ServiceModel.Channels.CustomBinding binding = new System.ServiceModel.Channels.CustomBinding();
            binding.Elements.Add(new System.ServiceModel.Channels.TextMessageEncodingBindingElement(System.ServiceModel.Channels.MessageVersion.Soap11, System.Text.Encoding.UTF8));
            System.ServiceModel.Channels.AsymmetricSecurityBindingElement asbe = new System.ServiceModel.Channels.AsymmetricSecurityBindingElement(new System.ServiceModel.Security.Tokens.X509SecurityTokenParameters(System.ServiceModel.Security.Tokens.X509KeyIdentifierClauseType.Any, System.ServiceModel.Security.Tokens.SecurityTokenInclusionMode.Never), new System.ServiceModel.Security.Tokens.X509SecurityTokenParameters(System.ServiceModel.Security.Tokens.X509KeyIdentifierClauseType.Any, System.ServiceModel.Security.Tokens.SecurityTokenInclusionMode.AlwaysToRecipient));
            asbe.MessageSecurityVersion = System.ServiceModel.MessageSecurityVersion.WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;
            asbe.LocalClientSettings.DetectReplays = false;
            asbe.LocalServiceSettings.DetectReplays = false;
            asbe.DefaultAlgorithmSuite = System.ServiceModel.Security.SecurityAlgorithmSuite.Basic256Rsa15;
            asbe.SetKeyDerivation(false);
            binding.Elements.Add(asbe);
            binding.Elements.Add(new System.ServiceModel.Channels.HttpTransportBindingElement());
            return binding;
        }

    And the creation of the client:

    EndpointIdentity identity = EndpointIdentity.CreateDnsIdentity("service0");

    var binding = QClient.CreateDefaultBinding();
    var ep = new EndpointAddress(QClient.EndpointAddress.Uri, identity);

    QClient client = new QClient(binding, ep);
    client.ClientCredentials.ClientCertificate.SetCertificate(StoreLocation.CurrentUser, StoreName.My, X509FindType.FindBySubjectName, clientCertificateName);
    client.ClientCredentials.ServiceCertificate.Authentication.CertificateValidationMode = System.ServiceModel.Security.X509CertificateValidationMode.None;
            client.ClientCredentials.ServiceCertificate.SetDefaultCertificate(StoreLocation.CurrentUser, StoreName.My, X509FindType.FindBySubjectName, serverCertificateName);
    return client;

    Does anyone know a solution? Its not possible to upgrade to windows phone.

    Thanks,

    24. února 2012 6:55

Všechny reakce

  • Hello,

    You can submit this feedback to Microsoft Connect feedback Center in formal format. Microsoft engineers will evaluate them seriously and report to Product Group.
    http://connect.microsoft.com/VisualStudio/

    Or you can send this to the Visual Studio UserVoice site.
    http://visualstudio.uservoice.com/forums/121579-visual-studio/filters/top

    Best regards,
    Jesse


    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us

    27. února 2012 7:19
  • We have been having the same problem but had not identified the security as being the culprit.

    It is very helpful to know that we are not the only ones seeing this leak.

    Do you think it could be to do with the Store Location of the ServerCertificate? Ours is in Trusted Authorities (the MS example in the WCF Guidance documentation gets it from the Root store).

    We have found that it does not leak if the reply is not decrypted and deserialised. The request message on its own does not leak.

    So I guess that the problem is with the use of the Server Certificate public key.

    I will see if calling client.ClientCredentials.ServiceCertificate.DefaultCertificate.Reset and reloading the certificate will work around the problem....

    Thanks for posting...

    28. února 2012 2:04
  • Calling DefaultCertificate.Reset did not help.

    It seems as if the leak is in using the certificate, not in the certificate itself.

    You are correct in that it is the Client Certificate that is leaking. The Server is using the Client Certificate to encrypt the reply and the Client is then attempting to decrypt and deserialise it.

    • Upravený timd199 1. března 2012 19:08
    28. února 2012 11:46
  • We inspected the native heap of the unit. And found that we found multiple copies of something related to the client certificate in memory.

    29. února 2012 7:08