- From: Michael Hanson <hanson@reactivity.com>
- Date: Fri, 04 Mar 2005 09:31:18 -0800
- To: daniela.claro@eseo.fr
- CC: www-ws@w3.org
- Message-ID: <42289B66.7000200@reactivity.com>
Hello, Daniela - SSL is sufficient for point-to-point web service connections; it provides authentication, integrity protection, confidentiality, and resistance to replay attacks. The typical "server certificate only" configuration of SSL may be insufficient --in a high-value web service interaction you would frequently want to use a client certificate (a so-called "bilateral certificate exchange") to authenticate the client to the server. When a web service intermediary (such as the Service Gateway made by my company, Reactivity), enters the picture, SSL is no longer sufficient. An intermediary such as our Gateway performs tasks like validation, verification of digital signatures, encryption or decryption, transformation, logging, and routing. For all of these tasks, we require access to the unencrypted bytes of the message content, which means that we need to act as an SSL endpoint. We can't just forward the SSL bytes onward because we do not have access to the private key of the client, so we either have to start a new SSL session with our own private key, or use non-SSL-based technologies for our cryptographic requirements. The WS-Security protocol provides mechanisms for authentication (SAML, WS Username), integrity protection (XML Signature), confidentiality (XML Encryption), and replay (through a variety of techniques). These mechanisms all work by modifying the SOAP envelope (typically by adding more Headers, though Encryption also modifies Body elements). WS-Security-based techniques have the additional advantage of persistence. An SSL session is ephemeral -- the guarantees of confidentiality and integrity apply only to bytes moving through the encrypted tunnel. An encrypted or signed SOAP envelope can be sent to a message bus, stored on disk or inserted to a database, and will remain secure as long as the private keys used in its construction are kept secret. In our product, for example, we write selected messages into a signed message log, which means that we have a tamper-evident store of secure content, which can help our customers satisfy regulatory and auditing requirements. I hope that helps! If you need more information, we have several white papers available here: http://www.reactivity.com/guidebook/white_papers_and_resources.html best- Michael Hanson Chief Architect, Reactivity hanson@reactivity.com Daniela CLARO wrote: > Hi all, > > Could anyone please explain me, why SSL is not secure for web > services? Moreover, what is exactly the "intermediaries" that could > exist between a web service connection that SSL can not garantee tthe > security anymore? > > > Thank you very much, > Daniela
Received on Saturday, 5 March 2005 04:55:33 UTC