Docstoc

SSL over SOAP

Document Sample
SSL over SOAP Powered By Docstoc
					SSL-over-SOAP




Sebastian Gajek, Lijun Liao, Bodo Möller, and Jörg Schwenk
Horst Görtz Institute for IT Security, Ruhr-University Bochum
Summary

•   What is SSL?
•   Why not SSL-over-TCP?
•   XML Signature, XML Encryption, WS-Security
•   Some traps in designing key agreement protocols over SOAP
•   SSL-over-SOAP
•   Future Work
SSL
SSL Overview


                     HTTP(S)



           Hand-   Change    Alert   Applica
           shake   Chipher           tion

                   Record Layer


                        TCP
SSL Handshake
SSL Handshake – Basic Step


    Client                   Server




         PK
      Server
SSL Handshake – Basic Step


    Client                   Server




         PK                      PK
      Server                  Server
SSL Handshake – Basic Step


    Client                   Server




         PK                      PK
      Server                  Server
SSL Record Layer


 HTTP-Data

                          Fragmentation

    http   3.1   Length

                          Compression

    http   3.1   Length

                          Encryption

    http   3.1   Length    MAC         Padd.   P. Länge
Summary

•   What is SSL?
•   Why not SSL-over-TCP?
•   XML Signature, XML Encryption, WS-Security
•   Some traps in designing key agreement protocols over SOAP
•   SSL-over-SOAP
•   Future Work
Why not SSL-over-TCP?

SOAP Sender                 SOAP Receiver




              SSL1


Controls SSL1 only      No protection here
Why not SSL-over-TCP?

SOAP Sender                SOAP Receiver




              SSL1      SSL2


Controls SSL1 only      Controls SSL2 only
Why not SSL-over-TCP?

•   SSL protects TCP connections, not SOAP connections
    – Protection (both confidentiality and integrity) ends at TCP
       endpoint.
    – Does not take into account multi-tier-applications, or SOAP
       intermediaries.
•   SSL authentication policies are outside the scope of WS-Policy
    – X.509 certificate parameters only accessible through web server
       interfaces
    – If no strict policy is configured, SSL is subject to PKI spoofing
       attacks.
    – It is NOT sufficient to define a certain domain name to be
       contained in a valid SSL certificate.
    – Standard SSL-over-TCP was considered secure in practice
       UNTIL 2004; since then, pharming attacks have shown that in a
       lot of configurations, it is insecure.
Why not SSL-over-TCP?

•   SSL-overTCP does not provide the necessary granularity for Web
    ervices
     – Standard example: Credit card information in eCommerce

<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
             Only visible to
  <Name>John Smith<Name/> the Web Shop
  <CreditCard Limit='5,000' Currency='USD'>
              Only visible for 5567
    <Number> 4019 2445 0277CC Company </Number>
    <Issuer>Bank of the Internet</Issuer>
    <Expiration>04/02</Expiration>
  </CreditCard>
</PaymentInfo>
Why not SSL-over-TCP?

•   SSL-overTCP does not provide the necessary granularity for Web
    ervices
     – Standard example: Credit card information in eCommerce

<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
  <Name>John Smith<Name/>
  <CreditCard Limit='5,000' Currency='USD'>
              Only visible for 5567
    <Number> 4019 2445 0277CC Company </Number>
    <Issuer>Bank of the Internet</Issuer>
    <Expiration>04/02</Expiration>
  </CreditCard>
</PaymentInfo>
Advantages of SSL-over-SOAP

•   SSL-over SOAP protects complete SOAP connections
     – Protection (both confidentiality and integrity) between two SOAP
        endpoints, regardless of the number of intermediaries.
•   SSL-over-SOAP authentication policies can be described in WS-
    Policy
     – X.509 certificate parameters accessible through XML Signature
        libraries
     – Policies only have to be described for SOAP endpoints
•   Instead of transport layer security, we have message security
     – This was intended by the WS-Security roadmap
Summary

•   What is SSL?
•   Why not SSL-over-TCP?
•   XML Signature, XML Encryption, WS-Security
•   Some traps in designing key agreement protocols over SOAP
•   SSL-over-SOAP
•   Future Work
XML Signature

<Signature>
  <SignedInfo>
    <!-- Canoncalization algorithm and parameters -->
    <CanonicalizationMethod/>
    <!-- Signature algorithm and parameters -->
    <SignatureMethod/>
     Information about which data has been signed, and how
    <!-- Resources to be signed -->
    (<Reference URI? >
      <Transforms/>?
      <DigestMethod/>
      <DigestValue/>)+
  <!-- Signature value is built over <SignedInfo> -->
  <SignatureValue/>       Signature Value
  <!-- Information about the key to verify the signature -->
  <KeyInfo/>?
         Additional Information, e.g. about verification keys
  <!-- for extension -->
  <Object/>*
XML Signature

<Signature>
  <SignedInfo>
    <!-- Canoncalization algorithm and parameters -->
    <CanonicalizationMethod/>
    <!-- Signature algorithm and parameters -->
    <SignatureMethod/>
    <!-- Resources to be signed -->
    (<Reference URI? >
      <Transforms/>?
      <DigestMethod/>
      <DigestValue/>)+
  <!-- Signature value is built over <SignedInfo> -->
  <SignatureValue/>       Signature Value
  <!-- Information about the key to verify the signature -->
  <KeyInfo/>?
         Additional Information, e.g. about verification keys
  <!-- for extension -->
  <Object/>*
XML Signature

<Signature>
  <SignedInfo>
    <!-- Canoncalization algorithm and parameters -->
    <CanonicalizationMethod/>
    <!-- Signature algorithm and parameters -->
    <SignatureMethod/>
     Information about which data has been signed, and how
    <!-- Resources to be signed -->
    (<Reference URI? >
      <Transforms/>?
      <DigestMethod/>
      <DigestValue/>)+
  <!-- Signature value is built over <SignedInfo> -->
  <SignatureValue/>
  <!-- Information about the key to verify the signature -->
  <KeyInfo/>?
         Additional Information, e.g. about verification keys
  <!-- for extension -->
  <Object/>*
XML Signature

<Signature>
  <SignedInfo>
    <!-- Canoncalization algorithm and parameters -->
    <CanonicalizationMethod/>
    <!-- Signature algorithm and parameters -->
    <SignatureMethod/>
     Information about which data has been signed, and how
    <!-- Resources to be signed -->
    (<Reference URI? >
      <Transforms/>?
      <DigestMethod/>
      <DigestValue/>)+
  <!-- Signature value is built over <SignedInfo> -->
  <SignatureValue/>       Signature Value
  <!-- Information about the key to verify the signature -->
  <KeyInfo/>?
  <!-- for extension -->
  <Object/>*
XML Encryption

<EncryptedData Type? MimeType? Encoding?>
  <!-- Encryption algorithm and parameters -->
  <EncryptionMetod/>?
                        Encryption Algorithm
  <!-- Information about the key to decrypt
        Encryption data -->
       the encryptedKey (same structure as EncryptedData)
  <KeyInfo/>?
  <!-- Encrypted Data -->
  <CipherData>
          The Encrypted Data or an URL where to find it
   <CipherValue/>?
   <CipherReference/>?
  <!-- Any properties related to the encryption -->
                       Additional Information
  <EncryptionProperties/>?
XML Encryption

<EncryptedData Type? MimeType? Encoding?>
  <!-- Encryption algorithm and parameters -->
  <EncryptionMetod/>?
                        Encryption Algorithm
  <!-- Information about the key to decrypt
       the encrypted data -->
  <KeyInfo/>?
  <!-- Encrypted Data -->
  <CipherData>
          The Encrypted Data or an URL where to
   <CipherValue/>?                                    find it
   <CipherReference/>?
  <!-- Any properties related to the encryption -->
                       Additional Information
  <EncryptionProperties/>?
XML Encryption

<EncryptedData Type? MimeType? Encoding?>
  <!-- Encryption algorithm and parameters -->
  <EncryptionMetod/>?
                        Encryption Algorithm
  <!-- Information about the key to decrypt
        Encryption data -->
       the encryptedKey (same structure as EncryptedData)
  <KeyInfo/>?
  <!-- Encrypted Data -->
  <CipherData>
   <CipherValue/>?
   <CipherReference/>?
  <!-- Any properties related to the encryption -->
                       Additional Information
  <EncryptionProperties/>?
WS-Security Roadmap


        WS-Secure      WS-Federation
       Conversation                     WS-Authorization


        WS-Policy        WS-Trust         WS-Privacy

Time
                        WS-Security


                      SOAP Foundation
WS-Security Roadmap


        WS-Secure      WS-Federation
       Conversation                     WS-Authorization


        WS-Policy        WS-Trust         WS-Privacy

Time
                        WS-Security


                      SOAP Foundation
WS-Security

                      soap: envelope



     soap: header           soap: body   wsu:Id=“theBody“


     wsse:security          Data


     ds:signature


     ds:signedInfo


     ds:reference    uri=“#theBody“
Summary

•   What is SSL?
•   Why not SSL-over-TCP?
•   XML Signature, XML Encryption, WS-Security
•   Some traps in designing key agreement protocols over SOAP
•   SSL-over-SOAP
•   Future Work
A Simple Key Exchange Protocol

•      The session key, encrypted with the recipients public key, is signed
       by the sender
•      The original document: The SOAP body (containing the encrypted
       session key) is signed and referenced by a wsu:id attribute;
       signature verification returns Boolean value.
                     soap: envelope


                                                               Vulnerability:
    soap: header            soap: body      wsu:Id=“theBody“
                                                               SOAP and XML Signature
    wsse:security           EncryptedData                      logics process data
                                                               independently. That is,
    ds:signature                                               when signed data located
                                                PK             at wsu:id is valid then
    ds:signedInfo                            Server            the content is processed
                                                               by SOAP engine.
    ds:reference    uri=“#theBody“
XML Wrapping Attacks (McIntosh
and Austel 2005)
•   The modified document: The same data is signed and referenced by
    a wsu:id attribute, but the SOAP Body has changed.


                                  soap: envelope



      soap: header                      soap: body   wsu:Id=“newBody“


      wsse:security   Wrapper           getQuote


      ds:signature                      soap: body   wsu:Id=“theBody“


      ds:signedInfo                     getQuote


      ds:reference     uri=“#theBody“
XML Wrapping Attacks (McIntosh
and Austel 2005)
Solutions:
1. Find a solution against wrapping attacks (difficult)
2. Use a secure key exchange protocol like SSL:
    – Sender computes a cryptographic checksum based on
       key

   – Receiver computes a checksum based on key

   – Since both checksums differ, the attack can be
     detected.
Summary

•   What is SSL?
•   Why not SSL-over-TCP?
•   XML Signature, XML Encryption, WS-Security
•   Some traps in designing key agreement protocols over SOAP
•   SSL-over-SOAP
•   Future Work
SSL-over-SOAP

•   Problem 1: Shall we place the handshake messages in the SOAP
    header or the SOAP body?
•   Solution: Handshake messages must be placed in the body,
    because SSL requires that a new handshake can be performed
    encryted.
     – Thus for encrypted handshakes, the header is needed to store
       the key info and the message authentication code (according to
       WS-Security)
SSL-over-SOAP

•   Problem 2: How can we describe the different Handshake messages
    in XML?
•   Solution: Use WS-Trust (e.g. “wst” in handhake message 1 below)
<soap:Envelope>
 <soap:Body>
  <wst:RequestSecurityToken tls:Id='uuid:UUID-msg1'>
   <wst:TokenType>.../sc/sct</>
   <wst:RequestType>.../trust/KET</>
   <wst:RequestKET/>
   <wst:KeyExchangeToken>
    <tls:ClientHello>
     <tls:Version>3.2</>
     <tls:CipherSuites>
      <tls:CipherSuite>...#tls_RSA_with_AES256_SHA1</>
     <tls:CompressionMethods>
      <tls:CompressionMethod>...#compression_null</>
     <wst:Entropy>
      <wst:BinarySecret Type='.../Nonce'>M7o9...MO0o=</>
SSL-over-SOAP

•   Problem 3: How can we compute the cryptographic checksum? (In
    SSL-over-TCP, this is simply the checksum over a byte stream.)
•   Solution: Compute the checksum over (parts of) the SOAP body
     – In the SSL framework, the exchanged messages are those
       visible at the handshake layer and do not include record layer
       headers.
     – Hence in SSL-over-SOAP, the exchanged messages are the
       SOAP bodies in messages 1 and 2,
     – and the SOAP body except the <tls:Finished> in this message.
     – The SOAP bodies are first canonicalized with the algorithm
       Exclusive C14N and then concatenated.
Summary

•   What is SSL?
•   Why not SSL-over-TCP?
•   XML Signature, XML Encryption, WS-Security
•   Some traps in designing key agreement protocols over SOAP
•   SSL-over-SOAP
•   Future Work
Future Work


•   Identify which key exchange/key agreement protocols are immune
    against XML wrapping attacks.
•   Design a streamlined, secure protocol using WS-Trust for each
    important key agreement/key exchange primitive.
•   Investigate key agreement protocols used in real world web services
    (are there any?).
Questions?




                 Jörg Schwenk
             joerg.schwenk@rub.de

				
DOCUMENT INFO
Shared By:
Categories:
Tags: over, SOAP
Stats:
views:32
posted:6/28/2010
language:English
pages:38
Description: SSL over SOAP