none
How to configure SSL work with customBinding and without any client certificates? RRS feed

  • Question

  • Dear ladies and sirs.

    I have a server and a client. Setup to work over ssl with minimum security. Here are their WCF configurations:

    Server:

     

     <system.serviceModel>
     <extensions>
     <bindingElementExtensions>
     <add name="gzipMessageEncoding" type="Shunra.Common.Wcf.Compression.GZipMessageEncodingElement, Shunra.Common"/>
     </bindingElementExtensions>
     </extensions>
    
     <services>
     <service name="Shunra.Common.Csla.WcfPortal" behaviorConfiguration="SSL_ServiceBehavior">
     <endpoint contract="Csla.Server.Hosts.IWcfPortal" binding="customBinding" bindingConfiguration="SSL_CompressedBinding" address="WcfPortal.svc" />
     <host>
      <baseAddresses>
      <add baseAddress="https://il-mark-w2k8/NC" />
      </baseAddresses>
     </host>
     </service>
     </services>
    
     <bindings>
     <customBinding>
     <binding name="SSL_CompressedBinding" receiveTimeout="00:30:00" sendTimeout="00:30:00" openTimeout="00:00:02">
      <gzipMessageEncoding innerMessageEncoding="binaryMessageEncoding" binaryMaxQuotaSize="2147483647"/>
      <httpsTransport maxReceivedMessageSize="2147483647" decompressionEnabled="true" requireClientCertificate="false"/>
     </binding>
     </customBinding>
     </bindings>
    
     <behaviors>
     <serviceBehaviors>
     <behavior name="SSL_ServiceBehavior">
      <serviceMetadata httpsGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
     </behavior>
     </serviceBehaviors>
     </behaviors>
     </system.serviceModel>
    
    

     

    Client:

     

     <system.serviceModel>
     <extensions>
     <bindingElementExtensions>
     <add name="gzipMessageEncoding" type="Shunra.Common.Wcf.Compression.GZipMessageEncodingElement, Shunra.Common"/>
     </bindingElementExtensions>
     </extensions>
    
     <client>
     <endpoint name="SSL_WcfDataPortal"
      address="https://il-mark-w2k8/NC/WcfPortal.svc"
      binding="customBinding"
      bindingConfiguration="SSL_CompressedBinding"
      contract="Csla.Server.Hosts.IWcfPortal" />
     </client>
    
     <bindings>
     <customBinding>
     <binding name="SSL_CompressedBinding" receiveTimeout="00:30:00" sendTimeout="00:30:00" openTimeout="00:00:02">
      <gzipMessageEncoding innerMessageEncoding="binaryMessageEncoding" binaryMaxQuotaSize="2147483647"/>
      <httpsTransport maxReceivedMessageSize="2147483647" decompressionEnabled="true" requireClientCertificate="false"/>
     </binding>
     </customBinding>
     </bindings>
     </system.serviceModel>
    
    

     

    Please, note that because we compress the traffic, we use customBinding.

    In addition, in order for the client to work without any certificates I handle the ServicePointManager.ServerCertificateValidationCallback event - return true from there (and log the details).

    I am fully aware, that using SSL without mutual authentication makes the system vulnerable to the man in the middle attacks. I am willing to pay this price, because I am currently not in a position to install any certificates at the client side. Given that constraint, is my setup good enough or can I improve it? For instance, I have no idea if the communication is encrypted/signed using my current settings.

    I have tried to use AnonymousForCertificate, but failed because it seems to require the presence of the server certificate on the client side, which I cannot do.

    Thanks.



    Sunday, May 8, 2011 9:46 AM

Answers

  • message level security (e.g. anonymousForCertificate) might be a little more secure in your case since clients have the server certificate embedded in them (or their environment) rather then getting it via negotiation from the network. This is harder for MITM to replace the certificate. this means each client needs to have the x.509 out of band.

    note the biggest thing is that your service currently does not authenticate the clients - so any client (also hacker) can access it. if this is not an issue and you just care about protecting the contents legitimic clients send then message security may be better.


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    • Marked as answer by Yi-Lun Luo Friday, May 13, 2011 9:14 AM
    Tuesday, May 10, 2011 9:27 PM

All replies

  • You seem to be well aware to the risk of returning true for each certificate.

    I still suggest you reconsider it - the way is wide open to MITM attack.


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Sunday, May 8, 2011 1:19 PM
  • Like I have mentioned, I have no choice at the present. I might introduce some mechanism to ask the user to confirm the operation, like the browsers do, but it is not going to be done now. Letting aside the MITM issue, is the current configuration good enough? For instance, I thought that the AnonymousForCertificate authentication mode is better than the default, but I failed to use it.

    Tuesday, May 10, 2011 8:02 PM
  • message level security (e.g. anonymousForCertificate) might be a little more secure in your case since clients have the server certificate embedded in them (or their environment) rather then getting it via negotiation from the network. This is harder for MITM to replace the certificate. this means each client needs to have the x.509 out of band.

    note the biggest thing is that your service currently does not authenticate the clients - so any client (also hacker) can access it. if this is not an issue and you just care about protecting the contents legitimic clients send then message security may be better.


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    • Marked as answer by Yi-Lun Luo Friday, May 13, 2011 9:14 AM
    Tuesday, May 10, 2011 9:27 PM
  • Hi Yaron.

    Forgive me my ignorance.I have two questions:

    1. Why is the message security better than the current configuration?
    2. Could you show the changes necessary to make in the current configuration to enable the message security?
    Thank you very much.
    Monday, May 16, 2011 11:14 AM
  • 1. because the server certificate is embedded inside the client app and not transfered over the network, which is one more point for failure.

    2. you can add this first element:

    <security mode="mutualAuthentication" />

    the WCF SDK has detailed samples, one is in this path (after you download it):

    \WCF\Basic\Binding\WS\MessageSecurity\Certificate\CS

    Note the setting up message security is more challenging then transport one so this make take a while until you finr tune it.


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Monday, May 16, 2011 7:51 PM
  • I do not understand how can the server certificate be embedded inside the client app.

    We have two options when the server is installed:

    1. Create the server certificate dynamically.
    2. Use a well known server certificate.

    The first option is quite hard to implement. It implies that the client installation can only be downloaded from the particular server machine, because this is where the server certificate lives. This makes the client installation process more complex introducing additional "points of failure".

    It is unclear to me how the second option can be better. Isn't it true, that having a well known server certificate means that the server installer should either embed it or communicate to some remote server to download it during the installation? And this time, the certificate must include the private key, so it is either transmitted over wire or embedded within the server installer. If my analysis is right, then I do not see how it is better.

    Please, explain me where am I wrong.

    Thank you very much.

    Wednesday, May 18, 2011 7:17 AM
  • let's say I want you to send me some secure box.

    you have the box. now either we have met before and I gave you a few locks to use when you need them ("embedded") or the case is that whenever you want to send me something you call me and I send you a lock.

    now only I have the key so after you lock the box and send it even if someone catch it we are still safe.

    the risk is if someone catches my lock as I send it to you and replaces it with his lock. since you have disabled the certificate verification (the callback) you will not notice it and send the message in the box with the man in the middle lock, which he can then open.


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Tuesday, May 24, 2011 8:02 PM
  • I understand the analogy, but it is not accurate.

    Please, explain how to "embed" the key securely? A user gets an installer of the server. Does this installer embed the server certificate? Including the private key?

    Thanks.

    Wednesday, May 25, 2011 6:07 PM
  • why the user gets the server? doesn't the user install a client which talks with your server?

     


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Monday, May 30, 2011 6:03 PM
  • And where does the server live? Our server is neither in the cloud nor do we provide any hosting. The product is a client-server solution. A global company, for example Nokia, installs the server somewhere in the datacenter and then installs the clients somewhere else. Do you find this configuration extraordinary?

     

    Monday, May 30, 2011 7:04 PM
  • hi - your last post focused on a question which did not came up in the thread so far (embedding the cert in the setup) while I was under the impression the real question is the runtime safety. this is why I wanted to step back a little and understand the big picture.

    I assume each of your customers would like to use their own certificate. In this case they may generate it themselves and configure your app to use it or you can do it for them manually or via setup (as ling as you send it securely to them). This is a matter of process rather then wire-security.


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Monday, May 30, 2011 8:01 PM
  • Yes, but how can one detach wire-security from the process? The customers want secure communication (to various degree, some tolerate MITM, others don't).

    The customer may not know anything about the certificate business, but (s)he knows to tell https from http.

    They want to install the server and get going. They do not expect to waste their time trying to figure how to setup security. This is our job.

    Now, some customers do not care about the security per se as do they care to keep the port 80 closed. In which case, we are left with 443 and https. It is our job to configure it. This is the case when MITM is of no concern to them. This is way I generate certificates with makecert, rather than using CA server.

    But suppose, there is a real security concern. Do I have to say them - "Folks. Here is our server. Here is its WCF configuration. Please, create the server certificate, modify the configuration files, perform the port binding. install the certificate in the Default Web Site in IIS, reserve HTTPS namespace, grant the server account permissions to the certificate private key and then make sure this server certificate finds its way to all the clients, otherwise you are vulnerable to MITM." What would be the customer's reaction to this configuration process? As I see it, the responsibility is ours to provide the server installer to do all that. The installer has to figure our how to create the certificate (whether to use makecert or install a local CA server) and perform all the necessary housekeeping. And since the server certificate is dynamic comes the question - how is it delivered to the client? I do not see any easy solution to this question and because of this we do not support this option at all at the moment. Yes, we are open to MITM and customers know it and accept it, for the time being. Of course, we can tell them to configure a group policy to automatically deploy the server certificate to all the machines, but things like this take time and they do not depend on us.

    Please, tell me where I am wrong in this analysis.

    Tuesday, May 31, 2011 11:25 AM
  • Your analysis is correct. If you want client machines to support the server certificate, the cert must be signed by an issuer which the client already supports, or pushed to support by a group policy. TINSTAAFL.


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Friday, June 3, 2011 8:13 PM