Accrding to the following quote, WCF transport security provides point-to-point security:
Transport security is used to provide point-to-point security between the two endpoints (service and client). If there are intermediary systems between the client and the server, each intermediate point must forward the message over a new SSL connection.
What is meant by SSL providing point-to-point security?
Is SSL communication still possible between client and server, if intermediary system ( located between the client and the server ) forwards the message over a non-SSL connection?
Assuming it is possible ... I don't see why intermediary system forwarding messages over a non-SSL connection would provide less security, since messages are already encypted by original sender ( which is either client or server ) and thus can't be decrypted by an intermediary systems?
I've already answered a practically identical question:
WCF Transport security weakness
If you have any additional questions, ask away.
Related
I have client server application which using WCF service with Transport security mode and NetTCP binding. I heard like Transport security is best for local intranet, not for internet. Now my scenario is I need to access WCF service over internet (from another country), but dont want to use Message security (cause it need to purchase and install certificate on server and each client). I want to use Transport security and also encrypt my data, so no one can hack it from internet.
So please someone guide me how can I encrypt my data with Transport security ?
Thanks
Transport is just SSL, so after the initial setup on the host and client sides, there's really nothing special to it. SSL will encrypt all the bytes starting at byte 0 and only the host that distributed the public key portion of the SSL cert will be able to decrypt the transmission since it and only it should have the private key part of the certificate.
SSL does present some potential problems if you have a load balancer or proxy fronting your service - i.e. if the proxy or LB server didn't begin the SSL transmission, it won't know what to do with the inbound message. But SSL encryption can be offloaded to a LB or proxy, so there are ways around that.
Here's a link to a stackoverflow question about SSL over WCF
Enable SSL for my WCF service
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'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.
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.
I am reading about WCF Transport Security and I get a plethora of doubts in my mind because I have less network knowledge.
They say, Transport security is good to use only when there is direct communication between client and server. There should be no intermediaries.
First of all I want to know, what are these intermediaries ? According to me, they are the routers sitting in between, which relay the messages to next hop, and are not complete computer systems, on which somebody can sit and intercept the messages.
I have other doubts also regarding this topic, which I will ask once I receive the answer for this one.
No routers are not intermediaries in this scenario. Routers, switches and other network infrastructure devices operates on lower layers of ISO/OSI or TCP/IP network protocol stacks.
Intermediaries are in this case gateways, load balancers or reverse proxies. From the client point of view the gateway or reverse proxy is the host of the service but it doesn't have to be. It can be just entry point into some corporate network which will forward the message to the real host (server hosting the service) hidden inside the corporate network.
The difference between message and transport security is that transport security ends at the gateway - for client it is a destination and client opens connection to that destination. The connection is point to point and transport security cannot be maintained among multiple connections (transport security starts at one side of the connection and ends on the other side). Message security in turn is end to end it means that message contains security as part of its content and gateways just forward secured messages. Only the real destination (real host of the service) should be able to decrypt those messages.
While using HTTPS protocol, who encrypts the message, the Browser or the Network Card?
Again HTTPS is upper layer protocol - it is not responsibility of the network card to use it. Some programming API or OS infrastructure is responsible for creating HTTPS connection. Browser just calls this API.