I am encountering the following problems trying to work through the quagmire of settings in WCF...
I created a WCF client-server service using a NetTcp binding. I didn't make any changes to the security settings and when running on one machine it works very nicely. However, when I ran my client from another machine it complained that the server didn't like the security credentials that were sent.
I understand now that NetTCP is "secured" by default and that my client would have been passing the wrong security details - namely the Windows user name and password (or some form of domain authentication) to my server which as they are not running on the same domain it would not have liked.
However, what I don't understand is as follows:
I haven't specified any security in my binding - does the standard settings expect a Windows user name or password to be sent?
I don't have any certificate installed on my server - I understand that NetTCP bindings need some form of public private key to protect the credentials - yet this seemed to work when both client and server were on the same machine - how was the data getting encrypted? Or wants it as WCF knew it was on the same machine and encryption isn't needed?
I have had to set my security mode on my client and server to "none" now and they connect nicely. However is there a way to encrypt my data without a certificate?
Finally... what is the difference between Transport and Message security?
To check my understanding (excuse the scenario!) message security is like if I sent a letter from person A to person B and I encode my hand writing to ensure that if anyone intercepts it they cannot read it? Transport Security is if I decide to have my letter sent by armed transport so that no one can get at it along the way?
Is it possible to have any form of encryption in WCF without a certificate? My project is a private project and I don't want to purchase a certificate and the data isn't that sensitive anyway so it's just for my own knowledge.
The default client credential type for NetTcpBinding is Windows Authentication. For Windows Authentication to work both client and server must be in the same domain, or mutually trusting domains (which in your case you do not have).
If both client and server were on the same domain, WCF would handle the mechanics of Windows Authentication "behind the scenes". And when both client and server are on the same machine they are effectively within the same domain, so Windows can use its own mechanisms to handle the encryption and decryption. It will only do this within mutually trusting domains, though.
If you don't have mutually trusting client and server domains, then the client and server must have some other way to determine if they trust each other with their keys. That's where certificates come in. The client and the server have their own certificates (or the server can issue the client a certificate).
Transport security is like encrypting the outside of the envelope as well as the inside. The downside is if you have to pass the envelope to someone outside your own organization, they need a decryption key just to know where the envelope is supposed to go--now they can read the message in the envelope also. On the other hand, transport security is faster--it requires less security overhead data getting passed along with your envelope.
Message security encrypts your message, but the envelope can be read by the postal workers (the internet and its routers). Only the source and the destination have the keys to decrypt the message, but the intermediaries can properly route your message.
To summarize: to use encryption over the NetTcpBinding both client and server must be within a domain (or mutually trusting domains) or you must have a key exchanging certificate.
Edit: I was asked for some example code--here is a binding element in XAML. It would normally be placed within a netTcpBinding element.
<binding name="Secure" listenBacklog="4000" receiveTimeout="00:20:00" sendTimeout="00:20:01"
maxReceivedMessageSize="2147483647" maxConnections="200" portSharingEnabled="true">
<!-- ~2 GB -->
<readerQuotas maxStringContentLength="2147483647"/>
<!-- ~2 GB max string content length -->
<security mode="Message">
<transport clientCredentialType="None" protectionLevel="EncryptAndSign"/>
<message clientCredentialType="None"/>
</security>
</binding>
The important part is the security element. For transport security one would change the mode attribute to "Transport". More than likely the clientCredentialType would not be "None" but rather "Certificate", "Ntlm", or "Windows" depending on the context.
Related
I have seen one or two questions about this but no definite answers. I have a customer requirement to implement a WCF-based client/server solution using Message Encryption AND HTTPS. I understand that WCF doesn't support this as standard, and the options are HTTP with Message Encryption, HTTPS without Message Encryption, or HTTPS with Message Credentials.
None of these will satisfy the customer requirement. I have control over both the service and the desktop-based clients. The service is hosted at my location and the clients access it over the internet.
I have dug around for days (and nights :( ) trying out custom bindings and so on, but whenever I try to combine message encryption with Https, I come up against this error:
"The binding contains both a SymmetricSecurityBindingElement and a secure transport binding element. Policy export for such a binding is not supported."
I would prefer to user username/password for authentication but I am prepared to use client certificates if this makes it possible. So far I haven't found any combination which is acceptable to WCF.
Is there any way to achieve this or am I just wasting my time? I would value a quick answer because my customer's deadline is drawing very near!
Thanks!
According to this, the special both mode for security (meaning both message and transport) is only supported in the NetMsmqBinding binding, which I'm guessing, is not an option for you. Does your client happen to be the NSA? (Just wondering why anyone would need their communication encrypted twice).
OK I've found a solution ...
Using IMessageInspector I intercepted the incoming and outgoing messages so that they can be encrypted and decrypted. Encryption uses a symmetric technique - best because asymmetric only allows encryption of short strings and is very slow.
The downside is that both ends need to have the private key of the certificate - so the cert needs to be installed on both client and server machines (or the key could be placed in config). This works for me though because the number of users is limited and all are under the control of the IT dept.
If I had more time I would have looked at setting up a second SSL connection with a different cert, purely to handle the certificate negotiation and avoid placing the cert on the client machine. Using SslStream was a possibility but I wasn't sure whether I could access key information to use for my own encryption, or whether this is held privately within SslStream class.
For now I'm just pleased to have it working before my deadline (only just though :) ) ...
I'm trying to understand more why I shouldn't use WCF transport security over the internet. From the answer here I'm told the chain of hops may not be secure. But isn't transport security just like https (which is widely used on the internet)? Or maybe I should ask, what is the difference between wcf transport and https?
If I need to explain myself clearer, please comment.
Thanks
Transport security is indeed very similar to HTTPS (and identical in many cases). What it provides you is an encrypted tunnel between your client and the server. Providing there's a direct connection from your client to your server, it's perfectly fine (providing that your client verifies that it got the right server certificate). If your client is talking to another intermediate server, on which you rely to pass the message to your server - then that intermediate server would get unencrypted data.
An example :
You have a company that processes payments. Because of some regulations, you need servers in each country, and those in turn pass the requests to your main server in the US.
You want to make sure that even if the local hosting company tries to find out what details are being passed, they can't.
That is what Message Security provides you - you trust only the client and your main servers, so you want only them to be able to encrypt and decrypt.
With Transport Security, there would be two transitions - the client will encrypt, and the intermediate server will decrypt. Then it will encrypt again, and your main servers will decrypt. As you can see, there is an intermediate phase where the data is plain in RAM in the intermediate server.
This MSDN article describes it very well, and where to use each :
MSDN
Look at another answer on the link you gave. It explains that the case where transport security not sufficient is when the client doesn't check server certificate. I quoted the answer below:
Yes it is 100% secure when the clients (which most clients do) validate the server certificate.
The multiple hop scenario mentioned here is complete bogus. This is only true when the same message travels through various applications. Like for example several application brokers. If these brokers do not communicate securely then the message can be read by intermediate network sniffers.
In other words, client/server communication over the internet is 100% secure even when there are a million routers in between but it is only secure when the client validates the server certificate as the client could connect to a man-in-the-middle host that could impersonate the server with a false certificate. If the client does not validate the certificate the message could be compromised.
I'm trying to understand more why I shouldn't use WCF transport security over the internet
You should not because (Quoting from here).
Transport Security
Transport security is used to provide point-to-point security between the two endpoints (service and client). If there are intermediary systems between client and the service, each intermediate point must forward the message over a new SSL connection.
Message Security
When using message security, the user credentials and claims are encapsulated in every message using the WS-Security specification to secure messages. This option gives the most flexibility from an authentication perspective. You can use any type of security credentials you want, largely independent of transport, as long as both the client and service agree.
I have read in Training Kit of MS -WCF that all the bindings by default provide network security that is developer has to do nothing for implementing security.
I have one query over this :- I have used netTcpBinding and i send various objects from client to server. When sending objects we send a special guid in one of the properties of object which we again verify at Server before processing the request.
I will like to know what all vulnerabilities are involved, if do not do anything explicitly for Security, that is no transport level security is applied.
One more point we are using NetTcpBinding at Internet.
netTcpBinding is normally used for Intranet where you are likely to have point to point comms so transport security is probably adequate.
If you are operating over the web then you will want to enable Message level security to secure the end to end traffic (transport security will only secure the content for 1 hop). The default security for netTcpBinding is transport security so you need to change this.
In both cases message privacy (encryption), integrity(against tampering) and partial authentication is achieved.
NetTcpBinding I believe defaults to Windows authentication - so you will need an account in a domain or actually on the Service machine (if operating in a Workgroup) matching the Windows credentials of the client.
Note that you can programmatically change request the credentials from the client and set them programmatically before opening the client proxy if need be.
Also enable reliable messaging.
How can I enable the encryption of an WCF (Windows Communication Foundation) Service with VB.NET?
Is it enough to add a certificate to a service an set <security mode=""> to "TransportWithMessageCredential"? Or is there any other settings needed?
If this is enough:
What's with the client? Maybe I'm wrong but I thought the client and the server need a certificate?!
The client can encrypt messages with the server public key. But how does the server encrypt messages to the client? Or does the client generate an symmetric encryptionkey and send it to the server?
It depends what type of end point you are using. If you are using an HTTP/HTTPS endpoint, simply having a server certificate is sufficient.
What are the differences between security mode="Transport" and security mode="TransportCredentialOnly" when I use it with BasicHttpBinding and setup ssl in ISS 7.0?
Check here:
http://developers.de/blogs/damir_dobric/archive/2006/07/31/890.aspx
and
http://msdn.microsoft.com/en-us/library/ff648505.aspx
Transport seems to require HTTPS to encrypt credentials and throws an exception if there is no SSL. TransportCredentialOnly will send the credentials in plain text and unencrypted and is recommended for testing ONLY!
Good Luck!!
With TransportCredentialOnly security mode, the underlying secure transport layer (usually TLS/SSL) provides the integrity and confidentiality protection for the communication, while SOAP messaging layer handles transporting the client credentials in the SOAP message.
In other words, TransportCredentialOnly security mode passes the user credentials in the SOAP message without encrypting or signing the SOAP message, and the underlying transport connection (typically TLS/SSL) needs to ensure that the message contents cannot be seen or altered by a third-party.