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.
Related
i have just started reading wcf. so many things is not clear to me.
1) i hard that we can provide security in wcf in the area of message level or transport level. is it true ? but in what are the areas we can provide security in asmx web service ?
2) i like to visualize or understand what does it mean like security in transport level or message level...anyone can elaborate what does it mean like transport level or message level security ?
3) when people would go for transport level security or message level security ?
4) anyone can give me the sample wcf config file for transport level security and message level security please because i want to see how config look like when people use transport level security or message level security in their wcf application.
5) what is SSH and how to use it in wcf ?
6) if certificate cert file only contain public key then i like to know how browser decrypt incoming data when cer certificate file is used at web server end?
it will be huge help if some one answer my all question in detail point wise.
I think you need a book on WCF.
A few (possibly subjective) stabs at answering some of your (very broad) questions:
1) Yes, you can have transport and/or message level security in WCF. ASMX is a legacy technology, which at least supports some forms of transport security (SSL).
2/3) Transport level security means that all traffic is encrypted by the transport layer, e.g. SSL/HTTPS. Message level security is software encryption of the actual message only and is mostly used among heterogeneous systems whose security protocols for transports are incompatible. Transport security is usually both easier to implement and more efficient.
4) This is a broad area. There's a configuration tool in your IDE (on the Tools menu) that you can use to experiment with the various settings.
5) SSH is the encryption standard used for secure web communication (HTTPS), among other things.
6) Certificates are used with symmetric encryption. There are two parts of the key, the public part and the private part. Anybody can read the public key and encrypt messages with it, only the party who has the private key can decrypt those messages. This type of encryption is very slow, so it is almost always used only to exchange a private key, generated on the fly, between client and server which is then used to encrypt subsequent traffic using the more efficient AES-type encryption algorithms.
I study microsoft explanation about Service Credentials Negotiation.. but i don't understand What is Service Credentials Negotiation and when we should use it?
Negotiation is the process of establishing trust between a client and
a service by exchanging credentials. The process is performed
iteratively between the client and the service, so as to disclose only
the information necessary for the next step in the negotiation
process. In practice, the end result is the delivery of a service's
credential to the client to be used in subsequent operations. With one
exception, by default the system-provided bindings in WCF negotiate
the service credential automatically when using message-level
security. (The exception is the BasicHttpBinding, which does not
enable security by default.) To disable this behavior, see the
NegotiateServiceCredential and NegotiateServiceCredential properties.
http://msdn.microsoft.com/en-us/library/ms733836(v=vs.110).aspx
So, by default the system-provided bindings in WCF negotiate the service credential automatically when using message-level security with exception of BasicHttpBinding and you only need to worry about it if you need to change this default behavior and provision credentials at the client instead of letting the service take care of that for you through process called negotiation...
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.
The only reason I can think of is that an extra layer of security is needed because Web Services run on top of an application layer protocol. Does this imply the need for an extra layer of security?
Many people new to Web services see SOAP as a way to exchange messages between two endpoints over HTTP. Over HTTP, one can authenticate the caller, sign the message, and encrypt the contents of the message. This makes the message secure in several dimensions: the caller is known, the receiver of the message can verify that the message did not change in transit, and entities watching the wire traffic cannot figure out what data is being exchanged. For those looking at SOAP messaging to solve bigger problems, however, HTTP-based security simply isn't enough. Many of the bigger problems involve sending the message along a path more complicated than request/response or over a transport that does not involve HTTP. The identity, integrity, and security of the message and the caller need to be preserved over multiple hops. More than one encryption key may be used along the route. Trust domains will be crossed. HTTP and its security mechanisms only address point-to-point security. More complex solutions need end-to-end security baked in. WS-Security addresses how to maintain a secure context over a multi-point message path.
Extract from http://msdn.microsoft.com/en-us/library/ms977327.aspx
I'm looking into WCF & Security.
There are several security modes but the big picture is that there are 2 main "layers" you can secure : Transport or Message.
Can someone explain this in more depth please?
What do I have to imagine when I'm securing Transport, how does it work, etc.
it is pretty much as you'd expect, transport security secures the transport - e.g. SSL over HTTP, whereas message security secures messages. Here's an msdn overview for reasons to use message security:
http://msdn.microsoft.com/en-us/library/ms733137.aspx
and an overview for transport:
http://msdn.microsoft.com/en-us/library/ms729700.aspx
(From the message security link):
Windows Communication Foundation (WCF) has two major modes for providing security (Transport and Message) and a third mode (TransportWithMessageCredential) that combines the two. This topic discusses message security and the reasons to use it.
What Is Message Security?
Message security uses the WS-Security specification to secure messages. The WS-Securityspecification describes enhancements to SOAP messaging to ensure confidentiality, integrity, and authentication at the SOAP message level (instead of the transport level).
In brief, message security differs from transport security by encapsulating the security credentials and claims with every message along with any message protection (signing or encryption). Applying the security directly to the message by modifying its content allows the secured message to be self-containing with respect to the security aspects. This enables some scenarios that are not possible when transport security is used.
Reasons to Use Message Security
In message-level security, all of the security information is encapsulated in the message. Securing the message with message-level security instead of transport-level security has the following advantages:
• End-to-end security. Transport security, such as Secure Sockets Layer (SSL) only secures messages when the communication is point-to-point. If the message is routed to one or more SOAP intermediaries (for example a router) before reaching the ultimate receiver, the message itself is not protected once an intermediary reads it from the wire. Additionally, the client authentication information is available only to the first intermediary and must be re-transmitted to the ultimate receiver in out-of-band fashion, if necessary. This applies even if the entire route uses SSL security between individual hops. Because message security works directly with the message and secures the XML in it, the security stays with the message regardless of how many intermediaries are involved before it reaches the ultimate receiver. This enables a true end-to-end security scenario.
• Increased flexibility. Parts of the message, instead of the entire message, can be signed or encrypted. This means that intermediaries can view the parts of the message that are intended for them. If the sender needs to make part of the information in the message visible to the intermediaries but wants to ensure that it is not tampered with, it can just sign it but leave it unencrypted. Since the signature is part of the message, the ultimate receiver can verify that the information in the message was received intact. One scenario might have a SOAP intermediary service that routes message according the Action header value. By default, WCF does not encrypt the Action value but signs it if message security is used. Therefore, this information is available to all intermediaries, but no one can change it.
• Support for multiple transports. You can send secured messages over many different transports, such as named pipes and TCP, without having to rely on the protocol for security. With transport-level security, all the security information is scoped to a single particular transport connection and is not available from the message content itself. Message security makes the message secure regardless of what transport you use to transmit the message, and the security context is directly embedded inside the message.
• Support for a wide set of credentials and claims. The message security is based on the WS-Security specification, which provides an extensible framework capable of transmitting any type of claim inside the SOAP message. Unlike transport security, the set of authentication mechanisms, or claims, that you can use is not limited by the transport capabilities. WCF message security includes multiple types of authentication and claim transmission and can be extended to support additional types as necessary. For those reasons, for example, a federated credentials scenario is not possible without message security. For more information about federation scenarios WCF supports, see Federation and Issued Tokens.
Transport security, such as Secure Sockets Layer (SSL) only secures
messages when the communication is point-to-point. If the message is
routed to one or more SOAP intermediaries (for example a router)
before reaching the ultimate receiver, the message itself is not
protected once an intermediary reads it from the wire.
Misleading. A network router or switch (OSI Layer 2 and 3) will not have access to the message content if encrypted with Transport layer security (Server side SSL certificate) since the service side SSL certificate is needed to decrypt the message. Transport layer security secures the message between the client and intended destination IP address since only the destination service provider is assumed to have the SSL private certificate which is required to decrypt the message. A SOAP intermediary would only be able to read the content if the SOAP intermediary (i.e. ESB) was in fact the intended message destination that actually establishes the encrypted transport channel with the client, ensuring a secure channel from client to server regardless of the number of network hops, routers and switches, etc (OSI layers 2 and 3).
Message Level security would add security to the message and could encrypt parts of a message if a middleware ESB (intended SOAP Intermediary) needed to read parts of a message to make routing decisions (Content Based Routing) but shouldn't be able to read other parts of a message that should only be accessed by downstream systems.
With transport use are securing the channel you are using, and with message the message (content) you are sending.