I have read at several places that transport security is only hop to hop (vs. endpoint to endpoint), and thus has limited use in internet scenarios where there may be several hops in-between your endpoints. First, is this correct? Second, why is transport security only hop to hop? What is preventing the intermediary nodes from simply relaying what they have gotten from their respective receivers?
what they mean when they say that transport security provides only hop-by-hop protection is that at the intermediate steps, the incoming data stream is unencrypted and the intermediary can see the message in plain-text if it so wishes. The intermediary does encrypt the message again before passing it over to next node. So if the intermediary nodes are trusted nodes (your own servers) there is no harm in using transport security, but if the intermediary nodes are not owned by you, these nodes can see the plain message and your data is vulnerable.
This brings me to the question: what are intermediary nodes? Are these the nodes specified in clientVia? So if I don't have any clientVia's (as is mostly the case) can I safely use transport security without the need for message-level security?
References:
http://www.silverlighthack.com/post/2008/12/10/WCF-101-Understanding-Transfer-Security-Visually.aspx. There is a nice diagram here, but per my understanding above, I think part of it is wrong.
http://msdn.microsoft.com/en-us/library/ff647370.aspx
Related
To be honest I don't know if this is the appropriate title since I am completely new to this area, but I will try my best to explain below.
The scenario can be modeled as a group of functionally identical servers and a group of functionally identical clients. Assume each client knows the endpoints of all the servers (possibly from a broker or some kind of name service), and randomly chooses one to talk to.
Problem 1: The client and the server first need to authenticate themselves to each other (i.e. the client must show the server that it's a valid client, vice versa).
Problem 2: After that, the client and server talk to each other over some kind of encryption.
For Problem 1, I don't know what's the best solution. For Problem 2, I'm thinking about letting each clients create a private key and give the corresponding public key to the server it talks to right after authentication, so that no one else can decrypt its messages; and let all servers share a private key and distribute the corresponding public key to all clients, so that the external world (including the clients) can't decrypt what the clients send to the servers.
These are probably very naive approaches though, so I'd really appreciate any help & thoughts on the problems. Thank you.
I asked a similar question about half a year ago here, I've been redirected to Information Security.
After reading through my answer and rethinking your question, if you still have questions that are so broad, I suggest to ask there. StackOverflow, from what I know, is more about programming (thus security in programming) than security concepts. Either way, you will probably have to migrate there at some point when doing your project.
To begin with, you need to seriously consider what needs protecting in your system. Like here (check Gilles' comment and others), one of the first and most important things to do is to think over what security measures you have to take. You just mentioned authentication and encryption, but there are many more things that are important, like data integrity. Check wiki page for security measures. After knowing more about these, you can choose what (if any) encryption algorithms, hashing functions and others you need.
For example, forgetting about data integrity is forgetting about hashing, which is the most popular security measure I encounter on SO. By applying encryption, you 'merely' can expect no one else to be able to read the message. But you cannot be sure if it reaches the destination unchanged (if anything), either because of interceptors or signal losses. I assume you need to be sure.
A typical architecture I am aware of, assumes asymmetric encryption for private key exchange and then communicating using private keys. This is because public-key infrastructure (PKI) assumes that the key of one of the sides is publicly known, making communication easier, but certainly slower (e.g. due to key length: RSA [asymmetric] starts with 512bits, but typical key length now is 2048, which I can compare to weakest, but still secure AES [symmetric], which key lengths start with 128bits). The problem is, as you stated, the server and user are not authenticated to each other, so the server does not really know if the person sending the data really is who they claim they are. Also, the data could have been changed during traffic.
To prevent that, you need a so called 'key exchange algorithm', such as one of the Diffie Hellman schemes (so, DH might be the 'raw' answer to both of your problems).
Taking all above into consideration, you might want to use one (or more) of the popular protocols and/or services to define your architecture. Popular ones are SSH, SSL/TLS and IPSec. Read about them, define what services you need, check if they are present in one of the services above and you are willing to use the service. If not, you can always design your own using raw crypto algorithms and digests (hashes).
I was trying to understand the difference between Transport security and message security from the below link and came across the following content.
The http://msdn.microsoft.com/en-us/library/ff648863.aspx says that
When using transport security, the user credentials and claims are passed by using the transport layer. In other words, user credentials are transport-dependent, which allows fewer authentication options compared to message security.
Can someone please explain me the meaning of above statement with an example if possible ?
It has mainly two parts which I could not understand :
user credentials are transport-dependent.
allows fewer authentication options compared to message security.
If you read further in those article, you yourself might be able to make out.
If you see TCP/IP or OSI Layers of the Protocol suit you will notice that upto Transport layer communication is mostly dependent on communication mechanism. The protocols of Transport layer are limited (HTTP, TCP, IPC, MSMQ) for transporting of data. They transport all the data in same manner irrespective of the type of data. Here the channel that is transporting is made secure.
On the other hand in message level security, it is message that is secure. You can use any type of mechanism to encrypt / authenticate your message, and in this case Transport level security provides added advantage.
In simple term, A, B and C are three persons. A wants to send a message to C and B is transporter of the message. If A send his message in a simple envelop, then the message is as secure as the transporter that is B. But if A send a message locked in a box and only C has its key, then his message is secure as B plus it has security of the locked box.
Hope this helps.
Further going with the above analogy, if the transporter B is say your postal service, then A has limited options of having security and limited flexibilty to change B's security provision as those are decided by another party (the Postal Department). But in case you are sending a locked box, the locking mechanism is your choice, you have flexibility to choose type of lock of your own choice as long as C agrees and can open it.
I have a question with regards to WCF client channel lifetime while using Message security, but first, a few notes on my company's setup and guidelines:
Our client-server applications are solely for intranet use
Our clients are WPF applications
Our company's guidelines for WCF usage are:
Use wsHttpBinding
Use Message Security
Service InstanceMode: PerCall
Service ConcurrencyMode: Multiple
It is the first time I have to use message security on an intranet setup. Here's how I typically use my client channels to limit the amount of resources kept on the client and server and literally just to keep things simple:
Instantiate + open channel (with ChannelFactory)
Make the WCF call
Close / dispose the channel asap
While monitoring this strategy with Fiddler 2, I noticed that because of Message Security, a single WCF call ended up causing 5 round-trips to my service:
3 initial round-trips for handshaking
1 round-trip for the actual WCF call
1 call to close the session (since I am using PerCall, I am assuming this is more a security session at the IIS level)
If I were to turn off Message Security, as one would expect, one WCF ended up being... A single round-trip.
As of now, I must use Message Security because that's our guideline. With this in mind and knowing that we make hundreds of WCF calls from each client WPF app a session, would you therefore advise to open the client channel and keep it open for re-use instead of disposing of it every time?
I would advise not to preemptively turn off features until you know they are a known problem. Preoptimization is needless work. Until you notice your clients having lagging problems, I would not worry about the message security. At that point, try a few things: one of your approaches of keeping a client open longer; two, try grouping requests together without turning off message security; three, consider caching, if you can; four, if the message security is the final culprit, then try a different method. I wouldn't just turn something off because I see a bit more network traffic until I knew it was the absolute last thing that I could do to improve performance.
When you read about WCF Message Security and compare it to Transport security, one of the drawbacks that they always mention is that transport security is point-to-point and can't secure a message routed through intermediaries.
What is an example of these intermediaries. When would you use one?
All my experience with services is with point-to-point communication so I'm trying to build a context for when you might encounter a SOAP intermediary or router or proxy.
There are other questions on SO that beat around what I'm getting at but don't directly answer my question. For example, in this question:
Does SSL provide point-to-point security?
the answer says:
intermediate system', I think that quote means a system that must
access the message in the middle (intentionally or not)... not just a
router, but something actually decrypting, viewing and/or modifying
the message.
My question is: What would be an example of a system that need to view/decrypt/modify the message and why would it need to do that?
I just found a partial answer in this document from MS:
http://msdn.microsoft.com/en-us/library/ff647097.aspx
Part of it says:
Message layer security that uses X.509 certificates is flexible enough to provide point-to-point or end-to-end security. This allows messages to be persisted in a secure state for short periods for queue-based processing or for longer periods in an archived state.
So an example would be if a message were queued or stored off to disk. It would stay encrypted through the time it was processed and deleted from disk, presumably.
Edit: Here is a really good article on building a WCF Service Router that explains some of the reasons you might want to use one: http://msdn.microsoft.com/en-us/magazine/cc500646.aspx
See also: http://msdn.microsoft.com/en-us/library/ms731081.aspx
I need to implement a very secured Web Service using WCF. I have read a lot of documents about security in WCF concerning authorization, authentication, message encryption. The web service will use https, Windows Authentication for access to the WS, SQL Server Membership/Role Provider for user authentication and authorization on WS operations and finally message encryption.
I read in one of documents that it is good to consider security on each layer indenpendently, i.e. Transport Layer security must be thought without considering Message Layer. Therefore, using SSL through https in combination with message encryption (using public/private key encryption and signature) would be a good practice, since https concerns Transport Layer and message encryption concerns Message Layer.
But a friend told me that [https + message encryption] is too much; https is sufficient.
What do you think?
Thanks.
If you have SSL then you still need to encrypt your messages if you don't really trust the server which stores them (it could have its files stolen), so this is all good practice.
There comes a point where you have a weakest link problem.
What is your weakest link?
Example: I spend $100,000,000 defending an airport from terrorists, so they go after a train station instead. Money and effort both wasted.
Ask yourself what the threat model is and design your security for that. TLS is a bare minimum for any Internet-based communications, but it doesn't matter if somebody can install a keystroke logger.
As you certainly understand, the role of Transport-Level Security is to secure the transmission of the message, whereas Message-Level Security is about securing the message itself.
It all depends on the attack vectors (or more generally the purpose) you're considering.
In both cases, the security models involved can have to purposes: protection against eavesdropping (relying on encryption) and integrity protection (ultimately relying on signatures, since based on public-key cryptography in most cases).
TLS with server-certificate only will provide you with the security of the transport, and the client will know that the communication really comes from the server it expects (if configured properly, of course). In addition, if you use client-certificate, this will also guarantee the server that the communication comes from a client that has the private key for this client certificate.
However, when the data is no longer in transit, you rely on the security of the machine where it's used and stored. You might no longer be able to assert with certainty where the data came from, for example.
Message-level security doesn't rely on how the communication was made. Message-level signature allows you to know where the messages came from at a later date, independently of how they've been transferred. This can be useful for audit purposes. Message-level encryption would also reduce the risks of someone getting hold of the data if it's stored somewhere where some data could be taken (e.g. some intranet storage systems).
Basically, if the private key used to decrypt the messages has the same protection as the private key used for SSL authentication, and if the messages are not stored for longer time than the connection, in that case it is certainly overkill.
OTOH, if you've got different servers, or if the key is stored e.g. using hardware security of sorts, or is only made available by user input, then it is good advice to secure the messages themselves as well. Application level security also makes sense for auditing purposes and against configuration mistakes, although personally I think signing the data (integrity protection) is more important in this respect.
Of course, the question can also become: if you're already using a web-service that uses SOAP/WSDL, why not use XML encrypt/sign? It's not that hard to configure. Note that it does certainly take more processor time and memory. Oh, one warning: don't even try it if the other side does not know what they are doing - you'll spend ages explaining it and even then you run into trouble if you want to change a single parameter later on.
Final hint: use standards and standardized software or you'll certainly run into crap. Spend some time getting getting to know how things work, and make sure you don't accept ill formatted messages when you call verify (e.g. XML signing the wrong node or accepting MD5 and such things).