Q:

Transport-level vs message-level security

I'm reading a book on WCF and author debates about pros of using message-level security over using transport-level security. Anyways, I can't find any logic in author's arguments 

One limitation of transport
  security is that it relies on every
  “step” and participant in the network
  path having consistently conﬁgured
  security. In other words, if a message
  must travel through an intermediary
  before reaching its destination, there
  is no way to ensure that transport
  security has been enabled for the step
  after the intermediary (unless that
  interme- diary is fully controlled by
  the original service provider). If
  that security is not faithfully
  reproduced, the data may be
  compromised downstream. 
Message security focuses on ensuring the integrity and privacy of
  individ- ual messages, without regard
  for the network. Through mechanisms
  such as encryption and signing via
  public and private keys, the message
  will be protected even if sent over an
  unprotected transport (such as plain
  HTTP).

a) 

If that security is not faithfully
  reproduced, the data may be
  compromised downstream.

True, but assuming two systems communicating use SSL and thus certificates, then the data they exchange can't be decrypted by intermediary, but instead it can only be altered, which the receiver will notice and thus reject the packet?!
b) Anyways, as far as I understand the above quote, it is implying that if two systems establish a SSL connection, and if intermediary system S has SSL enabled and if S is also owned by a hacker, then S ( aka hacker ) won't be able to intercept SSL traffic travelling through it? But if S doesn't have SSL enabled, then hacker will be able to intercept SSL traffic? That doesn't make sense!
c)

Message security focuses on ensuring the integrity and privacy of individ-
  ual messages, without regard for the network. Through mechanisms such
  as encryption and signing via public and private keys, the message will be
  protected even if sent over an unprotected transport (such as plain HTTP).

This doesn't make sense, since transport-level security also can use encryption and certificates, so why would using private/public keys at message-level be more secure than using them at transport-level? Namelly, if intermediary is able to intercept SSL traffic, why wouldn't it also be able to intercept messages secured via message-level private/public keys?
thank you

A:

Consider the case of SSL interception.
Generally, if you have an SSL encrypted connection to a server, you can trust that you "really are* connected to that server, and that the server's owners have identified themselves unambiguously to a mutually trusted third party, like Verisign, Entrust, or Thawte (by presenting credentials identifying their name, address, contact information, ability to do business, etc., and receiving a certificate countersigned by the third party's signature). Using SSL, this certificate is an assurance to the end user that traffic between the user's browser (client) and the server's SSL endpoint (which may not be the server itself, but some switch, router, or load-balancer where the SSL certificate is installed) is secure.  Anyone intercepting that traffic gets gobbledygook and if they tamper with it in any way, then the traffic is rejected by the server.
But SSL interception is becoming common in many companies.  With SSL interception, you "ask" for an HTTPS connection to (for example) www.google.com, the company's switch/router/proxy hands you a valid certificate naming www.google.com as the endpoint (so your browser doesn't complain about a name mismatch), but instead of being countersigned by a mutually trusted third party, it is countersigned by their own certificate authority (operating somewhere in the company), which also happens to be trusted by your browser (since it's in your trusted root CA list which the company has control over).
The company's proxy then establishes a separate SSL-encrypted connection to your target site (in this example, www.google.com), but the proxy/switch/router in the middle is now capable of logging all of your traffic.
You still see a lock icon in your browser, since the traffic is encrypted up to your company's inner SSL endpoint using their own certificate, and the traffic is re-encrypted from that endpoint to your final destination using the destination's SSL certificate, but the man in the middle (the proxy/router/switch) can now log, redirect, or even tamper with all of your traffic.
Message-level encryption would guarantee that the message remains encrypted, even during these intermediate "hops" where the traffic itself is decrypted.
Load-balancing is another good example, because the SSL certificate is generally installed on the load balancer, which represents the SSL endpoint.  The load balancer is then responsible for deciding which physical machine to send the now-decrypted traffic to for processing.  Your messages may go through several "hops" like this before it finally reaches the service endpoint that can understand and process the message.

A:

I think I see what he's getting at.  Say like this:
Web client ---> Presentation web server ---> web service call to database
In this case you're depending on the middle server encrypting the data again before it gets to the database.  If the message was encrypted instead, only the back end would know how to read it, so the middle doesn't matter.

